- Pokoli repetát hoz az új GeForce driver
- Elkezdtek szállingózni az Arctic P Pro sorozatú ventilátorai
- Autós kamerák
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Home server / házi szerver építése
- Kezdő fotósok digitális fényképei
- Dell notebook topic
- CPU léghűtés kibeszélő
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen monitort vegyek?
Aktív témák
-
perla
csendes tag
1. Register renaming es attoltes nem ugyanaz, de ezt mar mondtam. Masreszt az, hogy ket utasitas mehet egyszerre, az nem jelenti azt, hogy pl. a masodik nem lassit, hiszen az elso mehetne egyutt a harmadikkal is, ha nem lenne ott a masodik. Amugy minden utasitas, ami atmegy a pipe-on bir lassitani, ha lehetne helyette ott a kovetkezo.
Ha a peldam nem tetszik, nyugodtan irjal masikat, megnezhetjuk.
2. Ha ez hivatalos allaspont, akkor rakd be az url-t, ahol olvashato.
3. Cafolni nem cafoltad, csak irtad, hogy nem igaz. Ez ugye nem cafolat, hiszen nincs indoklas. En peldat is irtam, ahol latszik, hogy 7 helyett 3 utasitassal meg lehet ugyanazt oldani.
4. Ez megint kodosites. Arrol volt szo, hogy ha keves regisztered van, es kifogysz beloluk, akkor kenytelen vagy memoriaba irni az adatot. Erre irtad te, hogy memoria operandusu muvelet regiszteresre helyettesitodik. Aha, csak lesz mellette egy memoria eleres, szal igy mindenkepp lassabb, mintha regiszterekben meg lehetne oldani.
5. Akkor ebben megegyeztunk?
6. ? Akkor mit ertesz nem jobb alatt? Minthogy sebessegrol van szo, nekem csakis az jut eszembe, hogy nem gyorsabb. De mar mondtam, hivatkozd le. Akkor nem kene itt levegobe beszelni, es az idot tolteni (amibol neked olyan keves van).
7. Akkor ebben is megegyeztunk?
'Figyelj vegyél kicsit vissza újoncstílusodból!'
'Mondod ezt az együgyüség magabiztosságával.'
Es te mondod, hogy hagyjuk a szemelyeskedest. Amugy mit jelent nalad az, hogy ujoncstilus? Ez az, aki nem hiszi el a sok hulyeseget, hanem ellentmond? Ez az egyugyuseg is sima fikazas, erv nelkul, teny, hogy nem hivatkoztad le egyiket sem. Beszolasverseny nem itt van.
'Valóban nincs sok időm, ugyanis dolgozom, értelmes emberekkel, értelmes célokért és még sok pénzt is kapok érte.
Szerinted vitatkozzam inkább veled, eredménytelenül???
A június végén megyek az USA-ba és találkozom többek közt John Crawforddal(gyerünk nézd csak meg a Google-ba kicsoda az ürge), majd megemlítem neki a gondolataid.'
? Nem maradt mas, mint elovenni, hogy kinek az apukaja erosebb?? Kepzeld, en is ertelmes emberekkel, ertelmes celokert dolgozom, es sok penzt kapok erte (es nalam ez azt jelenti, hogy sebessegre optimalizalok intel/amd/mips/ppc procikon, szal a temahoz eleg sok kozom van). Nem kell velem vitatkozni feltetlenul, eleg ha beismered, ha tevedsz ;). Es az ellentmondas nem vita. A vitaban erveket is mond az ember. Amugy Inteles csokaval nem annyira jo mostanaban dicsekedni, minthogy architekturaban elegge bukasra allnak. A marketingesekkel dicsekedhetsz, az jol megy naluk. Szal uzenem a csavonak, hogy jo lenne belehuzni, mert az emberek allnak at az amd platformra, szal nagyotmondasbol eleg, kene dolgozni is. -
perla
csendes tag
Persze, mindenki abban hisz amiben akar. De teveszmeid neked vannak. Eleg sokminden osszegyult mar az elozo hozzaszolasomban, amit te mondtal es hulyeseg. Csak sorolom:
1. Attoltesek nem lassitanak semmit
2. Intel&AMD ellenjavalja az assemblyt
3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval
4. Memoria operandusu muvelet regiszteresre helyettesitodik
5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel
6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.
7. Risc compilert nehezebb irni, mint cisc/vliw compilert.
Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz. Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel. Sokkal egyszerubb azt mondani, hogy 'nincs idom'. -
perla
csendes tag
''Az áttöltések nem lassítanak semmit''
Te irtad. Megegyszer mondom, probald ki.
''Írj te, hogy hol gyorsít ez?''
Ok. Pl:
attoltes nelkuli kod:
mov eax,1
mov ebx,1
add ebx,eax
attoltessel kod:
mov eax,1
mov ebx,1
mov ecx,ebx
add ebx,eax
Lemerheted, lassit az attoltes. Johet a te peldad.
''A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.''
? A renamingnek szerintem semmi koze a keves regiszter problemahoz. Szerinted mi koze van hozza?
''Felejtsd már el ezt a kézi optimalizálást. Mind az intel, mind az Amd ellenjavalja az assembly-t. Egy 386-os vagy egy P2-es esetén használhatsz, de 2004-ben már csak magadat fogod szívatni.''
Ezt nem tudom, honnan veszed, hogy ellenjavaljak, hivatkozd le. Azt tudom, hogy en szinte minden nap irok assembly kodot, C-ben in-line assembly, foleg sse2 gyorsitas miatt, de sajnos ahhoz kell sima x86 assembly is ugye. SSE2 nelkul nyilvan nem irnek, mezei x86-ban nagyon sok munkaval tudok csak kicsivel gyorsabb kodot irni (ha erre a gondoltal, akkor az igy van), az nem eri meg, de sse2 az tokre megeri.
''Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.''
Latom ezt nem veszi be az agyad. Ujra mondom, probald ki. Pl. a*b+b*c+c*a 2 operandusu muvelettel 7 utasitas, 3 operandusuval 5. Emiatt gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Na, ha fogalmam sincs rola, akkor fejtsd ki. Hogy tudja vajon a proci a memoria operandusu utasitast regiszteressel helyettesiteni. Ha a forras a memoria operandusu: hulyeseg, ha az adat a memoriaban van, akkor nem lehet regiszterben. Ha az eredmeny: vajon ilyenkor beirja az adatot egy regiszterbe, egy masikba meg egy cimet, hogy hova is kellett volna irni, hiszen kulonben nem tudna, hogy hogy milyen mem hivatkozasnal kell elovenni. Es ezt igy folytatja, mig el nem fogynak a regiszterek. Es utana? Ez is hulyeseg. Cachbe irodik nyilvanvaloan, az pont erre van kitalalva. Na meselj, hogy van ez szerinted?
''Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?''
Probalsz kodositeni. Arrol volt szo, hogy tobb regiszterrel gyorsabb kodot lehet irni, szerinted meg nem. De igen, mert sokszor elofordul, hogy keves regiszterbe sok adat nem fer be, valamit ki kell irni membe. Ezert lehet tobb regiszterrel gyorsabb kodot irni. Lehet, hogy te nem szoltal memoriaba irasrol, csak sajnos mas valasztasa a forditonak sincs, minthogy kiirja az adatot membe.
''1. Több processzoros környezetben a kozisztencia problémák léphetnek fel és egy túlméretezett cache visszafoghatja a rendszert.
2. Gyártási problémák - túlontúl nagy cache -> rosszabb kihozatal, alacsonyabb órajel''
Ja, ezert is raknak egyre tobb cachet a procikra. Ez full kamu. Az egesz hozzaszolasodra ez jellemzo egyebkent. De hivatkozd le. Melyik gyartonal van olyan, hogy azt mondjak, itt egy specko proci direkt kisebb cache-sel, hogy gyorsabb legyen. Nincs ilyen.
''Tudod mi az az MMX/SSE/SSE2?''
Abszolut. Tobb eve sse2-ben programozok. Az intel marketing eventeken szokott a kodjaimra hivatkozni. Mondjuk ez nem tudom, hogy jott a temaba, de mind1.
''Micsoda???
Látod a mikro kódot? Látod a futásközbeni átrendezést?
Felejtsd már el az x86-os opcode-okat, totál más zajlik a háttérben.''
Ezt nem kell ennyire misztifikalni. Egyreszt ha nagyon muszaj, akkor a mikrokodot is elo lehet banyaszni, de nem szoktam. Szepen le lehet merni a sebesseget enelkul is, tokre kimerheto, hogy az adott kodban egy ilyen memoriaba mentes es visszaolvasas mennyit lassit.
''Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le.''
? Ha jol ertem, nincs erved, inkabb fikazol. Ird be a google keresobe : ''risc vc cisc compiler'', es lasd az eredmenyt. Risc compilert egyszerubb irni. Egyforma az utasitasok hossza. Ugyanarra a feladatra nincs tobb megoldas, mint a ciscnel, nem kell gondolkozni, hogy melyiket valassza a compiler. Egyszerubb a cimzes. stb. -
perla
csendes tag
''Egy olyan processzor ami sok proci környezetre terveztek nem lassabb, mint amit ugyanabból egy procis környezetre terveztek, sőt mindegyike gyorsabb.''
Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake. Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.
Ha programoztal volna assemblyben, tudnad, hogy x86 felulirja az egyik operandust, es ha kesobb szukseged van ra, akkor extra utasitassal kell elmenteni (rosszabb esetben memoriaba). Attoltes lassit, probald ki. Ha nagyon kotni akarod az ebet a karohoz, mutass peldat, amikor nem lassit, szivesen lemerem.
Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.
''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?
Masreszt a register renaming nem helyettesiti a tobb regisztert. X db regiszterben nem tudsz X+1 adatot tartani, errol szol az egesz. Ki kell irni membe (ami szerinted regiszterbe irasra helyettesitodik??? Vicces). Membe iras (level 1 cachebe is) lassu.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
Ez megint hulyeseg. Mutass 2 processzort, amik csak a cache mereteben ternek el egymastol, es amiben a kisebb cache van, az gyorsabb. Nagyon kivancsi vagyok.
''Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.''
Nem, csak te hiszed, hogy ezeket szet kell valasztani. Annyirol volt szo, hogy szetkapja az ember a legfaszabb x86 processzorat, a riscszeru magot megtartja, rak bele tobb regisztert es nehany uj utasitast (3-4 operandusut), es gyorsabb lesz a proci. Igen, van, ahol az osszetett muvelet miatt, van ahol azert, mert nem irja felul az operandust, van ahol azert, mert nem kell kiirni membe. Tok mind1, gyorsabb lesz.
Kerdezd meg az ismeroseidtol, hogy riscre vay x86-ra konnyebb compilert irni. Nyilvan riscre. Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.
''Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam ''
Tegyel egy probat. Irjal egy akarmilyen c proggyt, forditsd le, aztan nezd meg a kodot amit kaptal. Latni fogod, hogy tele van olyan reszletekkel, amikor adat kiirodik membe, aztan visszaolvasodik. Ugye mondanom sem kell, hogy membe irni (level 1 cachebe is) jopar orajel. Szal 5% az 100 orajelenkent kevesebb, mint 1 ilyen. Szerintem tobbet fogsz talalni.
''Ez ilyen visszafele bizonyítás?''
Mit nem ertesz? Szivesen elmagyarazom.
''Na mindegy, nem akarok semmi bántót írni.''
Ne is, erveket irjal. Megjegyzem a stilusod eleg lenezo ebben a hozzaszolasban, pedig eleg sok hulyeseget irtal. Erdekes eddig meg ha nem is ertettunk egyet, de nem volt ilyen. -
perla
csendes tag
Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.
Nem tudom ertelmezni amit irtal, hogy ugyanolyan gyorsak. PPC-t nem tudom, de szerintem mind dual procira van tervezve, A64 meg multiprocira, szal nincs beloluk single-re tervezett, nem?
Ja, 3 operandusos utasitasok gyorsitjak a kodot. Latszik, hogy sose programoztal assemblyben. Tok fontos, hogy nem irodik felul egy operandus, nem kell ujra betolteni, vagy masik regiszterbe menteni, ez kezzelfoghato gyorsulast jelent. Hogy a 4 operandusu utasitasokrol mar ne is beszeljek. Pl. nem tudom hallottal-e mar arrol, hogy egy ilyen jellegu muvelet: d=a*b+c az ppc-ben 1 utasitassal vegrehajthato, es ugyanugy 1 orajel mint barmi mas. Probalj egy a*b+b*c+c*a kifejezest kiszamitani 2 es 3-4 operandusu muveletekkel, es latni fogod, hogy melyik a gyorsabb.
1. Szukseg van tobb regiszterre, megint azt tudom mondani, hogy latszik, hogy nem programoztal assemblyben. De tekintsd pl. ugy, hogy a regiszterek a 0. szintu cache, minel tobb van, annal jobb. Kulonben ennel nyilvanvalobb dolgot, hogy az x86 architecturaban keves a regiszter, nem is lehet talalni. Te ezt komolyan cafolni probalod???? Ja, taskvaltasnal trade-off van, ezert van optimalis meret, nem kell ezer regiszter. Eleg mondjuk 32.
2. Ez igaz, ilyenkor a l1 cache-be toltest lassitja.
3. Latod, hogy tudtam. 3 operandusu muvelettel es tobb regiszterrel. Illetve igazabol 'felesleges' utasitasokat sporoltam meg ezekkel. Egyebkent nyilvan nem az IPC fog vissza, az csak meri a proci egy jellemzojet, nem meghatarozza.
4. Azzal valoban nem, az olyan amilyen. Mondjuk azt azert el lehet erni, hogy ugyanannyi ido alatt tobb adatt toltodjon fel a cachekbe. Masreszt van ez a data stream cucc a ppc-kben, hogy ha folytatolagos cimrol kezdesz olvasni a memoriaban, akkor elkezdi neked a proci elore behozni a cachebe.
Nemnem. A peldam jo, egy csomo tranyot kidobtam, amikor csak a magot tartottam meg, par regiszter meg par utasitas siman kitelik belole. Es forditot csak x86-ra meg itaniumra nehez irni, riscre sokkal egyszerubb, ez is egy elonye, csak eddig errol nem volt szo, mert nem a hardverhez kapcsolodik.
Amugy eddig azt magyaraztad, hogy risckel kozelebe se jutok az x86-nak, mostmar visszakoztal, hogy szignifikans kulonbseget nem tudok osszehozni. Egyreszt ez a nem szignifikans kulonbseg szerintem akar 20-30% is lehet (ki lehet probalni G5-on csak 4-6-8 regiszter hasznalataval mennyivel lassabb kodot lehet irni, es amikor rajossz, hogy hoppa, ki kell irni a memoriaba az adatot, mert nincs tobb regiszter, akkor kiderul, hogy mennyit lassit), masreszt mivel kidobtam a procibol egy nagy reszt, valszeg magasabb orajelet is el lehetne erni, harmadreszt ez 0 uj otletet tartalmazo megoldas, szal ha meg 1-2 evet belefektet az ember a tervezesbe, nyilvan egyeb gyoritasokat is kitalal, es nem csak egy siman lemasolt procit krealna. -
perla
csendes tag
Persze, a tobbiek is okosak. De mondjuk azok mas celu processzorok, szal nem gondolnam, hogy az osszehasonlitas valamennyire is erdekes. Szal egy olyan procit, ami csak single proc uzemmodban mukodik, nem erdemes egy olyanhoz hasonlitani, ami 64 procis kornyezetben is mukodik.
Fejtsd ki legyszi, hogy milyen elvi oka van, hogy egy risc proci gyorsabb legyen, mint egy p4. Kulonosen, mert hiszen tudjuk, hogy belul riscszeru magja van, szal igy mar lehetne rogton olyan procit csinalni, ami ugyanilyen gyors, es risc, ha ennek a magjat vesszuk (igaz, az nem x86 kompatibilis). Megszorjuk meg par 3 operandusu utasitassal ill. sok regiszterrel, es maris gyorsabb (es meg az utasitasok mikroutasitasra bontasat is megsporoltuk -> rovidebb pipeline, vagyis egy pipeline stall koltsege kisebb -> meg gyorsabb). Tessek, ez egy recept a gyorsabb risc procihoz. -
perla
csendes tag
Bocs, felreertettel. ''Helyesen 'nem x86''' alatt azt ertettem, hogy amikor eddig arra hivatkoztam, hogy a risc mennyivel jobb, stb., az azt jelentette, hogy a 'nem x86' mennyivel jobb.
Nem hiszem, sokkal jobb lenne. Eddig egyetlen jo erv nem volt a mellett, hogy az x86 miert lenne az abszolut sebessegkiraly irany (nem is az). Persze, az Intel meg az AMD mernokei fasza csavok, es mara nagyon kiraly procikat hoztak ossze. (Nagyon sok penzert, amin sokkal gyorsabb nem x86-os procit lehetett volna fejleszteni). Igen, a kompatibilitas a legnagyobb ertek, ezert is mehet a sebesseg rovasara.
Igen, Itanium teljesen mas megkozelites. Miert csinaltak igy, es miert nem x86 az is? Mert megprobaltak valami gyorsat csinalni, es ugy gondoltak (ahogy en is, de te nem), hogy azt nem x86 alapon lehet megcsinalni. -
perla
csendes tag
Ez a ketto osszefugg. Az x86 processzorok (a kompatibilitas miatt) ossze-vissza allitgatjak a flageket, es emiatt szopatjak a pipelinet (illetve a branch predictiont). De errol mar volt szo korabban. De nezd meg pl., hany orajel kell a flag allito utasitasokhoz (pl. shift, rotate).
Hulyeseg, hogy mindig riscet mondunk (mondok), amugy helyesen 'nem x86'. Hogy ne legyen felreertes, mar mondtam ugyan, szal nem arrol van szo, hogy a mostani x86 procik szarok, eppen ellenkezoleg, de sokkal faszabbak lennenek, ha nem x86-ok lennenek. Meg az itanic is jo pelda erre, az Intel szerint is szopat az x86 architectura, az itanium nem is arra van optimalizalva. -
perla
csendes tag
1. Nyilvan arrol van szo, hogy egy hasonlo teljesitmenyu risc proci kevesebb tranzisztorbol all, mint egy cisc vagy vliw stb.
USP-IV - ez 2 USP-III corebol all, az USP-III-ban a logic 11 millio tranzisztor
PA-8800 - ez ugye ket PA-8700-as corebol epul fel +cache, a core-ok 25 millio tranzisztorbol allnak
Tobbirol nem talaltam egyertelmu adatot, ha te talalsz, legyszi ird ide.
2. Nem tudom itt mire gondolsz. Szerintem nagyreszt az hatarozza meg, hogy sikerult-e egy chip, amikor a tranzisztorokat kialakitjak. Logikus modon a nagyobb meretbol nagyobb hibaszazalek adodik, raadasul egy szeletre kisebb szamu chip fer. Ezekbol az kovetkezik, hogy kisebb chipet ugyanolyan technologiaval olcsobb gyartani.
Ja, az x86 processzorok hasonloak, mint a riscek, van egy risc magjuk, meg a hulye korites. Pont a hulye korites az, amit ki kellene dobni. Amugy nem is ertem, hogy ezen miert vitatkozunk. Jozan paraszti esszel: az x86 architecture korlatozas, kereteket, szabalyokat szab. Vajon egy korlatozas nelkul vagy azzal egyutt lehet a gyorsabb procit epiteni? Nyilvan a korlatozas nelkul. Na errol van szo. Az SMT-nek meg CMP-nek nincs koze az x86 vagy nem x86 kerdeshez. -
perla
csendes tag
1. Egy risc proci kisebb (most a cacheket hagyjuk). Mitol lenne nagyobb?
2. Ha minden egyforma (technologia, csikszelesseg stb.), akkor ugyanazert a penzert a kisebb lapkameretubol tobbet lehet gyartani.
Persze, csak nem a felso kategorias processzorokon van a haszon. Nyilvan nem akkor kaszal a ceg, amikor meg a fejlesztesi koltseget termeli vissza.
Pl. egy mostani Celeron proci arat szerinted mi hatarozza meg? Szerintem foleg az eloallitasi koltseg es a piac. Fejlesztes mar nem nagyon jatszik.
Mar volt szo rola, de nem ugyanazok a gondok. Pl. egy risc procinal nincsenek olyan nagy gondok, mint az x86 pipeline szopato flagallitasai. Szerintem ha riscet fejlesztettek volna, akkor mar most 4-5 gigahertznel tartananak, es teljesitmenyben meg legalabb 2x-nel. Az intel nem ezert nem csinalt riscet, hanem mert azt nem tudta volna eladni, az x86-ot meg igen. -
perla
csendes tag
Vajon az Itanium es egy risc proci fejlesztesi koltsegei hogy viszonyulnak egymashoz szerinted? Nyilvan a risc olcsobb. Masreszt egy kisebb lapkameretu proci hosszutavon is olcsobba bir valni a nagyobb kihozatal stb. miatt. Es igaz ugyan, hogy az eladott kb. 18 db Itanium procinal a fejlesztesi koltseg dominal, de egy piacvezeto procinal mar sokkal jelentosebb az eloallitasi koltseg (mint az Itaniumnal, nyilvan a fejlesztesi koltseg sokaig meghatarozo az arban).
Amugy mit ertesz 'a risc' alatt? Szerintem csak siman risc van, es termeszetesen nem ugyanazok a gondok vele, mint az x86-nal. -
perla
csendes tag
Hat annyiban igaz, hogy nem x86, de szerintem gyorsabb lenne, ha riscet fejlesztettek volna, es nem is kerulne annyiba az eloallitasa.
Nagy teritett betlit ad elo az Intel minden szinten. Itanic bukta, sok fejlesztes lelove, es meg egy kurva 800-as fsb-s xeont se tudnak osszehozni a fiuk, nemhogy 64 bitet. Persze a bemondasok mennek, marketing mukodik, de ennyi. Sose volt nagyobb eselye az AMD-nek az eloretoresre, mint most. -
perla
csendes tag
Ebben azert sok csusztatas van. En allitottam, hogy az x86 kompatibilitas visszafogja a procik teljesitmenyet. Azt is, hogy a G5 simd-ben gyorsabb a tobbi procinal, de a kettot csak te kototted ossze. Arrol volt szo, hogy x86 nelkul faszabb procit lehetne csinalni. Nem csinalt meg senki ilyet. A G5 csak egy pelda, amilyen iranyba lehetne menni, de messze nem tart ott (csak simd-ben), mint mondjuk az opteron. Volt mar errol szo, ennek egyszeru oka, hogy a jatekok okan nagyon sok penz megy az intel/amd/ati/nvidia cegek fejlesztesi budgetjebe.
-
perla
csendes tag
1. Ja, ok, ugy ertem, x86-hoz nincs koze. Amugy ja, hat a rambus egy nagy beszopas volt (annak ellenere, hogy ebben a gepben is rdram van, amin ezt irom). Ez sokszor elofordul, hogy valaki kitalal valamit, es probalja a tobbieket lehuzni, erre azok szarnak ra, es fejlesztenek mast.
2. Nem tudom, hova akarunk itt eljutni. Igen, az a64 jol futtatja az x86 kodot. Amugy a p4-ek is egesz jol, csak az a64 jobban. Bar a pentium M is egesz jol futtatja. Ettol meg x86 nelkul szebb es gyorsabb a vilag.
5. Itt nagyon elbeszelunk egymas mellett. Annyit tudok mondani, hogy www.top500.org. Ott megtalalod a linkeket a szuperszamitogepek oldalaihoz. Van ahhol talalsz informaciot a szuperszamitogepek mukodeserol is. Ha megnezed, latod, hogy a kis pc potyogott programok nem is futnanak ezeken. Szal ugy kell a proggykat fejleszteni, hogy az adott gepen futtassad. Mi ez, ha nem optimalizacio?
Kevered az informatikust a programozoval. A Fritz 1.0 nem ismerem, de nem lehet, hogy algoritmikus szinten is mas volt?
Nem tudom, nekem ugy altalaban az az erzesem, hogy meg sose lattal cpu clustert, nem is hasznaltal. Ebbol adodnak az ilyenek, hogy ''A G5 vonatkozasaban ez pl. azt is jelenti, hogy amennyiben tudna fogadni a megfelelo interface eszkozoket''. Nyilvanvalo, hogy egy cpu clusternek nem feladata interface eszkozoket fogadni. Nagy sebessegu halozat kell inkabb, es a specko interfaceeket meg mashova teszed. Az meg, hogy a cpu cluster milyen altalanos cpukat tartalmaz, azt meg a feladat valasztja ki. Ha simd feladat van (amihez tok jo konyvtarak leteznek), akkor g5 a legjobb valasztas. Ennyirol van itt szo. -
perla
csendes tag
1. ? Az rdramnak mi koze a kompatibilitashoz? Szerintem semmi. Amugy tobb mellekvagany is van/volt, van amelyik a kompatibilitasi uton (pl. a topikindito cikk is errol szol), van amelyik nem (pl. itanium).
2. Ez igaz, marmint hogy sse2 stb.-t nem korlatozza. Tobbi reszet a procinak igen. Szal ez azt jelenti, hogy ha nem optimalizalsz (pl. siman c-ben programozol), akkor azok korlatozva lesznek, ha optimalizalsz akar optimalizalt konyvtarak hasznalataval, akar sajat koddal, akkor nem leszel korlatozva.
3. Persze, ezt abszolut nem huzza vissza. Itt csak arra probaltam utalni, hogy a SIMD a legjobban a 3 kozul a G5-ben van megoldva, masodik a p4, harmadik az amd64.
4. Ok, tovabbra se ertem, hogy jott a sznobsag a proci sebesseghez. Meg ez, hogy valaki villogott vele, nekem azt jelenti, hogy hallottal mar rola. De nem hasznaltad, nem fejlesztettel ra, szal nem tudod osszehasonlitani massal. Nyilvan, ha nem igy van, akkor visszavonom, bar szerintem ha valaki kiprobalja a G5 simd extensionjet es osszehasonlitja a p4-evel, akkor egyreszt le kell essen az alla, meg akkor tudnia kell, hogy mirol beszelek.
5. Nem gondolnam, hogy kivulallo vagyok a temaban, epp kepfeldolgozassal foglalkozom, es epp sse2 meg altivec optimalizalast csinalok, sima 2 processzoros gepeken meg 16-32 processzoros clusteren. Nem erzed butasagnak, elfecserelt idonek szuperszamitogepen nem optimalizalt kod futtatasat? Amugy az oke, hogy az egyet merek, kettot osztok feladathoz nem kell tul nagy szamitasi teljesitmeny, es a ganyolt program is megoldja (es ettol ez meg lehet tok tudomanyos, szamtalan olyan tudomany, illetve feladat van, amihez nem kell szamitasi teljesitmeny). Pl. Idojarast szimulalni viszont nem fogsz igy. Real-time kepfeldolgozasi feladatok se mennek igy. Amennyire en tudom (bar szuperszamitogep nem volt meg a kezemben, de cluster igen) szokas valamilyen api-t hasznalni, amiben optimalizalt fuggvenyek vannak, amit a kododban hasznalhatsz. Ily modon a kodod is optimalizalt. Amugy nem is ertem, minek allok le ezen vitazni. Azt akarod nekem bemeselni, hogy senki senmmilyen feladatra nem hasznal optimalizalt kodot? Ez nyilvanvalo hulyeseg. Szerinted soha senki nem hasznalt meg sse2-t? De meg csak egy libraryt se, ami optimalizalva volt? Es en fantazialok? Az, hogy te nem hasznalsz, az nem jelenti azt, hogy mas se hasznal. Tok sok optimalizalt library van. Akar ha csak egy FFT-t nezek, szerinted mindig mindenki leall ezt ujra megirni, vagy hasznalnak egy mar letezot? Ha esetleg letezot hasznalnak, akkor vajon egy gyorsabb, simd utasitasokat hasznalot fognak hasznalni, vagy direkt egy lassabbat? Ehh...
6. Ok, vilagos, en is erre gondoltam, azt hittem, valamirol kimaradtam. Mondjuk erdekes, hogy itt talalsz peldat, amit clusteren erdemes futtatni, bar gondolom, hogy szerinted itt se hasznal senki sse2-t, ugye? -
perla
csendes tag
Tobb dologgal nem ertek egyet.
1. Ezek a nullarol indulasrol kozhelyek. Ha megnezed az Intelt, hogy mennyi mellekvagany volt az utobbi idoben, ami nem lett sikeres, vagy amit becanceltek, lathatod, hogy tobb nullarol indulas is kitelik belole.
2. Igenis az x86 kompatibilitas visszahuz. Akar a mar emlitett bonyolult flagrendszert nezed, ami szopatja a pipeline-t, akar egy csomo mast, ezek nelkul igenis dramian gyorsabb es olcsobb procit lehetne csinalni. Es nem tudsz olyat csinalni, hogy ezt megkerulod, illetve egy modon, sse2 hasznalataval.
3. Ezzel spec egyetertek, legnagyobb igeny x86 procikra van, illetve azon belul minel nagyobb jatek es multimedia teljesitmenyre (a jatek meg logikusan 3d-t is jelent). Jo ideig ez a jovo, errol szolt a dobozba zartsag.
3. Intel es media kodolas, ez ugye az sse2. Hogy most a G5 hasonlo-e vagy nem, azon lehet vitatkozni, az a kozos, hogy mindketto simd, es ezutan ki is merult. Ennek spec semmi koze nincs az x86 architekturahoz, ez mindket prociban extension. En mind2-t hasznalom, a G5-os szinte mindenben jobb. Hogy mondjak peldakat: adatok reorganizalasa sokkal jobb, vegezheto muveletek (arra gondolok, hogy a G5 utasitasai nem destruktivak, tehat tudsz olyat csinalni, hogy a forrasoperandusok megmaradnak, mig sse2-ben az egyik felulirodik), sebesseg (G5-ben egy v4=(v1+v2)*v3 jellegu muvelet 1 utasitas, sse2-ben minimum 2, de az adat fuggoseg miatt meg szopatod is a procit, illetve a G5 orajelenkent tobb utasitast is vegre tud hajtani, p4 nem). Az egesznek az a lenyege, hogy G5-re sokkal gyorsabb kodot lehet irni.
4. Sznobsag nem tudom, hogy jott ide. Ezt gondolom az mondatja veled, hogy nem ismered a G5-ot, es ezert ha valaki azt dicseri, arra azt mondod, sznob, mert amugy amit mond nem hiszed el, szal nyilvan aki mondja, elfogult.
5. Ez tokre nem igy van a tudomanyos programokkal kapcsolatban. Igen, van ilyen amit te mondasz, es van olyan, amikor pont a szamitasi teljesitmeny a lenyeg, vagy legalabbis kulcsfontossagu. Gondolj pl. titkositasra, kepfeldolgozasra, barmire, amihez nagy szamitasi teljesitmeny kell. Minek epitenek szuperszamitogepeket? Gondolod, hogy elkoltenek ra a nepek egy csomo penzt, es utana nem optimalizalt programokat futtatnak rajta? De egyebkent az elozonel is szetvalasztanam, hogy x86 (vagyis az architektura), illetve athlon 64/p4 (vagyis egy-egy megvalositas). Ugyanis, legalabbis szerintem, az x86 nem tul jo erre (nem tul optimalis, egy risc valszeg jobb lenne), a megvalositasok viszont tenyleg tok jok, vagyis pl. az athlon64 olyan faszan valositja meg az x86-ot, hogy az kikompenzalja az x86 korlatjait. Nem tudom, ertheto-e amit mondani akarok.
Mit jelent neked az opteron erosen javitott szerver teljesitmenye? Azt, hogy 8 procit is lehet egy gepbe tenni? -
perla
csendes tag
Esz nelkul fikazni? Te mirol beszelsz? Szerintem olvasd el, amiket irtam, mielott beszolsz, mert igy te magad tunsz eretlennek. Ez amit ide irtal, tok kamu szoveg. Idezd be, milyen alkalmat teremtettem, amikor nem volt? Mi volt az esz nelkul fikazas (ami nem volt megindokolva)? Semmi. Ugyhogy a reszedrol ez egy erv nelkuli beszolas volt. Ez az ami nem produktiv es ovodas (ha mar igy elmentunk szemelyeskedesbe).
-
perla
csendes tag
Latom, nem nagyon latod at a dolgokat. Pont azert van a doboz, mert ez adhato e a piac 99%-an. A faszik (intel es amd is) tele vannak egy csomo otlettel, latjak, hogy milyen fasza procit tudnanak csinalni, es az x86 visszahuzza oket. Igy a nagyon kiraly otletekbol meg a sok munkabol epp hogy egy kicsivel jobb procit sikerul osszehozniuk (legalabbis ahhoz kepest, amit x86 nelkul tudnanak). Rohoghetsz rajta, de ez a valosag. Vagy szerinted ha nullarol indulnanak, egy ilyet tudnanak csak osszehozni, mint az x86? Fraszt, sokkal jobbat, ok se hulyek. De muszaj ezt csinalniuk, mert ez kell a nepnek. Hiaba probalkoznak, hogy masfele tereljek oket, a piac (ami x86-ot akar) visszahuzza oket. Ez a doboz.
Ja ezt valojaban DcsabaS 217-es hozzaszolasara irom.
[Szerkesztve] -
-
perla
csendes tag
Hat ezekben teljesen igazad van. De mondjuk ennyi erovel azt is mondhatnank, hogy ne vegyen senki 3 gigas p4-et mert a 2 gigas mindenre eleg. Es ez amugy igaz is. Kiveve a jatekok. De amugy az koztudomasu, hogy ezt az egesz intel/amd/nvidia/ati vilagot a jatekok mozgatjak. Ebbol a szempontbol meglepo is, hogy a G5 ennyire fasza. Nezzuk csak meg az SGI-t vagy az alfat, sunt stb. Ok nincsenek benne ebben a jatek bizniszben, le is maradtak szepen, pedig valaha ok voltak a janik.
-
perla
csendes tag
? Nem ertelek, hiszen mindenki arra hajt, hogy melyik proci gyorsabb. Igen, ezen az egy teruleten, hogy melyik proci a gyorsabb, a G5 a nagyon jo, a tobbi meg szarabb. Nem azert vesz senki intelt vagy amd-t, mert azok a leggyorsabbak, hanem mert elsosorban x86 kompatibilisek, masodsorban meg mert azokra vannak optimalizalva, vagy egyaltalan a proggik. Amugy a G5 annyira fasza, hogy gyakorlatilag akarmilyen proggit irsz, G5-re meg lehet irni gyorsabbra. Hogy veszik-e a faradtsagot, az mas kerdes.
-
perla
csendes tag
Pedig szerintem ertheto volt. Azt mondtam, hogy a G5 jobb technologia, mint az x86, ennek ellenere nem olyan nepszeru, mar irtuk meg. Egyben tudomanyos szamitasra gyorsabb is. www.top500.org. Itt egyfajta benchmarkot hasznalnak (ami linearis egyenletrendszert old meg). Mas hivatalos forrast nem ismerek, de azt tudom, hogy mennyivel gyorsabbak a procik, mert probaltam. Illetve opteront nem probaltam, de eddig akarhany benchmarkot lattam, az opteron lassabb a xeonoknal sse2-ben. De majd kiprobalom azt is, hogy sajat szememmel gyozodjek meg rola.
-
perla
csendes tag
Miert gondolod, hogy nincs ertelme hasonlitgatni?
Amugy, ha figyeltel, en is pont azt mondtam, hogy a G5 faszabb nagyon sok szempontbol, es megse ezt hasznaljak az emberek, mert kevesbe fontos, hogy amit hasznalnak, az belul zsenialis, sokkal fontosabb, ha olcsobb ra fejleszteni, uzemeltetni, egyaltalan a kivant funkciot megvalositani. Lasd korabbi hozzaszolasaim. -
perla
csendes tag
Nem ertem, osszekevered a dolgokat. Szal a P4 szerinted nem kompatibilis visszafele?? Dehogynem, full kompatibilis. Masik dolog, hogy lassabbak rajta bizonyos kodok. De ez csak orajel/orajelre igaz, abszolut ertelemben nem. Harmadik dolog, hogy mire van optimalizalva. Arra van, hogy nagyobb orajelet lehessen vele elerni, es igy legyen gyorsabb, mint az elozo.
A masodik reszben full igazad van. Annyit tudok hozzatenni, hogy ezek a cegek bezartak magukat az x86 szuk kis dobozaba, es azota sem tudnak kijonni. Hidd el, ha valahol ki tudnanak jonni, mar reg hagytak volna a francba az egesz x86-ot. -
perla
csendes tag
Ja, valoban, az amd mindig elorebb jart ebben. Annak mar csak annyi gondja van, hogy a G5 meg mindig kurvara megveri SIMD-ben, meg kicsit megveri memoriasebessegben. De amugy nem rossz, valoban. Csak az szomoru egy kicsit, hogy a G5-nek ehhez fele annyi tranzisztor kell, meg hogy sokkal hamarabb volt (es megse kellett annyira hypolni, hogy 64 bites).
-
perla
csendes tag
Azert lasd be, hogy ennel a ganyolasnal elragadtattad magad ;). Szal jo, hogy szar az x86 architektura, de errol szo sincs, hogy ugyanugy lenne megoldva ma is a kompatibilitas, mint 20 eve. Amugy szerintem nem is az a baj, hogy a procinak van egy pici resze, amitol kompatibilis (bar teged valamiert nagyon zavar az az 1-2 watt, amit ez fogyaszt), hanem a tobbi. Pl. miert van ilyen keves altalanos celu regiszterem? Miert van ilyen bena vermes FPU-m (amiben szinten keves hely van)? Miert van csak 8 sse2 regiszter? Szerintem ezek a nagy hulyesegek. Mert jo, hogy a regi proggiknak kell ez a par regiszter, de az ujaknak miert nincs meg 16 masik?
-
#163
perla
csendes tag
Don Vittorio
#157
perla
csendes tag
válasz
Don Vittorio
#157
üzenetére
Ez annyiban igaz, hogy ha a nyers ero a sima kodokat jelenti, akkor valoban nem gyorsabb, ha meg a Velocity Engine-t hasznalod (tehat pl. videozol/effektezel/matrixozol/Fourier transzformalsz stb.) akkor brutalisan sokkal gyorsabb.
-
perla
csendes tag
Mindenfele tudomanyos szamitasnal, amikor cpu-ra van szukseg, nem masra (pl. memoriasebessegre). Mert ha memoriasebessegre van szukseg akkor csak 20-30%-kal gyorsabb. De az AltiVec vagy Velocity Engine ha igy jobban tetszik, ami az sse2 G5-os megfeleloje az sokkal jobban van megvalositva, ertsd ezalatt, hogy sokkal gyorsabb (3-4x).
-
perla
csendes tag
Meg valami eszembe jutott, a cikkel kapcsolatban. Irtak, hogy 24kbyte adat es 64kbyte trace cache. Legjobb tudomasok szerint a mostani procikban 12k bejegyzes van a trace cacheben, ami valojaban 80 kbyte (256 set, 8 utas, egy line 40 byte, ami 6 utasitas, 53 bit/utasitas), szal a 64kbyte az gondolom eliras, hiszen az kevesebb lenne, mint ami most van. Amennyire en tudom, 16k-ra akarjak fejleszteni, es az ugy epulne fel, hogy 512 set, 8 utas, 32 byte egy line, ez 4 utasitas lenne, vagyis 64bit/utasitas. Ez osszesen 128kbyte. Illetve ami meg kulonbseg, hogy a mostani trace cache orajelenkent 3 utasitast tud megtalalni, a tervezett uj meg 4-et.
-
perla
csendes tag
En nem ertek veled egyet a tervezest illetoen. Miert jo az, ha tervezel egy zsenialis procit, es a celkozonseg olyan progit futtat rajta, amire nincs optimalizalva, vagyis lassabban fut a progi rajta, mint az ellenfel szoftverhez tervezett procijan? Lehet, hogy tudomanyos szempontbol jobb a proci, de gazdasagilag meg csod.
Amugy abban egyetertunk, hogy az x86 architektura az egy nagy szopas. De ezt amugy az Intel meg az AMD is tudja, megis ilyen procit gyartanak, pont azert, mert a jonep ezt akarja. Szal akkor ok szerinted alapveto hibat kovetnek el (hiszen azert terveznek ilyen procikat, hogy a mostani szoftverek fussanak rajta)? Ez nagyon nem igy van. Kiprobalt teny, hogy az emberek a most mukodo alkalmazasaikat nem nagyon akarjak ujraforditani, atportalni mas platformra. Amugy altalaban olcsobb is tobb hardvert venni, mint egy uj platformra portalni. Ugyhogy ez egy masik erv a nem szoftverhez tervezett cpu ellen.
De mondok egy tok szemleletes peldat: hany G5 clustert lattal mar? 1-2-t esetleg. Hany Xeon clustert lattal mar? Szazaval lehet talalni. A G5 procik nagyjabol 3-4-szer birnak gyorsabbak lenni, mint a leggyorsabb Xeonok, ha szamitasi teljesitmeny kell. Akkor vajon miert van ez? Szoftver kompatibilitas miatt. Szal lehet fasza procikat tervezni, de muszaj figyelembe venni, hogy a felhsznalok mire akarjak hasznalni (ertsd ezalatt, hogy milyen szoftvert futtatnak rajta).
Ja meg valami eszembe jutott. Szal az x86 a 'hagyomanyok' miatt szopas, de azert eleg sok jo otlet van benne (marmint a mai procikban). A G5-ot amugy tok fasza procinak tartom, de a direct mapped level 1 cache azert vicces. Ilyet x86 procikban nem talalsz. Meg a float to int konverzio... Az is vicces. Vagy az SGI-os vonal, a MIPS processzorok, R10k,12k,14k. Hat azok is katasztrofalisak. Valahol el kene gondolkozni, hogy amikor egy 8 procis Onyxot egy 2 procis Xeon lenyom (meg egy single G5), akkor ott valami baj van. Szal lehet azert sok jo otletet talalni az x86-os procikban.
Aktív témák
Hirdetés
- Linux kezdőknek
- Gmail
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Linux haladóknak
- Pokoli repetát hoz az új GeForce driver
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- Elkezdtek szállingózni az Arctic P Pro sorozatú ventilátorai
- Mobil flották
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Fűnyíró topik
- További aktív témák...
- AMD Ryzen 7 5700X3D - Új, 1 év garancia - Eladó!
- Intel Core i7-7700K (8M Cache, up to 4.50 GHz) OEM Processor! 27% számlával!
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
- Intel Core i7 10700 - 4.8 GHz - 8mag/16szál - Eladó!
- ÚJ Intel Core Ultra 5 245KF 4,2GHz 24MB LGA1851 BOX 3év
- Új! Számla + 1-3ÉV Gari! Áfás! Gamer PC - Számítógép! R5 8400F / RX 9060XT / 32GB DDR5 / 1TB SSD M.2
- PlayStation Plus Premium 24 hónapos előfizetés , egyenesen a Sony-tól!
- BESZÁMÍTÁS! ASRock B460M i5 10400 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA TT 500W
- AKCIÓ! Apple MacBook Pro 16 M4 Pro - M4 Pro 24GB 512GB SSD garanciával hibátlan működéssel
- Bomba ár! Dell Latitude 5430 - i7-1255U I 16GB I 512SSD I HDMI I 14" FHD I Cam I W11 I NBD Garancia!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest