Upgrade z AMD Ryzen 2700x na 5800x alebo 5900x?

[JurajP]

Pokud je 2700X "stále dobrý", tak proč upgradovat. Spíš bych počkal na 65W Ryzeny 7000 a pak přešel na AM5. Protože příští rok ještě starou desku za nějakou tu tisícovku prodáš, ale za +5 let těžko.

No lenze tam bude ten upgrade cenovo uplne inde. Nova doska, procesor, a nikde nie je zarucene ze predam dosku s procakom.
Asi vezmem 5900x ale uvazujem trosku nad tym 5950x, len to uz je cenovo viac, neviem ako by som to obhajil doma

[Reklama]

[Karmelos]

Podle moji zkusenosti by bylo nejlepsi tam nacpat to co je nejlepsi pro tu desku, klidne z druhy ruky. Dokud je to na trhu.
Az to bude vybehovy typ, nejlepsi procesor k tomu nesezenete, bude ke koupi jenom nejaky mid az low end a to i v bazaru.

[Vít Šesták (v6ak)]

Tato generace má 8jádrové chiplety, tzn. 5800X se skládá z jediného (to asi joint007 myslí tím monolitem), vyšší varianty budou mít více chipletů. Jediný chiplet může znamenat rychlejší komunikaci mezi jádry, více chipletů bude IIRC znamenat více jedné úrovně cache.

Mám 5800X (s vypnutým SMT kvůli bezpečnosti). Než jsem se pustil do Rustu, přišlo mi to celkem naddimenzované a málokdy bych využil více jader. Na rustc mi to zatím přijde tak akorát.

[JurajP]

Este som zacal uvazovat aj nad 5950x  . Rozdiel oproti 5900x su 4 jadra navyse. Co sa tyka ale rychlosti kompilovania, tak tento graf ukazuje rozdiel max 2sec https://tpucdn.com/review/amd-ryzen-9-5950x/images/compiler.png.
Cena oproti 5900x je vyssia o 140€, tak som nesvoj, ci sa to vyplati

[Michal Kubeček]

Ty výsledky vypadají podezřele, důležitá otázka asi je, na čem to testovali. U dostatečně rozsáhlého projektu s mnoha soubory a rozumně udělaným buildem bych čekal výrazně větší rozdíl než 4 procenta. Ale samozřejmě nejvíc záleží na tom, co na tom budete dělat vy, zdaleka ne všechno se dá efektivně paralelizovat na 32 procesorů.

[Reklama]

[JurajP]

Tiez sa mi to zda zvlastne, ze rozdiel su len 2s. Co sa tyka mojej prace, tak produkt je velky monolit, vyvijany vo VS, s vela projektami. Momentalne rebuild bezi tak 2.5min, co je dost dlho. Potom napr. spustanie testov

[Michal Kubeček]

Jedna možnost je pustit si během buildu top a podívat se, jak je to s vytížením CPU, ale to se v průběhu buildu může dost měnit. Lepší je rovnou celý build pustit pomocí příkazu time a vydělit součet hodnot "user" a "sys" skutečným časem ("real" nebo "elapsed"). Ideálně by mělo vyjít číslo blízké počtu logických procesorů (s hyperthreadingem dvojnásobek počtu fyzických jader), čím je ten poměr nižší, tím hůř dokáže build vícejádrový procesor využít.

[Vít Šesták (v6ak)]

V zásadě souhlasím, akorát s Visual Studiem bych čekal, že tazatel má Windows, a použije jiné nástroje. Tuším, že i nějaký vestavěný správce úloh dá lepší představu, jak moc je build schopen vytížit více jader.

Rebuild 2.5 min mi přijde celkem dlouho. Neznám ten projekt, ale čekal bych, že větší věci se budou rebuildit inkrementálně, a vhodným buildem to půjde stlačit více než lepším procesorem.

Testy by většinou měly být schopny běžet paralelně, ale záleží. U unit testů to problém asi nebude. U složitého integračního testu to může být komplikovanější a někdy třeba i nežádoucí kvůli RAM. To, že je paralelní běh testů v principu možný, ale neznamená, že tak ty testy reálně běží. Může si to vyžádat nějaké úpravy.

Pokud začnete u analýzy buildu a testů, nejspíš se dozvíte, kolik jader využijete, a možná vám nakonec bude stačit i stávající procesor. Pokud začnete u upgradu HW, jednak to bude střelba od pasu a jednak může být dopad celkem malý. Možná i jen v rámci zrychlení jednojádrového výkonu. V extrémním případě by dokonce bottleneck mohl být mimo procesor (třeba I/O) a jeho upgradem byste si nepomohl ani trošku.

