[h1ghland3r]

Hozzatennem, hogy aki ilyen cuccos vasarlasan tori a buksijat, az szepen fogja a sajat kodjait, es a tesztelesi idoszak alatt (merthogy az is jar ilyenkor gondolom) szepen kiprobalja, hogy mit tud az uj architektura/compiler.

Valoban a Linpack1000x1000 tesztben assemblyvel jobb eredmenyeket erhetsz el (a 100x100-ban mar nem), de ezt mindenki batran megteheti, igy fair a dolog (ez egyebkent a Piszkos Fred a kapitany c. felejthetetlen regenyre emlekeztet, amikor Portas Robek cinkelt kockaval jatszottak, de mindketten tudtak rola, igy korrekt volt a jatek ).

Legjobb, ha a SPEC-et, TPC-t es tarsaikat inkabb versenynek fogjuk fel, mert ugyan klassz dolog ezekben jo helyezest elerni, de ugy nez ki eppen a szamitogep teljesitmenyerol keveset arul el.

h1ghland3r

[Rive]

Tesztelési idõszakról nem hallottam még: a többi abszolut korrekt

[hvuk]

Fiery, ha szépen kérjük, akkor ugye megteszed? Na, lécci, lécci!

A gondot ott látom, hogy nem tudjuk, hogy mennyire kellene a source-ot átalakítani, hogy a fordító már ne ismerje fel. Vajon mitõl ismeri fel, ha felismeri? Milyen részét azonosítja a programnak?

Persze, ha "csak" annyit csinálnak, hogy minden használt függvénykönyvtárat kézzel optimalizálnak - mármint ahol van értelme -, akkor nyilván nem kell felismerniük feltétlenül a SPEC-et (ezt te is írtad). Viszont mi van, ha a könyvtárat módosítom úgy, hogy ne ismerje fel? Illetve tudom mi van, akkor lassabban fog futni a program. Ekkor igazából az a kérdés, hogy vajon mennyi könyvtárat optimalizáltak kézzel és melyeket? Vagy mi van akkor, ha én ugyanolyan nevû könyvtárat csinálok, amiben ugyanolyan nevû függvény van, de igazából mást csinál, mint az eredeti mátrixszorzás. Ekkor vajon kicseréli a kódot a sajátjára és nem lesz korrekt a program futása?

[Rive]

idézet:

---

Ezt írta hvuk:
Persze, ha "csak" annyit csinálnak, hogy minden használt függvénykönyvtárat kézzel optimalizálnak - mármint ahol van értelme -, akkor nyilván nem kell felismerniük feltétlenül a SPEC-et (ezt te is írtad). Viszont mi van, ha a könyvtárat módosítom úgy, hogy ne ismerje fel? Illetve tudom mi van, akkor lassabban fog futni a program. Ekkor igazából az a kérdés, hogy vajon mennyi könyvtárat optimalizáltak kézzel és melyeket? Vagy mi van akkor, ha én ugyanolyan nevû könyvtárat csinálok, amiben ugyanolyan nevû függvény van, de igazából mást csinál, mint az eredeti mátrixszorzás. Ekkor vajon kicseréli a kódot a sajátjára és nem lesz korrekt a program futása?[/quote]

Én még soha nem hallottam olyanról - értelmét se látom - hogy egy külsõ könyvtárból hívott függvényt bármelyik fordító valaha is lecserélt volna. Pont ez a könyvtár lényege, nemde :confused:

[hvuk]

idézet:

---

Ezt írta Rive:


Én még soha nem hallottam olyanról - értelmét se látom - hogy egy külsõ könyvtárból hívott függvényt bármelyik fordító valaha is lecserélt volna. Pont ez a könyvtár lényege, nemde :confused:[/quote]

Na, akkor most lehet, hogy én valamit brutálisan félreértettem? Szerintem Elric pont errõl írt a hozzászólásában.

idézet:

---

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. [/quote]

[Rive]

Elric errõl írt a hozzászólásában: én pedig ennek az eljárásnak nem látom az értelmét.

(Feltételes élethelyzet: a kétéves compilerem tfh. lecseréli a frissen megvett, 50% gyorsulást ígérõ matematikai könyvtár rutinjait. Szerinted ezt ki kockáztatná meg? Pláne, hogy az Intel is elad ilyen könyvtárakat - külön is! -, amiket egyrészt könyebb hekkelni, másrészt azt is lecseréli?? Mit szólnának ehhez azok, akik a könyvtárakat írják? Nem vennék észre?
Amúgy, fanyar fintor: a legtöbb mérés nem az Intel matematikai könyvtárait használja )

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

[hvuk]

