Mi pedig így csináljuk, immáron 2 évtizede, folyamatosan.

[ Szerkesztve ]

A stratégia az, hogy minden CPU-generációra extrém optimalizáció kerül beépítésre. Tehát minden CPU-ból kisajtoljuk a maximumot, így nem kerül egyik sem előnybe vagy hátrányba.

CPU-generáció alatt ne azt értsd, hogy Zen 4, hanem azon belül külön optimalizáció készül a Strixre, Strix Halo-ra, Granite Ridge-re, Krackanra, Turinra, stb.

Intel vonalon pedig az utasításkészlet szegmentáció miatt külön optimalizáció készül pl. AVX-512-re és AVX2-re is. És így ha a prociban le van tiltva az AVX-512, akkor anélkül is optimálisan fog futni a benchmark, nyilván az adott kereteken belül.

[ Szerkesztve ]

Az örök dilemma, mert vagy
1) ugyanazt a kódot futtatod minden hasonló képességű processzoron, így pontosan kimutatható az eltérés közöttük, mert a runtime-különbség a processzor jobb képességét hozza ki (cserébe nem hozza ki a maximum teljesítményt, mert nem elég optimalizált), vagy
2) minden processzorhoz mikroarchitektura-mélységig kitúrod a publikus (és a titkos?) dokumentációkból, hogy bitszintű reszeléssel mi a maximum amit ki tudsz hozni belőlük. Így viszont még 2 hasonló processzor sem ugyanazt a kódot futtatja, így a valóságban nem fogod tudni eldönteni h. melyik hogyan teljesít. Mert (néhány bencsmark íróján kívül) 1 kommersz program készítője sem optimalizál ennyire extrém módon.

[ Szerkesztve ]

Én azért tartom jónak a mi hozzáállásunkat a benchmark kérdéshez, mert nyíltan és egyértelműen publikáljuk, miképp fejlesztjük a benchmarkokat, és hogy azok tényleg extrém optimalizált kódok. Van aztán, akinek ez tetszik és relevánsnak gondolja, és van aki nem. De semmiképp sem árulunk zsákbamacskát.

Nekem nagyon tetszik ez a vezérelv és szerintem a teszteredményeket is érthetővé és védhetővé teszi. Így a tesztek legalább meg tudnak válaszolni egy releváns kérdést, hogy mi az ami az adott processzorcsaládban benne van egy-egy szituációt (algoritmust tekintve). Hogy a valós életben egy produktív szoftver ebből mit hoz ki az megint egy másik jóval messzebb vezető kérdés amire a válasz ráadásul időben is változik.

A ricsip féle felvetéssel az a bajom, hogy minnél gépközelibb a kód (és itt benchmarkról van szó, tehát az lesz), szerintem annál kevésbé megvalósítható a gyakorlatban olyan, hogy architektúrafüggetlen pártatlan minden hasonló generációs processzor számára nagyjából egyenlően jó gépi kód.

Gondolom az assemblyfejlesztő is nyilván valamilyen gépen fejleszt, menet közben teszteli az egyes szubrutinokat, számszerűsíti, hogy az egyes iterációs változtatások gyorsítanak vagy inkább lassítanak. Aztán ennek köszönhetően a végén a kód nem csak a támogatott utasításkészlethez, hanem a fejlesztéskor használt processzor belső felépítéséhez (cache, elágazásbecslés, párhuzamosan végrehajtott skalár utasítások száma, utasítások késleltetése) is adaptálódik.

Gondolom ebben az esetben az egyébként hasonlóan gyors és hasonló utasításkészleteket támogató i7 7700K és R3 3300X közül is az lenne a gyorsabb amely architektúrán éppen készült az adott tesztesetre a kód. Ez meg nem valami pártatlan...

Amúgy extrém benchmark mátrixműveletes AVX-es tankönyvi példa kódon kívül (ami laborkörülmények között tudja mutatni, mire képes a chip), mi az amit annyira kellene architektúrnként optimalizálni, h. jó legyen a való életben bármire is?

Ott van a Prime95 small FFT. Megsüti a vízhűtéses gépeket is, crashel tőle minden, ami átlagos programok alatt stabilnak tűnik hónapokig. Pedig az is csak földi halandók által írt kódot futtat, de azt mondjuk a való életben szinte sehol nem jelentkező sűrűségben.