[Michal Kubeček]

Ze zkušenosti můžu říct, že už mezi 2700X a 3900X je docela výrazný rozdíl i ve výkonu na jedno jádro, 5900X oproti 3900X ještě další kus přidá. Ale pokud předpokládaná zátěž nedokáže 24 threadů využít, nemá samozřejmě dvanáctijádrová verze smysl (a možná ani osmijádrová).

V extrémním případě by dokonce bottleneck mohl být mimo procesor (třeba I/O) a jeho upgradem byste si nepomohl ani trošku.

Build rozsáhlejších projektů zásadně dělám na tmpfs, právě proto, abych procesor(y) využil naplno a nezdržovalo je něco jiného.

[Vít Šesták (v6ak)]

Build na tmpfs je IMHO většinou zbytečný, zejména v době NVMe SSD. Ano, budou specifické případy (teď mě napadají testy se skutečnou DB, byť tam bývají i jiná řešení jako vypnutí fsync), kdy se to hodí. Jinak ale:

* Načtení zdrojáků bude asi rychlé, byť latence bude stále vyšší než z RAM. Když bych to chtěl řešit, mohu hodit zdrojáky do cache tím, že je načtu (něco jako find -type f -print0 -execute cat > /dev/null). To můžeme udělat i pro některé soubory knihoven, které máme v jiném adresáři.
* Zápis může zdržovat fsync, pokud na něm kompilátor trvá. (Nemám moc přehled, jak moc to řeší který kompilátor.) Kdybych to chtěl řešit, mohu použít něco jako eatmydata, akorát musím dát pozor na zápisy mimo build dir (například udělat cargo fetch předem). Po buildu se hodí spustit sync, aby se vše zapsalo. Pokud nevydrží (výpadek proudu, kernel panic, …), může se hodit čistý build.
* V principu totiž kernel umí pracovat s RAM místo fyzického úložiště celkem transparentně. Něco může vyřešit sám (např. opakované čtení) naprosto automaticky, někdy to může chtít napovědět, co má udělat předem (číst všechny soubory z jednoho adresáře; lze dělat i paralelně po zapnutí buildu), někdy je potřeba říct, co si může dovolit (eatmydata, permisivní mount options jako data=writeback a další).

V době HDD to s dostatečnou RAM asi mělo celkem smysl. S rychlými SSD sice věřím, že takové případy najdete, ale zároveň často to IMHO bude zbytečná práce, a čtení+zápis (tj. kopírování do/z tmpfs) nemůže probíhat paralelně s buildem.

Pokud máte po ruce nějaký veřejný projekt, kde si myslíte, že kopírování z a do tmpfs má smysl, mohu zkusit jednotlivé přístupy změřit. Podmínka je, aby šel snadno buildovat.

[Michal Kubeček]

Je to znát i na rychlosti, i když samozřejmě zdaleka ne tolik, jako u klasických magnetických disků. Ale jsou i jiné důvody, např. mi nepřijde moc praktické používat SSD s jeho relativně omezeným počtem zápisů na opakované generování velkého množství souborů s praktickou užitností v řádu sekund, nanejvýš minut.

[by_cx]

Je to znát i na rychlosti, i když samozřejmě zdaleka ne tolik, jako u klasických magnetických disků. Ale jsou i jiné důvody, např. mi nepřijde moc praktické používat SSD s jeho relativně omezeným počtem zápisů na opakované generování velkého množství souborů s praktickou užitností v řádu sekund, nanejvýš minut.

Vzhledem k ceně SSD a k faktu, že se ten parameter se zápisy dá hlídat, to je úplně jedno. Na pracovním notebooku se v ničem neomezuju a za rok jsem na jeho SSD zapsal 16 TB. Na domácím serveru za rok a půl 103 TB. V obojím mám stejné disky, takže server to má podle papíru na 8+ let a notebook na 37 let. V obou případech disky vyměním dlouho před hranicí jejich plánované životnosti.

[Vít Šesták (v6ak)]

Tak nějak; v době, kdy jsem si z cenových důvodů k HDD koupil malé ~120GiB SSD, mi to dávalo smysl řešit. Dnes moc ne.

[Michal Kubeček]

To si holt každý musí rozhodnout sám za sebe. Ale jak už jsem psal, je to poznat i na rychlosti, takže moje volba je jasná.

[JurajP]

Tak nakoniec som zobral 5950x. Skusal som merat rebuild a vyslo mi to 4:19min. Vypol som analyzery pocas buildovania a dostal som sa na 3:38, aj tak sa mi to zda moc. Co mame pc v office kde je 5750G tak tam rebuild vysiel na 6:11min.