A nap képe: AMD Ryzen Threadripper 1950X - Linux kernelfordítás 36 másodperc alatt

Címkék

Hozzászólások

Huh, de rohadt régen fordítottam kernelt!

--
trey @ gépház

386DX 20MiB RAM, cache nélkül, már nem emlékszem az időre, de másnapra készült el :)
(Délután kezdtük)

Ne felejtsük el, hogy a kernel forrás azóta sokkal nagyobb lett, nem lehet az időket egy az egyben összehasonlítani.

---
http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Idezet a hogyanbol:
"Az időről annyit, hogy egy IP166MMX -en
64 MByte -on kb 5 percig tart (ha jól emlékszem. Sose mértem), viszont
a 486-osomon 8 Megával ez kb 1 órán át is eltartott."

"Egy 486DX4/100-es gépen 16 MB RAM-mal egy 1.2-es kernel fordítása öt fájlrendszerrel, hálózati támogatással, hangkártya meghajtóval körülbelül 20 percig tart. Egy 386DX/40-en (8 MB RAM) hasonló konfigurációval majdnem másfél óra."

Én az alábbi teszttel vetettem gyorsan össze x86_64 architektúrán és gcc-7.2 fordító esetére:

$ wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz
$ tar xf linux-4.9.tar.xz
$ cd linux-4.9
$ make defconfig
$ time make bzImage -j 6 # ahány szálon akarod

proci: i5-3337U
real 8m30,384s

Ügyes a Threadripper 36 másodperce. A 17 wattos (CPU+GPU) laptop procimhoz képest igen fürge, ha minden magját tudod nyúzni.

