Fórumok
Az Intel Xeon processzorai olyan fordítót használtak, ami megnöveli a benchmark eredményeket.
A SPEC szerint az Intel Xeon processzorai olyan fordítót használtak, amely mesterségesen 9%-kal megnövelik az ipari benchmark eredményeket.
Reszletek: https://www.pcworld.com/article/2238972
Hozzászólások
tldr;
mindenki azt csinalja, amihez ert. az intel forditot csinal. :)
ha minden mas programot ezzel forditanak, es azok is ennyit gyorsulnak, akkor ezt a forditot kell hasznalni xeonon futo programokhoz, vagy beepiteni a tudasat mas forditokba.
neked aztan fura humorod van...
Ha jól értem a cikket, ennek csak annyi haszna lenne, hogy a SPEC tesztek azokkal is gyorsabbak lennének.
Azt nem, hogy bármi más is.
Science for fun...
Nem teljesen erről van szó. Pont, hogy semmi más program nem gyorsulna ettől az optimalizációtól. Konkrétan xalanbmk-nevű tesztre volt egy nagyon specifikus optimalizálás beépítve.
Régóta vágyok én, az androidok mezonkincsére már!
Ígérte valaki, hogy ez bármilyen más programra is igaz lesz?
Valakik szép nagy csíkot akartak ott látni. Megkapták.
Ahol KPI van, ott magától értetődő, hogy elindul a KPI forging. Ezért nem vagyok nagy barátja a KPI-k bevezetésének.
Ezzel kb azt mondod, hogy semmilyen benchmarknak nincs semmi értelme.
Konkrétan a SPEC-et én sem szeretem, mert egy vagyont kérnek el hogy a teszthez egyáltalán hozzáférhess. Vannak bőven ingyenes alternatívák és kevésbé is vannak kitéve a gyártók "szűk-területű optimalizálásainak". Ráadásul a SPECCPU2017 már vén mint az országút és azóta nem frissítették. Ettől függetlenül érthető, hogy miért létezik és szerintem _anno_ volt ráció abban, ahogy össze lett állítva. Szempont volt, hogy valós használatban is releváns szoftverekből álljon össze.
Van itt: perlbench, gcc, x264, exchange, xz, povray, blender, imagemagick, ezek amiket kapásból felismerek név alapján. Van mégegyszer ennyi, aminek utána kell néznem, hogy melyik mire is jó.
Itt is ellentmondó dimenziók mentén kell optimalizálni. Minél hosszabb ideig változatlan (lerögzített verziókkal szereplő teszt-alkalmazások) annál szélesebb körben maradnak összehasonlíthatóak az eredmények. Viszont idővel annál kevésbé lesz releváns, a suite-ban lerögzített 2017 előtti szoftververziókat mára nyilván senki nem használja. És persze minél hosszabb ideje változatlan, annál könnyebb és vonzóbb célpont a gyártóknak, hogy valahogy forge-oljak az eredményt.
Ami sajnos nincs részletezve, hogy technikailag pontosan mi is volt az "optimization with very narrow applicability".
Ha csak úgy általában az Apache Xalan-ra ráreszelték a fordítót, akkor lehet lamentálni, hogy etikus-e, de végülis mindenkinek előnye származhat belőle, aki xalan könyvtárat használ valahol a szoftverében függőségként.
Ha viszont azt csinálták, hogy a Xalan-ra pont azokat (és csak azokat) a teszt-adatokat futtatták be, amik a SPEC CPU benchmarkban vannak, a futását rögzítették egy profilerrel és az ebből készült statisztikát kötötték vissza az ICC-be, akkor nagyobb genyóság van. Mert ez az optimalizálás nemcsak a szoftverre, hanem a tesztadatra is specifikus lesz.
Régóta vágyok én, az androidok mezonkincsére már!
_Szerintem_ az ilyen pontozásos, sokmindent beválogatós, súlyozós benchmarkoknak nincs értelme. Azt sugallják, hogy megspórolják neked a gondolkodást; elég az eredményeket megnézned. Aztán meglepődés van, amikor kiderül, hogy a gyártók elkezdenek ezekre a kvázi-sztenderdekre optimalizálni.
Ha célorientált a terület (pl. video encoding, webserver, raytracing, stb.) akkor talán érdemesebb kimondottan ezekben vizsgálni az adott CPU teljesítményét.
Azt adom, hogy már nem elég nyers integer és fp aritmetikai teljesítményt nézni; a dolgok ennél már komplexebbek.
Valamint a peremfeltételeket sem árt rögzíteni. Pl. adott alkalmazásra open source programokat hasonlítanak össze, ugyanazzal a fordítóval fordítva (lehet többfélével is), releváns optimalizálási beállításokkal. Tudom, hogy ez sem tökéletes, de talán mégsem teljesen átláthatatlan.
Ahol en szoktam latni SPEC eredmenyt (mondjuk pl Anandtech neha szerepeltet ilyet), ott lebontva vannak az egyes reszeredmenyek. Az egybe osszeontott vegso pontszam nyilvan nem tul informativ, ebben egyetertunk.
Régóta vágyok én, az androidok mezonkincsére már!
csak nehogy az legyen, mint videokátyáknál, hogy a driver átcserélgeti a játék shaderjeit olyanra, ami gyorsbban fut, mint a fejlesztő által készített.
Ezért nem olyan bencsmarkok eredménye alapján kell CPU-t vagy GPU-t venni, amik nem az éles, valós üzemben használt programokból származnak.
Ha egész életében SPEC bencsmarkokat fog futtatni egy gép, akkor persze arra kell optimalizálni, és ott fasza lesz ez a megoldás.
A SPEC CPU egyes altesztjei valos hasznalatban levo library-kbol vannak osszevallogatva. A mostani problemas esetben emlitett xalanbmk konkretan az Apache Xalan (https://xalan.apache.org/) XML, XSLT, XPath library-t hajtja meg. Ezek nem mesterseges microbenchmarkok. (A microbenchmark nem osszekverendo a szintetikus benchmarkkal, ez utobbi sok kis kulonallo tesztbol valami sulyozassal allit elo egy vegso pontszamot. A SPEC CPU szintetikus, de nem microbenchmark.)
Valoszinuleg a problema az, hogy az Intel ugy optimalizalta a Xalan forditasat, hogy tudta, hogy milyen elore rogzitett tesztadatot kuldenek at rajta. Arra az 1-2 tesztadatra gyorsabb lett, minden masra lassabb.
Régóta vágyok én, az androidok mezonkincsére már!
Nagyon egyetértek. Nem csak emiatt a gyártói trükközés miatt, hanem a szintetikus benchmarkok általában is torzítanak, néha túl jelentős, néha meg túl jelentéktelen különbséget hoznak ki, és ez nem fedi a valós felhasználás során érezhető különbséget.
Egyébként meg szerintem ez az Intel részéről nem etikátlan. Nem helyeslem persze, mert kétségbeesésről tanúskodik, de mások is meghúznak ilyet. A fordítóval optimalizálás nem tilos, és pl. GPU driverek ezt már több évtizede csinálják, hogy cinkelik a benchmarkeredményeket, mivel rá vannak optimalizálva mindenféle 3D Markokra, stb.. Épp így egyes játékokhoz is tartalmaznak extra optimalizációt. Így nem látom, hogy az Intel hozzáállásával mi lenne akkora probléma. Ki van élezve a verseny, csak azt jelenti, de ez nekünk felhasználóknak jó, mert legalább van, nem úgy, mint 10 évvel ezelőtt, hogy az Intel el-tikk-takkozgat, ilyen 5%-os generációs gyorsulások voltak, meg mindenkit sok évig 2-4 magon, 2-8 szálon tartottak, hogy annyi mindenkinek elég, az AMD meg nem volt sehol, mert nem bírt normális versenyképes megoldást kihozni. Ez a Ryzenekkel változott.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Haha, hogy is volt ez a UNIX-oknál? A C-fordító, ami backdoor-t fordított a login-ba? Lásd Ken Thomson: Reflections on Trusting Trust.
Ha jól rémlik, Dennis M. Ritchie kapcsán járta az a pletyka, hogy a login-ba beépítette, hogy a dmr login-t mindig engedje be függetlenül attól, hogy van-e ilyen felhasználó vagy épp mi a begépelt jelszó. Méghozzá úgy, hogy a C-fordítóba beletette, hogy ismerje fel ha a login-t fordítja, és fordítsa bele fenti backdoor-t. És hogy bonyolultabb legyen az élet, a C-fordító önmagát is felismerte, ezért ha önmagát fordította, akkor beletette ezt a logint meghekkelő részt. Innentől a hekkelt fordító-forráskódot le kellett fordítani, ki lehetett venni a kódból a csúnyaságot,és az előzőleg fordított fordítóval újrafordítani. Innentől nem volt nyoma. Vagy valami ilyesmi.
Nincs új a nap alatt.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Én úgy emlékszek, hogy ezt egy cikkben írta Thompson, elméleti felvetésként, hogy ilyen létezhetne, és valóban, a belinkelt szöveg végig feltételes módban van. Ez nem jelenti azt, hogy ezt meg is valósították. Egyébként meg ezt manapság nem lehetne eljátszani, annyifélre disztrónak, annyiféle verziószámú, mindenféle C fordítója létezik, hogy nem bírná az egyik az összeset felismerni, és a fordítással trükközni. Mivel fordíthatod gcc-vel, clang-gal, tcc-vel, stb., azoknak bármilyen régi és új verziójával. Aztán akkor még a MS Visual C-ről, Intel-féle fordítóról nem is beszéltünk. Már rég lejártak azok az idők, amikor mindenki csak egyfélét használt, mert csak ahhoz fért hozzá.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Igen, azt a cikket linkeltem. És de, ma is meg lehetne csinálni, hisz bőven elég egy elterjedt (bináris csomagokal dolgozó) disztró alapbeállított eszközeivel ezt eljátszani. Mondjuk egy fasza kis 10 éves életciklusú rőt sityakon :-) De amikor ez felmerült, akkor azért sokkal szűkebb volt a választék. (Én egyébként arra is emlékszem de már nem keresem ki, hogy hol olvastam róla, hogy annyira megtörtént, hogy jó sokáig élt, és akkor derült ki a turpisság, amikor valaki egy teljesen másik kód fordítása során nem tudott értelmezni egy tervezett bináris méret / fordítással kapott méret eltérést, és elkezdte megkeresni, hogy mi a bánatért nem az az eredmény, ami szerinte kéne legyen. Szóval hogy Ken Thomson cikke, vagy DMR hekkje volt történetileg előbb, azt nem tudom, de mind a kettőt igaznak tartják. Amúgy az elv a lényeg.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ennyire atjarhato a CPU gyartas es az autoipar, vagy csak ugyanattol a konzultanscegtokl kaptak tanacsot?
A VW-t végül kártérítésre kötelezték, ha jól emlékszem. Lesz Intel kártérítés is?
a VW kismiska ehhez képest: https://hvg.hu/cegauto/20231221_Daihatsu_teszt_csalas_azonnali_hatallyal_leallitottak_a_kiszallitasokat
Az agile "Stop the line" kicsit komolyabban, mint SW fejlesztesben gondoljak nehanyan.
Meg az se semmi, hogy egy ilyennel kijonnek, es nem soprik a szonyeg ala, hogy a portasbacsi volt a hibas, mert nem jol koszont a dolgozoknak reggelente. Ha arcvesztes, akkor arcvesztes.
Persze kerdes, hogy az RCA-t folyatjak-e az anyavallalat felol erkezett, erzett vagy kepzelt nyomas felderitesere.
//
Volt egy japan (koreai?) film, amit a repulon lattam arrafele. Vonaton hasznalt ulesrogzito csavar hibaja korul forgott a tortenet.
Csak tudnam mi volt a cime...
"Vonaton hasznalt ulesrogzito csavar hibaja korul forgott a tortenet."
Mostanában azt nem tudják eldönteni, hogy akkor az az ajtó direkt nyílt ki, vagy összeszerelésnél valaki elfelejtett meghúzni pár anyát.
USA vs Japán
Azért a japánokat se sajnáld: https://www.japantimes.co.jp/editorials/2023/12/29/daihatsu-scandal/
Nem sajnálom (eleve az eredeti kommented is erről a botrányról szól), csak épp ezért értelmetlen ebbe a szálba amerikai példát behozni, amikor japán minőségbiztosításról meg gyökérok-keresésről van szó.
"went back as far as 1989"
Errol jutott eszembe, valamikor meg kisgyerekkent (kb 90-es evek legeleje lehetett) olvastam valami autosmagazinban, a "A BMW csele" cimu irast. Ezt a cimet valahogy megjegyeztem. Olyasmirol szolt, hogy volt valamilyen hatosagi szabvanyos tesztelesi eloiras, talan zajkibocsatasra. Ebben szerepelt, hogy a sebvalto 2-es fokozatban kell legyen a teszt alatt. A cikk szerint a BMW egyszeruen beepitett valami mesterseges lefolytast a motorba, ha 2-esben van a valto. Nyilvan nem huzott olyan jol a kocsi 2-esben, cserebe a zajteszten siman atment. Lehet, hogy nem pontosan emlekszem 1-2 dologra, ez boven az online vilag elott volt, nem hiszem, hogy sok cikk fenn lenne a neten rola. De az biztos, hogy ezeknek a csalasoknak nagyon regi hagyomanyai vannak.
Régóta vágyok én, az androidok mezonkincsére már!
Ha egyszer ez a követelmény, hogy kettesben legyen csendes, akkor miért gond, amikor erre optimalizálnak?
Minden iparágban a vonatkozó előírásokra és szabványokra fejlesztenek. Mi is ezt csináljuk. Az operating condition nem érdekel senkit, legtöbbször a vevőket se.
A fenti BMW-s példában arról van szó, hogy egy sokdimenziós térben értelmezett függvénynek egyetlen metszetére volt előírás. Ezt teljesítették. Nincs itt semmi látni való.
Gondolom akkor már nem lenne elfogadható ez az optimalizálás, ha észlelné h. éop tesztpadon van. Normál városi körülmények között meg sokkal hangosabb lenne.
Szerintem akkoriban ez nem is volt "gond". Én úgy emlékszem ez valami kisszínes rövid cikkecske volt. Nem valami világraszóló botrányként számoltak be róla, hanem a heti (vagy havi) autós bulvárhírek egyikeként. Nyilván köztudott volt, hogy ez így megy mindenfele, kb senki nem háborodott fel rajta.
Ha már többdimenziós tér, nagyjából logikus, hogy ezek miért történnek. Két (ellentétes) feltételrendszerben kellene egyszerre optimalizálni. 1) Feleljen meg a folyamatosan szigorodó fogyasztási és környezetvédelmi előírásoknak 2) az ügyfelek meg is akarják venni (=legyen gyorsabb, erősebb, nagyobb az előző generációnál). Egy darabig volt annyi fejlesztési lehetőség a technikában, hogy mindkettőn egyszerre tudjanak javítani. Egy bizonyos szint után már csak egyiket a másik rovására tudják fejleszteni. Nyilván az ilyen helyzetből általánosságban az a kiút, hogy a két kritériumra már nem egyszerre optimalizálnak, hanem külön-külön. Ha belegondolunk, ezt csinálta a VW is. Az, hogy ezt hogy minősítjük az egy másik kérdés.
Régóta vágyok én, az androidok mezonkincsére már!
Ráadásul az a durva, hogy a VW a vásárlókat nemhogy megkárosította volna, hanem éppen ellenkezőleg: dinamikusabb viselkedés, jobb üzemanyag-takarékosság lett az eredmény.
Mérnökként mi is találkozunk olyan szabályzásokkal, amik nem életszerűek; nem tudod őket úgy teljesíteni, ahogy a politikus megálmodta. Ilyenkor el lehet gondolkodni, hogy bedobod-e a picsába a törölközőt, vagy elkezded a dolgokat csűrni-csavarni, és megvizsgálni a mozgásteredet, a szürke zónákat.
Szerintem mindenben van az a szint, ahova még észszerű eljutni, amire még érdemes fejleszteni. Azon túl a további ,,fejlesztés" kontraproduktívvá válik.
Lásd az 1,2-es Puretech motorokat, ahol már azon baszakodtak, hogy az olajban futó szíjnak kisebb a futási vesztesége. A teszteken biztosan faszán elment, laboratóriumi körülmények között. A valóságban meg egy csomó embernek 40...60 ezer km után több olajat fogyaszt az autója, mint egy Trabant (fiataloknak: veszteséges kenésű kétütemű motorral), és amikor elviszi a szervizbe, közlik, hogy motorcserés.
Valóban ezt akartuk?
najo de hol van trey? ki vedi meg az intelt? :DD
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!