Na látod, a gond itt van. Nincs neki értelme és mégis csinálják. És a választ nem nehéz kitalálni. Azért csinálják mert így XY benchmark alatt a processzoruk teljesítménye megnõ.

[Rive]

idézet:

---

Ezt írta hvuk:
Na látod, a gond itt van. Nincs neki értelme és mégis csinálják. És a választ nem nehéz kitalálni. Azért csinálják mert így XY benchmark alatt a processzoruk teljesítménye megnõ.[/quote]

A gond ott van, hogy megint tutira veszel valamit, amire legföljebb a desktop B+markjaid világából tudsz következtetni :o

Mi a fenét gondolsz, mikor bukna ki a dolog egy MatLib írója számára? Miután frissen módosította a rutinjait, vajon a tesztelés elsõ vagy a második percében jönne rá, hogy nem változott semmi?
Hogy valaki csal?

Ui.: természetesen használnak SPEC CPU2k-t az efféle könyvtárak teszteléséhez. Hiszen: iparági standard.

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

[Rive]

Fenébe... Már egy órája azon gondolkodom, vajon hogyan lehetne ezt észrevétlenül megcsinálni

És: sehogy. Legkésõbb a bit-bolhászok kiszúrnának minden kódmanipulálást az utasítás-szintû profiling során...

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

[h1ghland3r]

idézet:

---

Ezt írta hvuk:
Fiery, ha szépen kérjük, akkor ugye megteszed? Na, lécci, lécci!

A gondot ott látom, hogy nem tudjuk, hogy mennyire kellene a source-ot átalakítani, hogy a fordító már ne ismerje fel. Vajon mitõl ismeri fel, ha felismeri? Milyen részét azonosítja a programnak?

Persze, ha "csak" annyit csinálnak, hogy minden használt függvénykönyvtárat kézzel optimalizálnak - mármint ahol van értelme -, akkor nyilván nem kell felismerniük feltétlenül a SPEC-et (ezt te is írtad). Viszont mi van, ha a könyvtárat módosítom úgy, hogy ne ismerje fel? Illetve tudom mi van, akkor lassabban fog futni a program. Ekkor igazából az a kérdés, hogy vajon mennyi könyvtárat optimalizáltak kézzel és melyeket? Vagy mi van akkor, ha én ugyanolyan nevû könyvtárat csinálok, amiben ugyanolyan nevû függvény van, de igazából mást csinál, mint az eredeti mátrixszorzás. Ekkor vajon kicseréli a kódot a sajátjára és nem lesz korrekt a program futása?[/quote]


Nezd ez marha bonyolult kerdes (marmint szakmai oldalrol). Eloszor is a megfelelo szabvanyos konyvtarak (algebraban: BLAS, LAPACK, VLIB ...) linkelesenel nyilvanvalo, hogy minden gyarto mas es mas csontra optimalizalt konyvtarat szeretne hasznalni. Ezek platform specifikusak, elkepzelheto, hogy alapjaiban kulonbozo algoritmusokkal valositjak meg ugyanazt a funkcionalitast. Namost egy regivagasu HPC kod a futasi idejenek minimum 80%-at tolti az algebrai konyvtarakban (pl. ahol eszmeletlen mennyisegu matrixot kell invertalni, szorozni olyan eleg sok van).

Megtehetnek, hogy megkotik a kezuket azzal, hogy pl. a BLAS es LAPACK referencia megvalositasat kell forditaniuk es linkelniuk. Igy meg a forditoprogram szerepe lenne eltulozva, a kapott ertekeket meg rohogve lepipalnak a szorgos hetkoznapokban hasznalt profi konyvtarak segitsegevel (szoval a valos elettol tavolodtunk).

Aztan van meg olyan kerdes (bar ez mar csak numerikus matematikai szempontbol erdekes), hogy a matrixszorzast meg lehet csinalni gyors amde pontatlanabb illetve lassabb de pontosabb algoritmussal. A BLAS (Basic Linear Algebra Subprograms) "szabvany" nem irja elo a kivant pontossagot, sot kijelenti, hogy a progresszivebb modeszerek is hasznalhatoak igeny szerint. Ez megint a useren mulik, hogy az o alkalmazasa kepes-e toleralni egy kevesbe pontos, de gyorsabb BLAS implementaciot.

Szerintem ez alapjan oda lyukadunk ki, hogy erdemes a valos korulmenyeknek kitenni a gepet, es akkor azt fogjuk latni, amire kivancsiak vagyunk.