"Gondolom az assemblyfejlesztő is nyilván valamilyen gépen fejleszt, menet közben teszteli az egyes szubrutinokat, számszerűsíti, hogy az egyes iterációs változtatások gyorsítanak vagy inkább lassítanak. Aztán ennek köszönhetően a végén a kód nem csak a támogatott utasításkészlethez, hanem a fejlesztéskor használt processzor belső felépítéséhez (cache, elágazásbecslés, párhuzamosan végrehajtott skalár utasítások száma, utasítások késleltetése) is adaptálódik."

Nem, nem így fejlesztjük a benchmarkokat. Nyilván mindig van egy fejlesztésre használt hardver (ami pár évente cserélődik), de az épp fejlesztés alatt álló kódot nem az adott fejlesztői vason méricskéljük.

A benchmarkok fejlesztése teljesen célorientáltan, maximálisan fókuszálva a megcélzott CPU-ra történik. Teljesen mindegy emiatt, hogy milyen hardver van a fejlesztésre használt számítógépben. A teljesítmény értékelése is a cél processzoron történik, nem a fejlesztői gépben lévő processzoron.

Az AVX (AVX, AVX2, AVX-512) valójában rengeteg helyen bevethető. Miből gondolod, hogy az Intel és az AMD is rádobott az AVX család fejlesztésére 16+ évet teljesen feleslegesen? Ha még csak az Intel implementálná őket, talán mondhatnánk azt, hogy ez az Intel dilije, és más meg tojik rá, de közel sem ez a helyzet. Ha az AVX semmire nem lenne jó (a benchmarkokon kívül), akkor az AMD nem bíbelődne az implementálással -- különösen az AVX-512 esetében, ahol több mint ezer (!) utasítás implementálása és validálása a meló. Amit ugye szépen el is végzett az AMD nem is olyan rég.

Az FFT meg hasonlók kapcsán nekem az az álláspontom, hogy ha egy konfiguráció stabil, akkor el kell bírnia bármilyen kódot. Melegedhet, adott esetben túl is melegedhet, de nem fagyhat le, nem dobhat kékhalált, nem kapcsolhat le, nem indulhat újra a gép. Másképp a stabilitás többé nem bináris kérdés lenne, hanem egy skála. Kb. mintha azt mondanád egy nőre, hogy kicsit terhes Az is eléggé bináris kérdés...

[ Szerkesztve ]

Persze. Elsőre is értettem amit írtál. A ricsip féle felvetést vittem tovább, hogy az miért nem lenne jó.

[ Szerkesztve ]

Félreérted. Tudom h. az AVX1-2-512 stb. irány a jövő, ez nem kérdés.
Hanem amikor benchmark szinten megjáratjuk pl. 1 (azaz egy) utasítást amilyen gyorsan csak lehetséges. Csak azért hogy teljesen beférjen L1-be, vagy akár a regiszterekbe és akkor lehet mondani h. 5 milliárd utasítás/sec. Kikeresve h. adott Zen 2,3,4,5 generációnál épp melyik utasítás hány ciklus alatt fut le, ebből lehet olyan mikrobenchmarkot írni, aminek az eredménye aztán teljesen félreviszi az embert az összkép teljesítményéhez képest.
(Gondolom ilyen Instlatx64 emberkék írományait szoktátok nézegetni.)

Helyette inkább életszerű kódot futtassunk, ami előállít valami tényleg használható outputot, és akkor hasznos munkát mértünk le az elméleti sebesség helyett. Mindegy, valószínűleg ezt fejtegetni nem menne sehova.

[ Szerkesztve ]

Viszont ha már így előjött a téma, talán megkérdezem tőled is:

---
Láttam pár YT gépösszerakós csatornán, h. veszik rakásszám ebay-ről a használt ES-es xeon platinumokat, mert az eredeti árának kb. tizedébe kerülnek. Ilyen millió forint fölötti hardvernál ez már elég szép megtakarítás ahhoz, hogy megérje foglalkozni a témával. Az ES azt jelenti Engineering Sample. Azaz a kiadás előtti még nem végleges -de már majdnem az- eszközt az intel kiadja külső cégeknek, partnereknek stb. akik így a tényleges startra már fel tudnak készülni (pl. alaplapgyártók ezzel le tudják tesztelni a BIOS-t). Működésben és viselkedésben is kb. megkülönböztethetetlenek általában a végleges piacra dobott változatoktól. A tokozáson szokott szerepelni h. Intel Confidential, nincs megnevezve a konkrét modellkód, illetve a CPUID alapján a diagnosztikai program tudja jelezni h. ez ES típus.

