[Rive]

idézet:

---

Ezt írta Fiery:
Remelem, jo iranyba tapogatozok, ha egy gyakorlati peldat probalok felhozni (Rive, javits ki, ha hulyeseget irok).

Tehat jo pelda erre a C-s sin() vagy cos() fuggveny, ami elvileg vegrehajthato lenne 2-3 FPU utasitas segitsegevel (FSIN, FCOS, FMUL) -- de ehelyett a fordito alkalmazhat aka'r egyszeru 4 alapmuveletet + ciklust, 3DNow! vagy SSE utasitasokat is, attol fuggoen, hogy az operandus es az elerni kivant pontossag mit kovetel meg.[/quote]

Pontosan így van. A forrás tulajdonságai határozzák meg, hogy egy-egy függvényt, szerkezetet végülis milyen kóddal helyettesít a fordító.

Mondjuk, C-ben ez leginkább a vezérlési szerkezeteket érinti: a HC matek a FORTRAN vagy a speciális függvénykönyvtárak dolga

[Atti]

[url="http://"https://www.hwsw.hu/perl/ultimatebb.cgi?ubb=get_topic&f=5&t=000202#000011"]https://www.hwsw.hu/...t=000202#000011[/url]

[Atti]

idézet:

---

A Hewlett-Packard több évre szóló partnerségi megállapodást írt alá az AMD-vel, és bejelentette a sunnyvale-i chipgyártó 64 bites Opteron processzoraira épülõ kiszolgálóit.
...
A CNET beszámolója szerint a HP a bejelentés kapcsán tartott sajtótájékoztatón többször is kiemelte, hogy az Opteron – illetve a rövidesen megjelenõ, az AMD 64 bites technológiáját alkalmazó Intel Xeon és Pentium 4 – processzorok felkarolása nem csökkenti a vállalat Intel Itanium platform iránti elkötelezettségét. Amint az ismert, az eddig mérsékelt piaci sikereket elért, 64 bites Itanium architektúrát a HP és az Intel közösen fejlesztette. Scott Stallard, a HP szervercsoportjának vezetõ alelnöke elmondta, hogy a két eltérõ 64 bites platform jól kiegészíti egymást, sõt egyenesen azt állította, hogy a mostani bejelentés csak erõsíti az Itanium alapú Integrity szerverek pozícióját. Az elemzõk egy része azonban szkeptikus ezeknek az állításoknak a megalapozottságával kapcsolatban. [/quote]
[url="http://"http://prohardver.hu/rios3_content.php?mod=10&id=5653"]Piacon az Opteron alapú HP-szerverek[/url]

[h1ghland3r]

idézet:

---

Ezt írta Rive:


Pontosan így van. A forrás tulajdonságai határozzák meg, hogy egy-egy függvényt, szerkezetet végülis milyen kóddal helyettesít a fordító.

Mondjuk, C-ben ez leginkább a vezérlési szerkezeteket érinti: a HC matek a FORTRAN vagy a speciális függvénykönyvtárak dolga [/quote]

Azt hiszem erre pl. jo pelda a Linpack benchmark. Ennek is tobb tipusa van, mas es mas szabalyok megengedettek.

Az elso a 100x100Linpack benchmark, ahol 100x100-as random matrixok Gauss eliminaciojat kell lefuttatni (van single es double valtozat), itt a forraskod modositasa nem megengedett (meg kommentek v. pragmak szintjen sem). 128kbyte-nal nagyobb L1 cache eseten szerintem ez jol meri a processzor lebegopontos teljesitmenyet, illetve a forditoprogram kepessegeit.

Az 1000x1000Linpack benchmark eseten a forras csak annyit csinal, hogy legeneral 1000x1000-es matrixokat, az eliminaciot vegzo rutinokat externalkent kell a programhoz linkelni. Na itt mar lehet varialni.

Szerintem mind a ket megkozelitesnek van ertelme, csak tudni kell a kapott eredmenyeket ertelmezni.

h1ghland3r

[special]

idézet:

---

Ezt írta Atti:

[url="http://"http://prohardver.hu/rios3_content.php?mod=10&id=5653"]Piacon az Opteron alapú HP-szerverek[/url][/quote]

Mi van ebben a hírben, ami a hwsw-sben nincs? Excuse me...

[Atti]

idézet:

---

Ezt írta special:


Mi van ebben a hírben, ami a hwsw-sben nincs? Excuse me...[/quote]

Kb az amit beidéztem
De a lényeg ez: "A Hewlett-Packard több évre szóló partnerségi megállapodást írt alá az AMD-vel"

[ 2004. február 25.: Atti szerkesztette a hozzászólást ]

[Olasz]

idézet:

---

Ezt írta special:


Mi van ebben a hírben, ami a hwsw-sben nincs? Excuse me...[/quote]

Például tagolt, írásjelekkel MEGFELELÕEN elválasztott gondolatok, ellenben a vesszõvel tagolni probált ömlesztett kivitellel. Ezáltal van még benne lendület is; sõt tán még fogyaszthatóbb is.
Elsõ blikkre ennyi.

[hvuk]

idézet:

---

Ezt írta Rive:


Bazz! Legalább olvass vissza vagy nézz utána, mielõtt marhaságokat írogatsz.

T2k már be is dõlt, pedig õ legalább szakmabeli, ha nem is a fordítók területén
[/quote]

Tök jó, hogy felteszed, hogy én nem szakmabeli vagyok. Pedig de. Erre persze írhatod, hogy ez nem látszik, de ez meg nem igaz.

idézet:

---

Ezt írta Rive:

A fordító annyit tesz, hogy a forrás elemzése során talált alkalmazási kondícióknak megfelelõ gépi kódú megfelelõvel helyettesíti a függvényeket. Ebbõl fakadóan minden fordító minden esetben 'speciális' kódot használ. Gyakorlottabbak ránézésre megmondják, melyik kód melyik fordító mûve.
A végleges programba belekerülõ kód esetében soha nem is volt biztosított, hogy egy sima 'for' ciklusnak két eltérõ helyen ugyanolyan a kódrészlet felel majd meg.
[/quote]

Ezt is tök jó, hogy leírod, ennyit még én is tudok, de ennek mi köze van az általam írtakhoz?

idézet:

---

Ezt írta Rive:

Csalás egyedül az lenne, ha ezek az 'alkalmazási kondíciók' nem csak a kód felépítésétõl, hanem valamiképpen a program céljától is függnének, nem ellenõrizhetõ módon.

Ilyen ma nincs. Ezt elég nagy biztonsággal merem állítani: a fordítók fejlesztése ugyanis pont az alkalmazási kondíciók esetén felhasználandó kódok kidolgozását jelenti. Ez adja a fordítók lelkét, nem pedig az a vas, amin a kód futni fog. Azaz: a lopásokat csak és kizárólag a más fordítók által generált kód elemzésével lehet kiszûrni. Szûrik is, rendszeresen - márcsak tanulási célból is.

Emellett: amíg a videokártyáknál a játékokat, teszteket alig néhány ember fordítja, a SPEC programcsomagok nagy részét boldog-boldogtalan. Semennyi idõ alatt kiderülne bármilyen csalás.

Ui.: a SPEC forráskóddal terjesztett programcsomagjai - mivel összeállításuknál pont a leggyakrabban használt feladatok közül válogatnak, és ezáltal iparági standardnak számítanak - a fordítók fejlesztésében nagy szerepet kapnak. Ez azonban a legkevésbé sem azt jelenti, hogy bármelyik fordító is a SPEC-et felismerné. Nem teszi. Ugyanúgy, ahogy a többi referenciaként használatos névtelen programot se ismeri fel.
[/quote]

Megmagyaráznád nekem, hogy a fent leírtakból hogyan következik, hogy nem csalnak? Én lazán el tudom képzelni, hogy a fordító felismeri a SPEC programot, majd annak kis részleteit (fontosabb ciklusokat) elõre eltárolt gépi kóddal helyettesíti. És itt nem arról a gépi kódról van szó, amit te írsz fent, hanem arról, hogy egy teljes programrészletet egyben helyettesít a megfelelõ gépi kóddal. Ugye olyan nincs a fordítóknál, óhh nagy mester, hogy egy 30 soros ciklust egyben befordít?

Megmagyaráznád azt is, hogy mire gondolt a fent idézett volt Inteles pofa, amikor azt mondta, hogy könnyû csalni és az Itaniumnál csalnak is? Milyen más módszer lehetséges még?

[hvuk]

idézet:

---

Ezt írta Atti:
[url="http://"https://www.hwsw.hu/perl/ultimatebb.cgi?ubb=get_topic&f=5&t=000202#000011"]https://www.hwsw.hu/...t=000202#000011[/url][/quote]

Köszi szépen az infót Atti!

Beidézném ide az általad linkelt hozzászólást, mielõtt még elsikkad a lényeg. Elric nagyon szépen megfogalmazta azt, amit én egy kissé talán sete-sután próbáltam meg beírni.

idézet:

---

Ezt írta Elric:
Erasmus, sokkal konyebben, mint az ember elsore gondolna. A compilerben lehet olyan logika, ami kelloen altalanos, vagyis nem csak a SPEC tesztek eseteben tuzel, de azok eseteben biztosan. Ez a logika olyan speci optimalizaciot alkalmaz, amitol jobb lesz a SPEC eredmeny. Az meg, hogy milyen mas esetben tuzel meg, hat kerdeses, de lehet ilyen eset...
Pl. egy valodi ceg valodi compilere felismer a SPEC2000fp benchmarkok kozott egyet, ami egy specialis numerikus konyvtarat hasznal. Ebben a csomagban lecsereli a matrix copy fuggvenyt egy kezzel optimalizalt SSE2-t is hasznalo rutinra. Ez onnan latszik, hogy mas esetekben, ahol teljesen hasonlo, de nem ennek a konyvtarnak a reszet kepezo matrix copy van, ott meg MMX-et sem hasznal, pedig ugy is gyorsabb lenne a masolas...
[/quote]

Tehát csalhat ilyen módon. Mégpedig pontosan olyan szemét módon, mint ahogy az NVidia csalt több esetben is (ok, az ATi is megpróbálkozott egyszer valami hasonlóval, de az fairebb volt, az iskola példa az NVidia ).

Ja igen. Várom a mea culpát!

És még egy idézet Elrictõl:

idézet:

---

A LINPACK hackelheto hand coded assemblyvel es ott azert be kell ismerni, jobb az I2, persze a kerdes altalanossagban az, hogy ki kodol assembly-ben egy RISC/VLIW procin (rajtam kivul) [/quote]

[ 2004. február 25.: hvuk szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta hvuk:
Tök jó, hogy felteszed, hogy én nem szakmabeli vagyok. Pedig de. Erre persze írhatod, hogy ez nem látszik, de ez meg nem igaz.[/quote]

Kezdem érteni, hogy mûködik a 'fan' mentalitás text-filter/extendere

idézet:

---

Ezt írta hvuk:
Ezt is tök jó, hogy leírod, ennyit még én is tudok, de ennek mi köze van az általam írtakhoz?[/quote]

Kontextusba helyezi, miért is nem 'csalás', amit annak vélsz.

idézet:

---

Ezt írta hvuk:
Megmagyaráznád nekem, hogy a fent leírtakból hogyan következik, hogy nem csalnak? Én lazán el tudom képzelni, hogy a fordító felismeri a SPEC programot, majd annak kis részleteit (fontosabb ciklusokat) elõre eltárolt gépi kóddal helyettesíti. És itt nem arról a gépi kódról van szó, amit te írsz fent, hanem arról, hogy egy teljes programrészletet egyben helyettesít a megfelelõ gépi kóddal. Ugye olyan nincs a fordítóknál, óhh nagy mester, hogy egy 30 soros ciklust egyben befordít?[/quote]

Bazz, mi a fenét magyarázzak? Azt, hogy itt nem tíz ember fordítgat naponta, mint az egyszeri felhasználók számára összebabrált drágalátos b+markjaidnál, hanem több ezer: azt, hogy másik ugyanennyi folyamatos kapcsolatban áll a fordítóprogramok fejlesztõivel, és a legkisebb abnormális jelenséget, gyenge pontot is azonnal jelenti: esetleg azt, hogy egy vektorizáció, egy SW-pipelining, esetleg egyes matematikai könyvtárak automatikus használata ugyan mi a rákos fittyfenérõl szól???

idézet:

---

Ezt írta hvuk:
Megmagyaráznád azt is, hogy mire gondolt a fent idézett volt Inteles pofa, amikor azt mondta, hogy könnyû csalni és az Itaniumnál csalnak is? Milyen más módszer lehetséges még?[/quote]

Elõször is, nagyon helyes lenne tisztázni, miért rögtön a SPEC-re asszociálsz. Azoknak a teszteknek a nagyrésze ugyanis éppúgy nem elcsalhatók, akár a többi, helyben fordítható vagy készen kapott teszt, amik fõleg user-time -ben futnak.
A 'csalás' itt annyit jelent, nem többet, hogy milyen környezetben tesztelsz egy processzort. Pl. az elhíresült TPC-C teszt futása során a futásidõ legnagyobb része kernel-time. A kernelt szabadon hekkelhetik - hekkelik! -, akárcsak a konfigurációt.

Megjegyzem, nemrégiben is csalást ordított valamelyik hígagyú, mert az ultrabrutál gyorsítótárral szerelt I2 hirtelen minden mást lenyomott az MCF-ben, és sokkal jobban ment, mint korábban a herélt változatok. Ütõdött állat... Pont a leginkább memória-függõ tesztet kellett kiszúrnia, ami 6-8M távolságokba generál memóriahivatkozásokat :o


De: ne érdekeljen. Nyugodtan nyomd csak tovább a hülyeségeidet

idézet:

---

Ezt írta hvuk:
Tehát csalhat ilyen módon. Mégpedig pontosan olyan szemét módon, mint ahogy az NVidia csalt több esetben is (ok, az ATi is megpróbálkozott egyszer valami hasonlóval, de az fairebb volt, az iskola példa az NVidia ).[/quote]

Magyarán: még a szövegértelmezéssel is gondjaid vannak?

Faggasd már ki T2k-t, hogy ugyan mi volt az Nv csalásának a lényege, bazz!!! Itt maximum - nagyon-nagyon maximum!!! - csak azt lehet a compiler-fejlesztõk - az összes! - nyakába varrni, amit az ATI csinált - illetve, még azt sem! Itt ugyanis minden pontról pontra reprodukálható, ellenõrizhetõ, nyílt...

:o

[ 2004. február 25.: Rive szerkesztette a hozzászólást ]

[Rive]

Aki még mindig nem értené:

idézet:

---

Ezt írta Elric:
Erasmus, sokkal konyebben, mint az ember elsore gondolna. A compilerben lehet olyan logika, ami kelloen altalanos, vagyis nem csak a SPEC tesztek eseteben tuzel, de azok eseteben biztosan. Ez a logika olyan speci optimalizaciot alkalmaz, amitol jobb lesz a SPEC eredmeny. Az meg, hogy milyen mas esetben tuzel meg, hat kerdeses, de lehet ilyen eset...

Pl. egy valodi ceg valodi compilere felismer a SPEC2000fp benchmarkok kozott egyet, ami egy specialis numerikus konyvtarat hasznal. Ebben a csomagban lecsereli a matrix copy fuggvenyt egy kezzel optimalizalt SSE2-t is hasznalo rutinra. Ez onnan latszik, hogy mas esetekben, ahol teljesen hasonlo, de nem ennek a konyvtarnak a reszet kepezo matrix copy van, ott meg MMX-et sem hasznal, pedig ugy is gyorsabb lenne a masolas...

Elric[/QB][/quote]

Azaz: az alkalmazási kondíció fele ebben az esetben a matematikai könyvtár puszta jelenléte, amit minden esetben észlel, nemcsak a SPEC-programoknál.
A másik fele pedig az, hogy a hivatkozott könyvtári elem hívásának paraméterei megfeleljenek pl. az SSE lehetõségeinek. Ilyen esetben természetes, hogy a beállított optimalizálási metódusnak megfelelõ leggyorsabb primitívet használja minden fordító. Ezt ugyanis a legtöbb ilyen matematikai könyvtár is támogatja, legalább áttételes módon...

Bár, azt is hozzá kell tenni, hogy aki olyan régi könyvtárral dolgozik, amiben nincs még SSE

[ 2004. február 25.: Rive szerkesztette a hozzászólást ]

[hvuk]

Ezt közben jól kiszerkesztettem véletlenül. Így jár aki béna.

[ 2004. február 25.: hvuk szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta hvuk:
Az Elric által emlegetett cég (vélhetõleg az Intel) fordítója olyan optimalizációt tartalmaz, ami csak és kizárólag egy tesztprogramot gyorsít, abból egy valódi - még a tesztprogramhoz nagyon hasonlító - alkalmazás sem profitál. [/quote]

Pont ez a hülyeség. Az Elric által emlegetett esetben minden egyes, az adott könyvtárat használó program gyorsul - hacsak nem valami agyament formátumot használ a program írója, ami esetben tulajdonképpen tökmindegy is
(Aki ugyanis nem olvassa a fordítóhoz és a processzorokhoz mellékelt optimalizálási tippeket, az ne írjon PowerApp-ot :o )

[Atti]

Inkább kiszedem mielõtt leordítja valaki a hajamat...

[ 2004. február 25.: Atti szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta Atti:
...[/quote]

Elric írása is arról szól, hogy nem a SPEC-et, hanem egy könyvtár hívásait azonosítja a compiler. Ez nem túl elegáns, de elfogadott, hiszem mindenütt gyorsít: nem csalás. Eleve, az egész C programozói gyakorlat erre épül

Azzal ellentétben, ha mondjuk egy beállított 'SPEC' flagre izgulna a drága...

[hvuk]

idézet:

---

Ezt írta Rive:
Aki még mindig nem értené:

Azaz: az alkalmazási kondíció fele ebben az esetben a matematikai könyvtár puszta jelenléte, amit minden esetben észlel, nemcsak a SPEC-programoknál.
A másik fele pedig az, hogy a hivatkozott könyvtári elem hívásának paraméterei megfeleljenek pl. az SSE lehetõségeinek. Ilyen esetben természetes, hogy a beállított optimalizálási metódusnak megfelelõ leggyorsabb elemet használja minden fordító. Ezt ugyanis a legtöbb ilyen matematikai könyvtár is támogatja, legalább áttételes módon...

Bár, azt is hozzá kell tenni, hogy aki olyan régi könyvtárral dolgozik, amiben nincs még SSE [/quote]

Ami nekem nem tetszik Elric által elmondottakban, az az, hogy:

idézet:

---

egy valodi ceg valodi compilere felismer a SPEC2000fp benchmarkok kozott egyet ... [/quote]

Eleve nem értem, hogy miért kellene egy fordítónak felismernie, hogy SPEC-et fordít. Nekem ez finoman szólva gyanús. A másik, hogy véletlenül pont azt a könyvtárat optimalizálja, amelyet a SPEC használ. Mellesleg nem hiszem, hogy teljesen megszokott dolog az a fordítóknál, hogy egy könyvtár komplett függvényét kézzel optimalizálják elõtte a fordítóírók szorgos munkával.

Továbbá Elric által leírtakban nem szerepel, hogy vajon mi történik, ha ugyanazon könytár mátrix copy függvényét egy másik programból hívjuk meg. Vajon ekkor is spéci kézzel optimalizált kódot tesz be, vagy csak akkor teszi ezt, ha a SPEC-rõl van szó. Bár persze ez nagy hülyeség lenne a részérõl, hiszen ha már egyszer megírták, akkor ugye érdemes hsználni.

[hvuk]

idézet:

---

Ezt írta Rive:


Elric írása is arról szól, hogy nem a SPEC-et, hanem egy könyvtár hívásait azonosítja a compiler. Ez nem túl elegáns, de elfogadott, hiszem mindenütt gyorsít: nem csalás. Eleve, az egész C programozói gyakorlat erre épül

Azzal ellentétben, ha mondjuk egy beállított 'SPEC' flagre izgulna a drága... [/quote]

Felismeri. Legalábbis Elric ezt írta. Persze lehet, hogy nem így gondolta. Majd ha benéz, akkor pontosítja.

[Rive]

idézet:

---

Ezt írta hvuk:
Felismeri. Legalábbis Elric ezt írta. Persze lehet, hogy nem így gondolta. Majd ha benéz, akkor pontosítja.[/quote]

Ha olvasol, akkor illene figyelned a hangsúly lejegyezhetetlenségére. Pláne egy összetett szakszövegnél.

NEM a SPEC-et ismeri fel, hanem a könyvtárat.

idézet:

---

Ezt írta Elric:
A compilerben lehet olyan logika, ami kelloen altalanos, vagyis nem csak a SPEC tesztek eseteben tuzel, de azok eseteben biztosan. Ez a logika olyan speci optimalizaciot alkalmaz, amitol jobb lesz a SPEC eredmeny. Az meg, hogy milyen mas esetben tuzel meg, hat kerdeses, de lehet ilyen eset...[/quote]

Ugyanerre lehet következtetni Elric hozzászólásának második részébõl is, akár.

Ui.: sorry mindenkidõ: elkaddam dalami nádád, kicsid ingerdédeny vadok...

[ 2004. február 25.: Rive szerkesztette a hozzászólást ]

[hvuk]

idézet:

---

Ezt írta Rive:


Ugyanerre lehet következtetni Elric hozzászólásának második részébõl is, akár.

Ui.: sorry mindenkidõ: elkaddam dalami nádád, kicsid ingerdédeny vadok...

[ 2004. február 25.: Rive szerkesztette a hozzászólást ][/quote]

A második része egyértelmûen azt mondja, hogy felismeri a SPEC-et. Érdemes lenne kipróbálni, hogy mi történne, ha a SPEC egy módosított verzióját letesztelni, ami át lenne annyira alakítva, hogy a fordító ne ismerje fel semmiképpen, de a futási idõnek kb. ugyanannyinak kellene lennie. Érdekes lenne, ha szignifikáns különbség adódna.

Amúgy meg továbbra is fenntartom a véleményem, hogy ez csalás. Noha annak egy kifinomult formája.

Amúgy meg nincs gond. Én meg köhögök.

[ 2004. február 25.: hvuk szerkesztette a hozzászólást ]

[Rive]

idézet:

---

Ezt írta hvuk:
A második része egyértelmûen azt mondja, hogy felismeri a SPEC-et. Érdemes lenne kipróbálni, hogy mi történne, ha a SPEC egy módosított verzióját letesztelni, ami át lenne annyira alakítva, hogy a fordító ne ismerje fel semmiképpen, de a futási idõnek kb. ugyanannyinak kellene lennie. Érdekes lenne, ha szignifikáns különbség adódna.[/quote]

Kérd meg Fieryt. Én ugyan nem tökölök ezzel...

Amúgy, a SPEC CPU2k csupán egy deriváltja egy kupac iparági szoftvernek. Gondolod, hogy senkinek nem jutott még eszébe összehasonlítani az eredetivel a futásidõket??

Nosza, próbáld ki a bzipet... Vagy valamelyik másikat.

Ui.: ja, persze: kellenének a SPEC-ben használt workload-ok. Jóvanna...

[ 2004. február 25.: Rive szerkesztette a hozzászólást ]