Szerintem a dragabb gepeknel igenis van tesztelesi lehetoseg. Nekunk az IBM egy dual Xeon-t adott el, es elotte volt lehetoseg a dominans szamitasaink futtatasara. Ez nagyjabol az SMP gepek alja, gondolom a minosegi daraboknal is lehet probalgatni.

h1ghland3r

[hvuk]

idézet:

---

Ezt írta Rive:


A gond ott van, hogy megint tutira veszel valamit, amire legföljebb a desktop B+markjaid világából tudsz következtetni :o

Mi a fenét gondolsz, mikor bukna ki a dolog egy MatLib írója számára? Miután frissen módosította a rutinjait, vajon a tesztelés elsõ vagy a második percében jönne rá, hogy nem változott semmi?
Hogy valaki csal?

Ui.: természetesen használnak SPEC CPU2k-t az efféle könyvtárak teszteléséhez. Hiszen: iparági standard.

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

Amit legeslegelsõ hozzászólásomban írtam ma, az épp erre vonatkozott: mármint arra, hogy a fenti buherálást a SPEC megengedi. Azaz lecserélheted gyorsabbra. De a gond az, hogy nem tudom, hogy melyik fórumon olvastam, az biztos, hogy valahol mostanában. Persze az is lehet, hogy nem így van, na de miért ne lehetne így?

Amúgy meg amit összeraktam, az két dolog:
- Volt Inteles csóka szerint lehet csalni és erre az Itanium a példa - ezt most mondta
- Még 2 évvel ezelõtt Elric írta a fenti módszert

E két független forrás egymást elég jól alátámasztja. Az elsõ azt mondja, hogy lehet csalni és az Itaniumnál megtették, a második meg azt mondja meg, hogy hogyan lehet. Sõt elég egyértelmûen utal egy gyártóra is (Intel). Én hiszek nekik. Ki vagyok én, hogy fölülbíráljam õket?

[Michell]

idézet:

---

Ezt írta hvuk:


Amúgy meg amit összeraktam, az két dolog:
- Volt Inteles csóka szerint lehet csalni és erre az Itanium a példa - ezt most mondta
- Még 2 évvel ezelõtt Elric írta a fenti módszert

E két független forrás egymást elég jól alátámasztja. Az elsõ azt mondja, hogy lehet csalni és az Itaniumnál megtették, a második meg azt mondja meg, hogy hogyan lehet. Sõt elég egyértelmûen utal egy gyártóra is (Intel). Én hiszek nekik. Ki vagyok én, hogy fölülbíráljam õket? [/quote]

Én is úgy emlékszem, hogy a SPEC tesztnek is megvolt a maga botránya, csak talán egy másik gyártó szereplésével. De biztos ezt is elõ lehet túrni annak aki nagyon ráér.

[SFIJ]

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 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 ][/quote]


Rive bazz az igenis csalas ha mondjuk lemd5ozod a SPEC forraskodjat, becsomagolod a compilerbe a kezzel optimalt reszeket es az md5=oket. Amikor a cpp kiszamitja az md5-ot es hit van, osszerakod a betarazott *.o-kbol az alkalmazast.
Es perse ha tortenetesen atzavarod a spec kodot egy kodzagyvalon akkor az okossag baromira laccik, mert nem fognak belinkelodni a betaralt *.o-k sot ugyanaz a kod meg MMX-et se fog latni, nem pedig SSE2-t vagyis az van, amit Elric irt.
A csalas ott van, hogy ez a proci+compiler parost jobbnak, ertekesebbnek mutatja, mint amilyenek azok valojaban

[SFIJ]

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]


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.

Hat netom hogy te hol elsz, de a C programozas nem arrol szol, hogy meghamistgatjuk a rendszerkonyvtarakat. Pontosabban vannak ilyen emberek azokat cracker-eknek, virus/exploit gyartoknak hivjak....

[Balala]

Szasztok,

New HP ProLiant DL145 excels in performance under the
WebBench™ 5.0 benchmark

Multiszemélyiségûek elõnyben:

idézet:

---

The ProLiant DL145 offers the following advantages:
HP leadership.
· HP is #1 in market share for x86 and Intel Itanium servers.[/quote]



Üdv,
Balala

[Erasmus]

idézet:

---

Ezt írta Balala:
Szasztok,

New HP ProLiant DL145 excels in performance under the
WebBench™ 5.0 benchmark

Multiszemélyiségûek elõnyben:



Üdv,
Balala[/quote]


Heh... skizofrénia HP módra.

üdv,

Erasmus

[hvuk]

