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. -
Power
senior 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:''
Inkább hagyjuk a személyeskedést.
''1. Attoltesek nem lassitanak semmit''
A register renaming lassít?
Ez csupán az L/S egységek számától és végrehajtandó utasításoktól függ.
Ha nálad lassít, akkor:
a.) rossz a kódod
b.) rossz processzort használsz
Elméletileg semmit nem lassít.
A hozott példádat meg nem lehet önmagában lemérni, szóval kiváncsi lennék hogy hogyan sikerülhetett.
Ciklusban pörgetve már az átlapolódástól illetve a ciklustól már egész más a környezet, szóval torz képet ad.
A mov és az add ott is mehet egyszerre, tehát ott sem lassít.
''2. Intel&AMD ellenjavalja az assemblyt''
Ez a hivatalos álláspont.
''3. 3/4 operandusu utasitassal nem lehet gyorsabb kodot irni, mint 2 operandusuval''
Te folyamatosan kevered az utasítást és műveleteket.
Te a RISC-re írtad, hogy gyorsabb, mert 3 operandusúak az utasítások, én csupán ezt cáfoltam.
''4. Memoria operandusu muvelet regiszteresre helyettesitodik''
Pontosan. Milyen mikroutasításokat ismersz amelyek memóriacímeken végez pl. aritmetikai műveleteket.
''5. Tobb regiszterrel se lehet gyorsabb kodot irni, mint kevesebbel''
??? Ezt te írod. Én ilyet nem írtam, csak annyit hogy itt sem a minnél több a legjobb.
''6. Ugyanaz a proci tobb cache-sel lassabb, mint kevesebbel.''
Ezt megint te írod. Én csak, azt írtam, hogy a több nem biztos, hogy jobb.
''7. Risc compilert nehezebb irni, mint cisc/vliw compilert.''
??? Ember te folyamatosan ferdítesz!
Én azt írtam, hogy nem könnyű RISC-re sem:
''Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani''
Nem tudom ebből honnan veszed, hogy vliw-re, vagy cisc-re milyen?
Egyébként el vagy tévedve, ha az x86-ot cisc-nek tekinted.
''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. ''
Nem tudom honnan jön ide az egyforma utasításhossz vagy a többfajta címzés???
Nem a compiler működőképességében van a munka, az 1-2 hét alatt összehozható. Hanem hogy optimális kódot fordítson, na ahhoz sok-sok év kell.
x86 esetén sincs több megoldás, elégg rég óta 1 féle megoldást fordítanak adott feladatra. Tulajdonképp a RISC is emiatt fejlődött ki, ugyanis az akkori jó CISC fordítók is egyfélét fordítottak.
Egyébként a mai RISC-eknél sincs már egyforma utasításhossz.
Egyszerű címzés? pl. PA-RISC egyszerre támogatja mindkétféle endian-t.
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt elküldöm az inteleseknek, ők is szórakozzanak egy kicst :)
''Ezek a te teveszmeid. Nem kijavitani nincs idod, max utananezni vagy lusta, hogy hol tevedsz.''
Figyelj vegyél kicsit vissza újoncstílusodból!
''Nyilvan nem tudtad egyebkent ezeket lehivatkozni, hiszen ezek hamis allitasok, csak nehez beismerni, hogy tevedtel.''
Mondod ezt az együgyüség magabiztosságával.
''Sokkal egyszerubb azt mondani, hogy 'nincs idom'.''
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. -
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. -
Power
senior tag
''Nincs benne, hogy riscrol lenne szo, hanem az, hogy mindegyik. Nezzel mas benchmarkot is, pl. quake.''
Ne gyerekeskedj!
Az IBM vagy a SUN esetleg az Intel szerver részlege szerinted a quake-re tervezi a processzorokat???
''Masreszt meg olyat nezz, ahol hasonlok a cache meretek. Ajanlom a p4ee-t.''
A P4EE egy áttokozott Xeon.
''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''
Mire?
Te írod állandóan, hogy gyorsít. Én ezt vitattom. Írj te, hogy hol gyorsít ez?
A későbbi szükségletekre ott a renaming, az átöltés párhuzamosan megy.
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.
''Nem keverek semmit, te nem olvasod el amit irtam. Nem volt szo a miertrol, csak arrol, hogy gyorsit.''
''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.''
Nyílvánvaló, hogy nem a 3/4 operandus gyorsít.
''Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Fogalmad sincs róla. :)
''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.''
Én nem ezt írtam. Én nem írtam egy szót se a memóriába írásról.
Nem olvasol figyelmesen vagy nem érted?
''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.''
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
''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.''
Tudod mi az az MMX/SSE/SSE2?
''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.''
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.
''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.''
Ezen már mosolyogni sem tudok.
Te vagy 14 éves vagy vagy menthetetlen.
Szerintem itt zárjuk le. -
''Mellesleg x86-ra kezzel mindig gyorsabb kodot irok, mint az intel compiler.''
Ezt lemérted? Érdekelne. Manapság nagyon sok szabályra kell figyelni. P6 óta már nem vagyok biztos abban, hogy jobbat írunk kézzel, tekintve, hogy nem publikus a belső.
Sajnos nincs intel compilerem (csak májkroszoft), szóval nem tudom kipróbálni.
''''Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.''
Ez hulyeseg. Akarod tovabb ragozni, vagy maradjunk ennyiben?''
Én el tudom képzelni, főleg, hogy a P4 már lefordított kóddal dolgozik. Simán meg lehet különböztetni fix és változó címeket.
Régen én is hasonlóan gondolkoztam...:))
Igaz Power?
[Szerkesztve] -
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. -
Power
senior tag
válasz
kisfurko
#297
üzenetére
''Ez igaz, de nem mindegy, hogy 8 regiszterre kell trükközni, vagy minimum 32-re. Meg az sem mindegy, hogy kétoperandusú vagy több. Mert kétoperandusúhoz több regiszter kell. A flagekről meg csak annyit, hogy sokszor tök feleslegesek (mert részszámítás), nyugodtan lehetne szabályozni, hogy mikor kell. Egyébként nem RISC/CISC összehasonlítást kell csinálni (hiszen manapság nincs igazi CISC), én is, mint perla x86 vs. jobb.''
A 3 operandusú nem is működne kevéssel ott lenne csak nagy baj, ott már eleve ezért is több van. Az igaz, hogy a renaming regiszterből ehhez viszonyítva már nem kell annyi.
Ahhoz viszont, hogy a flageket ne állítsa új útasítás halmazok kellenek, ezeket bele lehet pakolni.
Az x86 vs. bármi. Itt egyedül a bármi, ha az risc akkor jobbat vitatom.
''Ezt azért nehezen hiszem, nem véletlen, hogy a K8-ba is duplaannyi regisztert raktak.''
Itt adatfüggőségről beszéltem, nem regiszter függőségről. -
Power
senior tag
''Tenyleg nem lassabb? Xeon MP? Vagy akar Xeon? Ezek mind lassabbak, mint a megfelelo p4-ek. A Xeon MP meg orajelben is.''
Nem a xeon-okról volt szó, hanem a RISC-ek 1 illetve több processzoros példányai között. A XeonMP pedig igeni gyorsabb azonos órajelen, mint a sima P4.
Nyílván a Xeon-oknak a megbízhatóság miatt nem hajhatják olyan magasan, de 3 GHz-es XeonMP már van.
SPECint2K peak:
Xeon - 3,2GHz - 1563
XeonMP - 3,0GHz - 1408
P4 - 3,4GHz - 1393
Ez alapján még az alacsonyabb órajel ellenére sem lassabb, sőt.
''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?''
Ebből a szempontból tökmindegy.
''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.''
Te ezt honnan veszed, hogy én mit csináltam és mit nem? :))
Kis naiv. Már rég egész más hajtódik végre, mint amit te látsz az x86 opcodok alapján. Az áttöltések nem lassítanak semmit, csak plusz tranzisztor kérdése, regiszter átnevezés az egész. Semmit nem gyorsít.
''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. ''
Barátom te keversz valamit! :)
Itt nem a 4 operandus miatt gyorsabb, hanem azért mert kétműveletet hajt végre a VE. A három operandusú műveletek: a = b + c, ez a klasszikus RISC.
''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.''
Már megint feltételezgetsz? :)
Az x86 is van elég regiszter nem csak az amit az opcode-ból látsz. Belül egy sima memória operandusú művelet is regiszteresre helyetessítődik.
A 32 nem elég, de ennyi van az x86.
Ha jól emlékszem a P4-ben 128 entry-s a regiszter file.
''cache, minel tobb van, annal jobb''
Ez sincs így csak a mesében.
''Ez igaz, ilyenkor a l1 cache-be toltest lassitja.''
Nem mert könnyen párhuzamosítható. Az L1-L2 között késleltetés pedig még így is lassú - 10-30 órajel.
''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''
Azt hiszem folyamatosan kevered az összetett műveleket a több operandusossággal.
''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.''
Abban biztos vagyok, hogy még nem írtál compilert. :)
Én sem, de sok olyan embert ismerek aki igen. Szerintük egy RISC esetén a kb. 3-4 év után lesz jó, de kb. 8-10 év után éri azt a szintet, hogy nem nagyon van mit javítani a teljesítményen, s ezt minden egyes generációnál el kell játszani.
''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 ''
Nem visszakozok.
20-30% kizárt.
max 5%-ra gondoltam :)
''(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''
A G5 alatt a PPC970-et érted?
Ez ilyen visszafele bizonyítás? :))
Na mindegy, nem akarok semmi bántót írni.
Aktív témák
Hirdetés
- Az AI megeszi a szoftverpiacot?
- Milyen billentyűzetet vegyek?
- The Division 2 (PC, XO, PS4)
- Fujifilm X
- HiFi műszaki szemmel - sztereó hangrendszerek
- 2026-ra halasztották a Crimson Desert megjelenését
- Az Arctic (ismét) belép a házak piacára
- Milyen TV-t vegyek?
- Videós, mozgóképes topik
- OLED TV topic
- További aktív témák...
- BESZÁMÍTÁS! Intel Core i9 10850K 10mag 20szál processzor garanciával hibátlan működéssel
- AMD Ryzen 5 3600 BOX - Új, 3 év garancia - Eladó!
- AKCIÓ! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Új,bontatlan,dobozos, számlás,garanciás 7800X3D CPu.
- BESZÁMÍTÁS! Intel Core i7 6700K 4mag 8szál processzor garanciával hibátlan működéssel
- HIBÁTLAN iPhone 15 Pro Max 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3005
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- LG 65" C1 OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- HIBÁTLAN iPhone 13 Pro 128GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3026, 91% Akkumulátor
- LG 65B4 - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready
Állásajánlatok
Cég: FOTC
Város: Budapest