Az egyetlen rizikó ezekkel a processzorokkal kapcsolatban, h. mivel nem végleges kiadások, nem széleskörű használatra szánták őket, így lehetnek bennük olyan működési hibák, amiket a végleges revision-ben esetleg már felismertek vagy akár ki is javítottak. Erről azonban publikus dokumentáció nem szokott elérhető lenni. Így marad a remény, h. az ilyen típusú processzort is helyesen fel fogja ismerni az alaplap és a bios, és jól fog működni az OS alatt + a használt programokban.

Ráeresztesz egy benchmark-ot, vagy prímszámolós stressz-tesztet, azzal csak részben lehet meggyőződni arról h. a processzor stabil, nem hibázik, és nem fagy meg terhelés alatt. Viszont lehet h. olyan részében / utasításban maradt benne valamilyen hiba, amit a benchmarkok és stressztesztek nem (vagy csak lájtosan) tesztelik. Ezért a legbiztosabb teszt az lenne, ha egy program a processzor által ismert és támogatott ÖSSZES x86 utasítást tudná aktiválni és kipróbálni, hátha azáltal kiderül ha bármi ilyesmi bug van a processzorban.

Kérdés: létezik vajon ilyen általános célú processzor tesztelő alkalmazás x86-ra?

Láttam h. van az intelnek egy Processor Validaton Tool nevezetű programja. De ahogy néztem, az kimerül abban h. leellenőrzi a CPU brand string GenuineIntel-e, futtat rajta néhány SSE, meg AVX stressztesztet, és ha ezek eredménye sikeres, akkor a processzor átment a vizsgán. Szerintem ez édeskevés ahhoz képest, amit feljebb írtam.
----

Gondolom ilyesmivel nem foglalkoztok ti sem...
Ez valahol talán már az "unknown x86 instruction fuzzing" területe, ami meg aztán főleg niche téma egy aida64-nek.

[ Szerkesztve ]

Van az AIDA64-ben instruction latency mérés is, de a benchmarkok nem így működnek. Nem 1-2 utasításra fókuszálnak, hanem egy konkrét feladatot oldanak meg. Generálnak egy fraktált, sugárkövetéses képet renderelnek, nagy adatblokkokat kriptálnak el vagy hash-t generálnak hozzá, stb.

Szerintem nem létezik ilyen alkalmazás, legalábbis publikus formában semmiképp. Ha valakinek van ilyenje, az az AMD és Intel lehet, de ők tutira szigorúan őrzik azt.

Az ES procik egyik hátránya, hogy nincs hozzájuk mikrokód frissítés. Ergo ha beüt egy CPU sebezhetőség, az ES procikhoz hiába raksz fel új BIOS-t, nem fog a mikrokód frissülni.

Persze lehetne moralizálni azon is, hogy az eBayre felkerült ES procik tulajdonképpen mindegyike lopott vagy minimum illegálisan forgalomba hozott termék.

[ Szerkesztve ]

Engem is. De nem a program ára ami zavar, mert annyi megér, meg is venném, hanem utánna a support díjja.
Fizessek havi kb: 1.000 Ft (évente egyösszegbe persze), hogy megnézzem, hogy éppen hány fokos a CPU-m, vagy az alaplapom?

X évente veszek gépet, tudom, hogy mi van benne. Hosszabbtávon ez az egy dolog, ami hasznos benne. Ne mondja bárki, hogy havi szinten tesztelgeti a gépét...

[ Szerkesztve ]

A support nem kötelező. A support szerintem itt a szoftver frissítéseket jelenti.
Ha jól láttam, akkor a megvásárolt verziót korlátlan ideig használhatod, csak nem kapsz hozzá program frissítést.

"az 1-2 éves teljesen tökéletes állapotú HDD-ket / SSD-ket ledaráltatni a grinderrel, csak mert céges szekjúr adat van rajta, és a multiknak büdös költeni a biztonságos wipe-olásra"

Ez azért nem teljesen fedi szerintem a valóságot, mert a ledarált cuccot újra lehet és tudomásom szerint szokták is hasznosítani.

ledgeri, ricsip: azért általában nem a tökéletes állapotú 1-2 éves HDD-ket darálják le. Kifejezetten ritka az ilyen. Ami megy a darálóba az már olyan állapotban is van általában.
Másrészt meg a ledarálás általában jogszabályi előírás, nem pedig lustaság. (Legalábbis azoknál a cégeknél, akiknél eddig találkoztam ezzel.)

Mi is csináltunk már wipe-ot 1-2 HDD-n. De ha sok van valószínűleg a cégnek olcsóbb a darálás, mint csak azért futtatni egy gépet napokig, hogy törölje a lemezek tartalmát. (Ami amúgy vagy sikerül vagy nem.)