Van egy olyan érzésem, hogy azért a vállalati döntéshozók egy része el fog gondolkodni a Xeon vs Opteron kérdésrõl az elsõ olyan alkalommal, amikor azt olvassa, hogy erre a vírusra immunis az Opteron (az XP SP2-vel együtt használva persze). És ugyanez igaz (sõt ott talán még jelentõsebb a szerepe) a desktop piacon. A teljes cikk [url="http://"http://www.xbitlabs.com/news/cpu/display/20040225144527.html"]itt[/url] olvasható.

idézet:

---

Microsoft Corporation and Advanced Micro Devices announced on Wednesday, the 25th of February, 2004, that the Service Pack 2 update for Microsoft Windows XP operating system will enable AMD’s Enhanced Virus Protection technology available in AMD64 microprocessors.
...
The core of AMD’s Enhanced Virus Protection is the so-called NX bit in the page-translation tables that specifies whether instructions can be executed from the page. The capability is also available on Intel’s Itanium and Itanium 2 microprocessors, but is not present in IA32e chips, such as Intel Pentium 4 E also known as Prescott, unlike suggested by certain sources last year.[/quote]

Mondjuk baromira nem tudom, hogy az Intel mi a fenéért hagyta ki az iAMD64-bõl az NX bitet.

[hvuk]

idézet:

---

Ezt írta Balala:
Szasztok,

New HP ProLiant DL145 excels in performance under the
WebBench™ 5.0 benchmark

Multiszemélyiségûek elõnyben:



Üdv,
Balala[/quote]

Különösen ez figyelemre méltó:

idézet:

---

The ProLiant DL145 with dual processors achieved a 39% higher performance score than with a
single processor. The ProLiant DL140 only showed 28% performance scalability. This represents a
39% processor scalability advantage for the ProLiant DL145 over the ProLiant DL140. [/quote]

A sok 39% ne zavarjon meg senkit, tényleg nem számolták el, tényleg annyival jobban skálázódik.

[hvuk]

Ha [url="http://"http://www.xbitlabs.com/news/memory/display/20040222180122.html"]ez a hír[/url] igaz, akkor az AMD tényleg helyes döntést hozott, amikor nem sieti el a DDR-II-re való átállást és meghagyja az úttörõ munkát az Intelnek. Ez még akkor is durva ár lenne, ha 4-ed ennyibe kerülne. És ráadásul 400 MHz-en semmi, de semmi elõnye nincs a síma DDR-el szemben. LOL

idézet:

---

A report over Akiba PC Hotline claims that Buffalo will start selling its DDR-II PC2-3200 modules (DDR2, 400MHz) on Monday, the 23rd of February, 2004. The initial price for 256MB module will be $455, 512MB modules will cost around $915. Even taking into account the fact that the modules are something exclusive and prices in Tokyo are higher than in the rest of the world, the quoted prices for the first batch of DDR-II are just too high for desktops and workstations.

Mainboards with DDR-II support are currently not available and are expected to emerge in March or April. All DDR-II memory systems this year will be dual-channel and will require at least two models to be installed for optimal performance. With a pair of 512MB memory modules at 400MHz with CL 3-3-3 latencies quoted at about $1800, it is not likely that DDR-II will be mainstream this year, as a couple of 512MB quality DDR modules cost about $160 nowadays.
[/quote]

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

[Fiery]

idézet:

---

Ezt írta hvuk:
Ha [url="http://"http://www.xbitlabs.com/news/memory/display/20040222180122.html"]ez a hír[/url] igaz, akkor az AMD tényleg helyes döntést hozott, amikor nem sieti el a DDR-II-re való átállást és meghagyja az úttörõ munkát az Intelnek. Ez még akkor is durva ár lenne, ha 4-ed ennyibe kerülne. És ráadásul 400 MHz-en semmi, de semmi elõnye nincs a síma DDR-el szemben. LOL[/quote]

400 MHz-en a DDR2 egyertelmuen lassabb. Az i915/925 eseteben pedig mivel csak 800-as FSB lesz tamogatva, hiaba is tolsz ala gyorsabb DDR2-t (pl. DDR2-533), az FSB limitalni fogja a savszelesseget, ergo megint csak lassabb lesz, mint az i865PE/i875P

Ez egy vicc, egyszeruen nem ertem, minek eroltetni ennyire. Persze az is igaz, hogy valahol el kell kezdeni, csak nem ertem, miert nem 1066-os FSB-vel indul az i925 legalabb, akkor lenne valami ertelme a DDR2-nek -- bar a bazimagas latency (CL4 es hasonlok, DDR2-533-on) miatt me'g 1066-os FSB + Dual DDR2-533 sem lenne feltetlenul gyorsabb, mint az FSB800 + Dual DDR400.


Fiery

[ 2004. február 26.: Fiery szerkesztette a hozzászólást ]