Ezt már akartam én is írni. A Phoronix Test Suite-tel kell mérni, gondolom valami minimum konfigot használ fordításnak, csak a legminimálisabb modulokat forgatja bele a kernelbe. Úgy lesznek az eredmények összevethetők, mert jelenleg itt a kollégák teljes értékű kerneleket forgatnak, azért is kapnak sokkal reálisabb, kevésbé szenzációs eredményeket.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Sajnos én nem tudok eredményt betenni, mert Archon nem akar lefordulni a 4.9.0-ás kernel, leáll a make hibával 7m07 környékén (i7 2620M 2,7 GHz, 4 MB cache):
(.text+0x68e94): undefined reference to `____ilog2_NaN'
make: *** [Makefile:969: vmlinux] Error 1

Ugyanez az eredmény, ha a phoronixos cuccot futtatom, akkor 7m33-nál áll le, igaz a hibaüzenetet nem látom, csak azt írja a script, hogy The test quit with a non-zero exit status. Ismert 4.9-es kernel bug. Egyébként a phoronixos test is 4.9.0-ás kernelt húz le, de 139 megás fájlt, míg a wget-es módszer a kernel.org-ról, amivel itt tesztelünk egy 93 megásat húz le, amúgy egyformán make defconfig-os történet mindkettő, sok eltérésnek nem kéne közöttük lenni.

A 4.13-as kernel viszont lefordul nálam 8m4.058s alatt. A leggyengébb eredmény a topikban, és i5 3340M-re, ami még ennél is gyengébb, mondta hajbazer, hogy bloat proci :D

Szerk.: a 4.9.47-es lefordul, 7m23.063 alatt, ez már összehasonlítható a topikbeli eredményekkel, akár wgetes, akár forrónyixos.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Két és fél év alatt sokat változnak az idők. Igaz azóta kihalt a gépemben az i7-es lap, és mivel a proci oda van forrasztva a TP X-ekben az alaplapra, most egy i5-2520M-es lap van benne, ami alig lassabb, -1 MB L3 cache, meg -0,2 GHz órajel, de épp úgy 2 mag 4 szál. Ez a pár órája kijött 5.5.2-RC1 kernelt ~12,5 percig forgatta. Szerintem ez leginkább az inteles sebezhetőségeket védő foltok miatt van, mert bár ki van jó részük kapcsolva a mitigations=off paraméterrel, de a rendszert futtató kernel retpoline-nal lett fordítva, meg a friss BIOS-ban és linuxos microcode csomagban ott van Spectre1 elleni védelem. Na meg a kód is jóval nagyobb lett, amit fordítani kell.

Nem is túl régi teszteredmények alapján ugyanez a proci a 4.18-as kernelt 9 perc 43 alatt fordította. A dual 64 magos 128 szálas AMD EPYC rendszer meg 16 mp. alatt, ami jócskán megdönti a topikindító 36 mp.-et. Szépen kimutatható, ahogy az egyes hardverek avulnak, szép csendben, lassan, hónapról hónapra. Még a 4.9 és 4.13 fordítási ideje közötti 39 másodperces lassulás azonos procival szintén nagyon finoman jelzi ezt.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Greg Kroah-Hartman egyik előadásán elhangzott, hogy 20-nál több patch van a kernelben 1-1 ilyen exploitra, és az össz sebességcsökkenés lassan közelíti a HT kikapcsolását. Azt is mondta, hogy a FreeBSD csinálta jól, mert ők a Spectre megjelenésekor letiltották a HT-t.

Amúgy nem tudom, föltűnt-e, az Intel elkezdett kiadni HT nélküli i7-eseket. https://www.pcworld.com/article/3311519/intel-9th-gen-core-i7-lost-hype…

Ezek szerint nem javítják ki a HT implementációt, hanem megoldják nyers erővel. Elég rosszkor jött nekik ez a Spectre/Meltdown/Zombieload exploit sorozat, mert közben az AMD kihozta a Ryzen 7-es sorozatot HT-gel (vagy ki tudja, az AMD-nél hogy hívják), és Core i9-es sebességet kínál Core i7-es árakon és fogyasztással. És állítólag az AMD nem/kevéssé érintett az említett exploit-ok által.

Ez attó függ, hogy mit nézünk. Ha régebbi genes procikat, akkor igen, ez a sok sebezhetőség elleni folt már lassan akkora lassulás, mint pár HT szál elvesztése. Újabb procikon viszont nem ekkora a lassulás. Ennek ellenére lehet a BSD-seknek van igazuk, de a HT-t én se szívesen tiltanám le. Főleg nem régi procikon, amik még jobban rá vannak szorulva.

Most néztem, a mostani Ryzen 4700U-mon (8 mag, 8 szál, nincs HT, 4+8 MB cache) 3 perc 1 mp. alatt fordítja a defconfigos 5.17-es kernelt. Most az atta az apropót, hogy Ingo Molnar bejelentette a fordítást gyorsító patcheket az 5.17-rc8-hoz, állítólag 60-70%-kal gyorsabb. Ez kb. meg is áll, előtte kb. 6 perc körül volt a defconfig, és majdnem 9 perc egy használhatóbb kernel, pontosan nem emlékszek, de ilyesmi nagyságrend.

A patch által gyorsított fordítást nem néztem, de az asztali Ryzen 2600-ason is kb. ezek az idők voltak, mert bár több szál, 12, de csak kevesebb mag (6), kisebb IPC, viszont több cache (19 vs. 12 mega), és kicsivel több freki dupla energiakeret mellett, memóriák mindkét gépen dual channel 3200 MHz DDR4 alap órajelen. Kb. egál, lehet kicsit gyorsabb az asztali, ha lemérném. Az új, 12 genes Intelek ezt bőven vernék, de már ez a 3 perc is elég szép idő, fullosabb kernelnél legyen 5-6 perc, bőven kivárható, ha ilyenre van szükség, annak ellenére, hogy pl. a config és a tömörítés/initramfs létrehozása nincs belemérve, azok még pár-pár másodperces extrák.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ennek sok oka lehet. Vagy nem használod minden prociszálad, vagy HDD bottleneck van, próbáld lemérni ramdrive-ról, tmpfs-ből, ahogy én csináltam, háttérben se fusson semmi, ha nagyon bloat DE-s rendszert használsz, akkor lépj ki szöveges tty-ra, szabad memória legyen dögivel szabadon. Egyébként az a 3 perc attól a 9 éves, DDR3-at használó i7-estől elég badass, ezért is röhögtem, mikor a MS magyarázta, hogy az ilyen Ryzen 1600, meg i7-3770, i7-7700K azok ilyen elavult procik, nem elég jók a Win11-hez, nem lesznek támogatva, nekik redmondban jobb van, möhh-möhh, nem biztonságossschh! De még az a 4 perc se rossz egy laptopon szerintem, ilyen szintről még pár éve nem álmodtunk,, hogy egy pár W-os, papírvékony eszközön ilyen röpke idő alatt lefordul.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az i7-3770-en én is csodálkozom. Amúgy Yocto-t szoktam fordítani rendszeresen, az project-től függően 1-5 óra szokott lenni. És Yocto fordításnál is az jön ki, hogy legföljebb 1% különbség van az i7-3770 és az i5-1135G7 között. Pedig mindenféle elérhető teszt szerint legalább 50%-nak kellene lennie. Én a DRAM-ra gyanakszom. Az asztali gépben van dual-channel, a laptopban pedig valószínűleg nincsen. Ez is hoz vagy 10-15%-ot. Illetve nagyobb project fordítása biztosan nem fér bele a cache-be, így hiába gyorsabb esetleg a proci, a DRAM lelassítja.

Mindenesetre furcsa. Korábban egy i9-9900K-t is használtam, annak 3-szor olyan gyorsnak kellett volna lennie, mint az i7-3770, de csak olyan 2-szer, 2.5-ször volt gyorsabb. Szóval ennyit a benchmark-okról.

Szerk.: Yocto-nál az SSD, vagy HDD gyakorlatilag nem számít. Sima Linux fordításnál tmpfs-t még nem próbáltam.

Újabb mérés, Linux 6.0-rc1 defconfigos fordítás (+default gcc-s paraméterek, -O2, stb., ezen nem állítottam, csak a make-nek adtam -j segítségével több szálat), Ryzen 6800H (8 mag, 16 szál, 4+16 MB cache), szokásos 2×8 GB RAM (ez már DDR5 4800MT/s-es), 2m11.893s

Azért ez nálam nagy előrelépés, a korábbi 7-10 perces eredményekhez képest, ami lement először 3 percre, most 2 közelébe. Egyre gyorsabb, de csak egyre több mag és egyre nagyobb memóriasávszél mellett. Annak ellenére, hogy a kernelfa egyre nagyobb. Az is igaz, hogy ez csak egy alap, defconfigos fordítás, modulok nincsenek benne, meg esetleg extra szükséges driverek, úgyhogy napi használatra nem alkalmas, de azért bebootolható kernelt ad, csak a benchmark, összehasonlíthatóság kedvéért mérek mindig ezzel. Az a fullos generic kernel, amit a mainstream disztrók szállítanak, azokba konkrétan konyhai lefolyó, meg rozsdás vasmacska is bele van fordítva, annak a fordítási ideje a defconfingoshoz képest többszörös, most nem tudom mennyi, de kb. háromszoros tuti van. Az is igaz, hogy a disztrók viszont egy sok magos build servert használnak, és nem laptopot, desktop/workstation gépet.

Ha Gentoo-hoz fordít valaki saját kernelt, az is kicsit hosszabb, mint a defconfig, de az adott esetben nem sokkal, mert ha kell valami extra modul, az ellensúlyozva van azzal, hogy a nem kellő sallangokat is ki lehet szedni fordítás során.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

megneztem az a teszt mit csinal, vannak benne scriptek.
a vanila 4.9 kernel forrast szedi le, kibontja aztan:
make defconfig
make clean
make -s -j [core-ok szama] &>logfile

szoval semmi extra, barmilyen rendszeren reprodukalhato.
ami izgibb, az a gcc verzioja. nekem pl slackwaren le sem fordult ez a kernel, elszall hibaval a gcc :)

A'rpi

Igen, én is így mérek, Phoronix nélkül is, mivel ez a sztenderd, defconfig, clean make -j magszám, alap gcc flag-ek (kernellel jövő -O2, stb.). Ha valaki nem így mér, az csak torzítani fogja az eredményt. Plusz én javaslom, hogy lehetőleg tmpfs-en, ramdrive-on csináljuk a fordítást, hogy az I/O bottlenecket csökkentsük (ez főleg akkor fontos, ha HDD-ről megy, ha jobbfajta SATA vagy NVMe SSD-ről fut, akkor nem sokat javít az eredményen), meg esetleg lehet játszani azzal, hogy a make-nek kicsit több szálat adni, mint a processzor szálainak a száma, mivel néha segíthet egy kicsit. Nem minden rendszeren, de egy próbát megér, ez még nem csalás.

Plusz azt még mondani se kell, hogy a háttérben lehetőleg ne fusson túl sok sallang, meg valami jelentősebb feladat. Laptopoknál ajánlott a legjobb teljesítményt/hűtést adó energiagazdálkodási profilt használni. Be lehet kapcsolni a cpu governort performance-re is a balance, default, power helyett. Tuning is megengedett a hardveren.

Természetesen a különböző kernelverziók fordítása során létrejött eredmények nem összevethetők! Folyamatosan nő a kódméret, nő a komplexitás. Egy 4.9-es kernel azonos hardveren nem annyi idő alatt fog fordulni, mint egy 5.15-ös, és a 6.0-ás.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

i7-6820HQ, Fedora 26, gcc 7.1.1, -j 8 (asszem 3200 MHz-n hajtja 8 szalon)
real 2m7.789s

Elotte kiadtam a sudo cpupower frequency-set --governor performance parancsot.

Nem tudom, ervenyes-e az eredmeny, mert:

kernel/built-in.o: In function `update_wall_time':
(.text+0x68e94): undefined reference to `____ilog2_NaN'
make: *** [Makefile:969: vmlinux] Error 1

Szintén Fedora 26, gcc-7.1.1. Kipróbáltam az otthoni erőgépen (AMD Athlon(tm) 7750). Nekem is hibázott:


make bzImage -j2

kernel/built-in.o: In function `update_wall_time':
(.text+0x68e94): undefined reference to `____ilog2_NaN'
make: *** [Makefile:969: vmlinux] Error 1

real 14m12.945s
user 24m10.465s
sys 2m52.455s

Es nem reklamaltal, te kis huncut?! ;)

Maskor azert csapd az erdemenyhez a konfigot is, mert kulonben meg az egyszeri olvaso teves kovetkeztetesekre juthat. A kora azert nem a legfontosabb parametere egy rendszernek. Igy ismerve a reszleteket, azert eleg jo reklamot csinaltal itt a Threadrippernek ;) Most nem neztem utana, de egy 2660 V3 kerulhet vagy 1300 euroba, nem? Na az van neked ketszer (nem, ne probalkozz, itt nem jatszik szerepet, hogy te csak egyet fizettel! :p). A Threadripper ezzel szemben meg kerul cirka 1000 euroba. Es akkor vessunk egy pillantast az eredmenyekre. Hat igen. Kerdes persze, mennyire kell a kernel forditast ultimativ tesztkent elfogadni es mennyire van erteleme processzorokat egyfajta teszt alapjan osszehasonlitani, de jateknak azert jo ...

Azt ertem, csak itt most mindenki hasonlitgat mindent mindennel, aminek aztan keves ertelme van, mert a hir alapvetoen azert arrol szol, hogy eleg komoly teljesitmenyhez lehet jutni, elerheto aron. Es meg veletlenul sem arrol, hogy ki tudja gyorsabban forditani a linux kernelt. De azert jo geped van :)

Van 2 asztali gepem van amit napi szinten hasznalok (otthoni, irodai) azokon kiprobaltam:

phoronix-test-suite test build-linux-kernel

Intel Core i7-5820K @ 3.60GHz (6x2 Cores), Launch Date Q3'14
Timed Linux Kernel Compilation 4.9: Average: 107.29 Seconds

Intel Core i7-4790 @ 4.00GHz (4x2 Cores), Launch Date Q2'14
Timed Linux Kernel Compilation 4.9: Average: 133.44 Seconds

Ha jol latom ez a Razor 1950X proci meg 16x2 magos, ugyhogy nagyvonaluan a CPU mag szammal normalizaltam az eredmenyeket (mintha mindket fenti CPU 16x2 magos lenne), akkor az jon ki, hogy:

40.23s (i7-5820K)
33.36s (i7-4790)

Igy mar nem is olyan nagy a kulonbseg. Ne ertsen senki felre, nem az en processzorom hosszat akarom masehoz meregetni, az AMD vs Intel vitaba sem szeretnek belemenni es az arakat sem hasonlitottam ossze (ami pedig fontos lenne). Csak kivancsi voltam, hogy mekkora lepes is ez a "szenzacios" eredmeny, mert ugye azt senki nem gondolja, hogy barmelyik CPU generacio valtassal 3-5-szoros teljesitmeny novekedesek tortennenek (akarmenyik gyartonal).

megneztem most egy 4 magos intel i7 7700K procival (overclock nelkul), 86 sec volt. kis huzassal (ezek a procik birjak a 4.8-5ghz-et is plusz akkor a ram is gyorsabb) siman tudna 70 sec korul is.

szerintem az uj 18 magos i9 majd porig alazza ezt az amd csodat.

az viszont meglepett hogy a 6 magos i7 ennyire lassu, igaz 3 eves.

A'rpi

Valahol közelítőleg ennyit vártam volna látatlanban, legalábbis az alábbi alapján:
https://www.cpubenchmark.net/compare.php?cmp[]=3038&cmp[]=2874&cmp[]=30…

Kis nosztalgia: előkerült egy régi CPU.
Pentium4 HT 630 - 1+1HT, gyártás kezdete: 2005q4, 84 watt TDP.

vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
microcode : 0x5
cpu MHz : 3000.000
cache size : 2048 KB

real 33m33.870s
user 63m47.956s
sys 2m9.124s

de mit lehet ezen elbenazni? :)
amugy a 7820X 4.3ghz-re "huzva" (gyarilag tud annyit turboba, csak kicsit trukkozni kell hogy minden mag annyin menjen egyszerre), ram 2.66ghz-en: 52-53 sec. ram 2.4ghz-en viszont csak 54-55s. gyanus nekem hogy a kernelforditasnal ilyen pocikkal mar nem is a cpu sebesseg szamit annyira, hanem a cache meret es/vagy a ram sebessege, mivel az a bottleneck.
mprime tesztnel is a kis blokkmeret kimaxolja a cput 90-100 fokra, a nagyobb memoriamereten operalo meres viszont nem igazan futi fel, ott inkabb a ram izzad.
erdekes lenne megnezni valami tuning rammal (3.2-3.4ghz) is...

A'rpi

a gcc-s nyűgöt javították már? (threadripper állítólag nem érintett)

Tesztekkel együtt is ennyi, ugye? :)

Impresszív. Kár, hogy 26 évet késett ez a teljesítmény. 1991-ben sokkal jobb lett volna.

--
robyboy

Homályosan ugyan, de én emlékszem valamikor a 90-es évekből egy ilyen "kié a gyorsabb" versenyre valamelyik linuxos levlistán és ott volt egy ehhez közeli érték (talán 45 sec). Az illető természetesen valami rettenetesen sok processzoros gépen mérte, aminek kb. köze nem volt a desktop kategóriához. A "normál" időtartam akkor 5-15 perc volt.

Szóval szerintem korábban is voltak ilyenek, legfeljebb nem tudunk róla.

---
Science for fun...

97-ben a kernel forráskód letöltése órákig tartott. Még az egyetemen is, nemcsak egy modemes internettel. A kicsomagolás alatt is meg lehetett inni egy kávét. A fordítás overnight ment, többször aludtam emiatt a szoba műszőnyeg padlóján. Nagyon drága volt akkor még a memória is.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Mohács borítékolva volt. Ha ott nem kaptunk volna ki, kikaptunk volna a következö csatában. Az alföldön semmi sem tudta volna megállítani a török hadakat, ha összefogunk, ha nem.

Amúgy igen, látom lelki szemeimmel a sok okostojást, hogy húznak széjjel akkor, amikor össze kellett volna tartani.

--
robyboy

Szentmihályi Szabó Péter valamelyik 111 Mini könyvében pont tankokat küldött oda vissza. De a törököktől is ki gördültek a Nato tankok, és maradt minden ahogy volt. :)
- - - - - - - - - - -
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

Valamikor a tcc le tudta fordítani a kernelt iszonyatosan rövid idő alatt (nem tudom a legfrissebbet tudja-e?), de azért ez akkor is elég komoly eredmény...

Erről a klasszikus AMD-s processzor vicc (2+2) jut eszembe. :)

Mi ebben a hír? 36 másodperc alatt annyi segfaultot gyártok, ahányat csak akartok :)

BTW, a pár évvel ezelőtti, közel sem csúcskategóriás, hasonló magszámú (16 cores/32 threads) Xeon rendszereink szintén percen belüli idővel fordítják a kernelt.

A legkorábbi 16 magos amit találtam: http://ark.intel.com/products/81060/Intel-Xeon-Processor-E5-2698-v3-40M…

Ajánlott árat fel sem írtak, gondolom csak OEM partnerek adták. Alatta a 2697v3-hoz egy finom USD 2700-as árat látok. Nem mondanám "commodity hardware" kategóriásnak. :)

Ezekkel a mindenféle segfaultokkal meg fűtőtest dolgokkal kár jönni. Fordult elő probléma intel procival is és fűteni is tudnak bőségesen.

Sok vállalatnak jó fog jönni az olcsón nagyobb teljesítmény főleg szerveres oldalon (minden gyártó fog epyc rendszert szállítani) és végre felrázza az intelt is valami mert szégyen, hogy egy 4-6 évec CPU-t nincs komoly értelme lecserélni egy újra mert nem nyújt annyival többet.

Szerveres oldalon ott vannak a megfelelőik. Kis szerencsével az EPYC felrázhatja az állóvizet a relatív olcsó és sokmagos/sokszálas vonalon, ugyanis szerveren eleve a sokmag/sokszál a nyerő.

Már jóval régebben ismert, hogy inkább a többszálúsítás felé megy a desktop is, szóval annyira nem érzem ezt problémának.

Nem igazán. Egy i7-2600K 3.4Ghz (2011) ~40%-al lassabb csak egy i7-7700K 4.2Ghz (2017) ami nem valami nagy előrelépés. Szerveres oldalon nem, de szerveres oldalon az igen, hogy van egy újabb szereplő végre. Az intel elkarcolgatott volna még egy darabig de annak az 86 megszűnése lett volna a vége egyszer. CPOU teljesítményben már rég ránőttek más architektúrák is így verseny nélkül az x86 nem tudná szerintem tartani az alapértelmezett és vezető szerepét.

[partszélről bekiabálásba rejtett subscribe]

Szerveres oldalon meg nem az Intel i7 vs. AMD Ryzen fogja felrázni a piacot.

Annyira azért nem biztos... a Linus Tech Tips-es Linux fejtegette egy videóban, hogy az AMD felzárkózása miatti kényszerből kiadott i9-nek (ill. a hozzá csapott chipsetnek) tök jól néz ki ugyan a spec sheetje, de mindenhol tele van "Up to..." részekkel - szerinte egyértelműen azért, mert féltik a Xeon üzletágat, ami eddig el volt azzal, hogy sok-mag, oszt jónap. Ha most le kell vinniük a sok-mag-ot a consumer szintre is (márpedig le kell, ha versenyezni akarnak a Ryzennel), azzal kannibalizálhatják a Xeont, ha ott nem csinálnak valami újítást.
[/partszélről bekiabálásba rejtett subscribe]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem baj az, kannibalizálják csak szépen.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Gyorsan ránézve az ark.intel.com-ra a CPU-kra és az X299-es Chipsetre, az, Xeon-only. (szerintem ugyanabból a megfontolásból, mint amit fentebb írtam, egy-két tavalyi 18 magos Xeonnal összevetve http://ark.intel.com/compare/126699,93804,93807 ahol megvágták az a cache, a multiprocesszor támogatás, a használható RAM méret és az ECC - ha engednék az ECC-t, még a 128G-s limittel is egész korrekt szervereket lehetne belőle építeni, vinnék, mint a cukrot, csak épp fele annyiért, mint egy hasonló tudású Xeont)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hoppá, tényleg... Desktop celeron is van ECC supporttal.

https://ark.intel.com/Search/FeatureFilter?productType=processors&ECCMe…

Ezt a listát elnézve a magas magszám (>4) + ECC kombót hagyták meg a (szerver) Atom és Xeon családoknak.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nincs ezen min csodalkozni. Elmultak a 90-es evek amikor meg meg lehetett duplazni a frekvenciat. Egyszeruen elertunk par fizikai limitet, barmilyen kellemetlen is ez. Mar ~10 eve a magszam novelese a legnagyobb lehetoseg elore lepni. (A legnagyobb... ettol meg persze vannak kisebb sot kozepes lepesek)

Meg azt is látni kell, hogy a freki nem minden, az architektúra többet számít. Lásd a 3.8-as P4 esetét vs. 1,8 GHz-es C2D.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Főképp a vele együtt menő Athlon64-et kell látni. A desktopos Core az már az AMD-re volt válasz. Volt ott dualcore 3,4GHz-es Xeon 150W-os TDP-vel meg mindennel, hogy tudják a lépést valahogy tartani. Az Intel nem véletlenül i9-ezik és kamillázik, hiszen anno a K8 és most a Zen is Jim Keller által jegyzett: https://en.wikipedia.org/wiki/Jim_Keller_(engineer)

Inkább egy combosabb FPGA-szintézissel mérnének... tudnék adni párat :-)

180W TDP ?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mi van? Köze nincs semmilyen szinten egy ilyen 10 magos meditek fosnak akár egy nem atom szóval legalább i3 intel laptop procihoz, vagy egy desktop intel procihoz, töredéke teljesítményben.
A 10 magból a legtöbb inorder cortex-a53, az semmit se ér. Van mondjuk kettő normálisabb a72-es out-of-order mag azok már sokkal jobbak de az is töredéke egy x86-os szokásos procinak. Ezek kb. 2-3W-osak (és még throttlingolnak is mint az állat). Egy 3,2Ghz-s desktop pentium saccra olyan 4-5-ször tuti gyorsabb persze jóval nagyobb TDP-vel.

Te most milyen Pentiumra gondolsz?! Hagyjuk az Intel által újrahasznosított Pentium márkanevet a Celeron és Core i3 között, mert túl nagy a spektrum úgy. Az eredeti Pentiumok szintjét pedig már régen elérték az armok.
Még tavaly év elején voltak cikkek arról, hogy az Apple A9X ARM procija beérte az Intel előző évi Core M processzorait.
https://www.extremetech.com/mobile/221881-apples-a9x-goes-head-to-head-…

Azelőtt egy évvel az volt a hír, hogy az ARM procik beérték a Core2-t teljesítményben. Qualcomm is jó procikat gyárt, Samsung Exynosok között is sok erős arm van.

Nincs valahol egy teszt, ahol összevetik mondjuk egy 2xXeon E5-2670-el? Ennek az árából össze lehet hozni egy komplett duál xeonos gépet. Nem mondom, hogy megverné, csak kíváncsi lennék rá. Ugyanúgy 16 mag/32 szál.

Használt árakkal nem érdemes összehasonlítani, ilyet nagy cégek vesznek, a használt piacon meg az általuk levetett cuccokat kapod meg. Ez fogyasztásban is jobb, újabb architectúra is, meg valószínűleg jön új proci is majd még ebbe a foglalatba (mondjuk utóbbi céges szinten legtöbbször irreveláns)

Mivel Ryzen 5 1500x van a gépben, játszottam kicsit.
Bootoltam egy live rendszert, azon futtattam:

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz
tar xf linux-4.9.tar.xz
cd linux-4.9
make defconfig
time make bzImage -j x

Eredmények:

j4:

real 7m47.811s
user 14m10.614s
sys 2m44.793s

j8:

real 4m6.646s
user 15m28.706s
sys 2m35.682s

j16:

real 3m39.465s
user 16m8.607s
sys 2m47.036s

j20:

real 3m40.947s
user 16m16.435s
sys 2m49.155s

Szerintem érdekes, hogy az elvileg 4 mag-8 szálas cpu-n a kernelfordítás 16 szálon gyorsul meg. Ráadásul ez egy live rendszer volt, nincs amd-microcode betöltve, semmi spec driver.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Jelenleg az asztali gépen nincs Linux, 90%-ban úgyis csak játszom rajta. Ezért live rendszert bootoltam, amire fel tudtam ugyan telepíteni a phoronix test suite-ot, de először közölte hogy nincs elég hely, majd miután csináltam neki, azt mondta nekem, valami függősége nincs fent, pedig fent volt. Amit én mondtam neki, az nem volt szalonképes, úgyhogy nem részletezném. Ezért futtattam a fentieket. Csak miközben futott, néztem a gépterhelést, és 8 szálon a magok fele 50%-os terhelés alatt ment, mondom akkor legyen 16 szál is, utána meg elkapott a gépszíj.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Az mindegy, hogy live rendszer vagy rendesen feltelepített. Microcode sem számít, attól nem lesz gyorsabb, a microcode-dal csak bugokat javítanak. Semmilyen spec driver nem kell a procinak, a kernel tartalmaz minden szükséges dolgot, az meg live rendszernél is betöltődik, meg végigdetektál mindent, ami a gépben van.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Azóta lett telepített rendszer a gépen és mértem egyet újra.
A Live rendszeren az előző eredmény:

j16:

real 3m39.465s
user 16m8.607s
sys 2m47.036

A mostani telepített rendszeren futtatva ugyanaz:

j16:

real 2m23,293s
user 16m44,343s
sys 1m3,862s

A live rendszer lett telepítve a gépre. Szóval valahogy szerintem mégis számít.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

2 x AMD Opteron 4274 HE, 2x8 mag 2.5GHz

Average: 137.55 Seconds
Deviation: 3.43%