Názory k článku
AMD představilo serverové CPU Naples se 32 jádry
-
gngl (neregistrovaný)
A co to je ten "Xeon E5 V4"? ;)
Jinak vzhledem k velice příznivým provozním parametrům i současného Zenu (osm jader při TDP 65W má frekvenci 3 GHz) je dost dobře možné, že 32 jader při plánovaném TDP 180 W (45W na každou osmici) bude mít výrazně větší frekvenci než těch intelích 2,2 GHz. Někdo to snad odhadnul na 2,8 GHz, což by byla asi solidní facka pro Intel.
-
Michal Kubeček (neregistrovaný)
A co to je ten "Xeon E5 V4"? ;)
Xeon E5 v4 (třetí revize řady Xeon E5)
-
j (neregistrovaný)
Ani ne, kdyz intel je per jadro 2x rychlejsi ... takze 32/44 = 70%. Tudiz kdyby AMDcko melo pri tech 32 jadrech frekvenci o zhruba 30% vyssi, tak by +- dorovnalo toho intela.
Pricemz intel ty svy procaky uz rok vesele prodava. Tudiz narozdil od AMD pro nej snizit cenu neni zasadni problem.
-
-
Já myslel, že s AVX/AVX2 instrukcemi je to výrazně složitější, protože některé mohou mít latenci i několik set cyklů, takže to, že to RyZEN řeší AVX2 instrukce jinak (přes 128 bitové vektorové jednotky, pokud mě paměť neklame) neznamená, že jsou AVX2 operace 2x pomalejší než u Intelu. Koneckonců tomu odpovídají testy rychlosti u Blenderu a Handbrake, kdy RyZEN překonává rychlostně srovnatelný CPU 8C/16T od Intelu.
Nevím o tom, že by 2x pomalejší vykonávání AVX2 kódu bylo někde oficiálně potvrzeno či oznámeno. Našel jsem to jen v pár diskuzích jako příspěvek některých lidí, kteří nikde nepsali zdroj.
Pokud je to jinak, rád si to nechám vysvětlit. -
Petr (neregistrovaný)
Několik set cyklů? :) To je cache miss! I instrukce typu v[p]gather[xx] mají latenci tak 10..20.
Ještě nemám hotový Ryzen, ale latence/rcp SkyLake je k dispozic zde v sekci Performance: AsmGrid
PS není to ještě úplně hotové..
-
Tak jsem to pohledal, ať nevaříme z vody... Dle tohoto materiálu http://www.agner.org/optimize/instruction_tables.pdf instrukce VMOVNTDQ (AVX2) má latenci okolo 400 cyklů. Jsou další instrukce z AVX2 sady, které mají latenci v jednotkách cyklů. Jak je na tom RyZEN jsem nikde nenašel, ani to, že by ty operace měly být 2× pomalejší než u Intel CPU. Máte někdo nějaký zdroj s průkaznými informacemi?
-
Petr (neregistrovaný)
Instrukce typu movntdq/vmovntdq bych ani neporovnával. Jejich použití je tak specifické, že na typický workload o nich nemá smysl přemýšlet. Setkal jsem se i s tím, že programátor právě použitím těchto instrukcí běh programu zpomalil.
Jinak já si ještě pamatuju movntq z dob MMX, kdy byla obecně cache malá a právě tyto instrukce mnohdy znamenaly zrychlení 2x/3x (linux je tehdy používal pro čištění stránek).
-
FíkZlatý podporovateljedna má latenci několik set, asi ji ani žádný kompilátor nepoužívá. většina má na intelu latenci 1 na zenu bude mít 2
-
Bude mít? Jakože zatím nemá? :-D
Ty latence jsou dle toho odkazovaného materiálu minimální možné, mohou být za běhu větší. Např. cache miss atd.
Další info co jsem našel je, že Intel při vykonávání AVX kódu throttluje.
Pořád mám dojem, že porovnávat to na základě jedné hodnoty u těchto rozdílných architektur je k ničemu. Je třeba udělat průkazné testy vykonávání reálného kódu. Benchmarky např. u již zmíněného Blenderu, Handbraku, ale také dalších napovídají, že to bude jinak.
Připomíná mi to jako když někdo začne porovnávat obsah motoru a přitom tahle hodnota nic nevypovídá o výkonu a dokonce ani výkon samotný nic nevypovídá, protože daleko více vypovídající je výkon vztažený na hmotnost.
Jsem hodně zvědavý, jak si v tom RyZEN povede, konkurence tu velmi chyběla. -
FíkZlatý podporovatel
Je to složitější. Zen umí AVX2, ale trvá to dvě instrukce. Takže teoreticky by byl v AVX2 kódu dvakrát pomalejší. Čistě AVX2 kód ale není častý ani pravděpodobný
-
Takže jestli to chápu správně, tak RyZENu trvá naládování AVX2 instrukce do vektorové jednotky 2 cykly (po 128 bitech) a to samé uložení výsledku, ale o tom, kolik která instrukce trvá cyklů se tam nepíše. Takže pokud budu předpokládat, že to trvá stejně jako u Intelu (dle Petra výše), který průměrně vykonává AVX2 instrukce 10-20 cyklů, tak to u RyZENu bude trvat 12-22 cyklů? Což je o 10-20 % déle nikoli +100 %?
-
Petr (neregistrovaný)
Jenom bych opravil, že víc než 10 cyklů jsou jen specifické instrukce. Integer operace mají lat. 1, integer multiply 5, floating point add/mul 4, a pak jsou další jako dělění atd. Pak jsou horizontální operace, které mají u Intelu obecně víc. V podstatě se to dá vyčíst z té tabulky. Co je u AVX nepříjemné jsou permutace, které mají na Intelu latency 3.
-
Je nějaký materiál, jak to má RyZEN? Protože bez těchto informací je zmínka o dvou cyklech pro load/store pro vektorovou jednotku s informační hodnotou 0, vzhledem ke zcela odlišné vnitřní architektuře procesoru. Core i* a RyZEN jsou IMO na takové, z kontextu vytržené srovnání jedné hodnoty příliš rozdílné.
-
Martin (neregistrovaný)
Zde jsou latence a propustnosti různých instrukcí Zenu, podobně jako je určitě brzo zveřejní Agner:
http://users.atw.hu/instlatx64/AuthenticAMD0800F11_K17_Zen_InstLatX64.txt
... podle těch čísel je propustnost AVX instrukcí na Zenu opravdu poloviční oproti SSE. Tedy v některých případech, kdy by nebyla limitem propustnost pamětí, může mít jádro Zenu poloviční "výkon" oproti jádru Intelu.Celá sbírka s mnoha dalšími procesory zde: http://users.atw.hu/instlatx64/
-
Koukám na to, ale instrukcí AVX2, které trvají dvakrát déle zas tolik není, častěji to je méně, často stejně a jindy to je i opačně, kdy Intel má latenci výrazně vyšší. Zajímavá je také propustnost. Takže mi to spíše přijde jako zmiňovaný rozdíl architektur. Když k tomu připočtu řídkost AVX2 instrukcí, vykonávání instrukcí mimo pořadí..., dopadá to v reálu tak, jak to ukazují benchmarky reálných aplikací. Zajímavé.
U AVX a ostatních instrukcí je to úplně jinak.
Opravdu klobouk dolů před AMD, co v těžkých podmínkách dokázalo. I při horším výrobním procesu, v první 14 nm generaci oproti již vyladěnému výrobnímu procesu Intelu v několikeré generaci.
Každopádně pomalejší vykonávání AVX2 instrukcí mi přijde jako zajímavá výkonnostní rezerva pro budoucí generace Zen architektury.
Moc díky za zdroj, hodně zajímavé čtení :-) -
Martin (neregistrovaný)
Podívejte se hlavně na tu propustnost. Ta je opravdu u většiny AVX/AVX2 instrukcí poloviční oproti Intelu (jsou uvedeny obrácené hodnoty, tedy dvojnásobné). Latence jsou místy u Zenu lepší, ale na tom příliš nezáleží u kódu, kde je velký paralelismus na úrovni instrukcí (většina kódu s AVX/SSE). Jak jsem ale psal dříve, tato výhoda Intelu se projeví pouze tam, kde kód nebude limitován propustností paměti.
Tímto každopádně nechci nijak zpochybňovat, že je Zen skvělá architektura a je mi jasné, že z toho budeme mít užitek všichni, včetně zákazníků Intelu, protože ceny půjdou dolů. Jen prostě pro některé specifické nebo dobře optimalizované úlohy bude Intel lepší volbou.
-
Peter FodrekZlatý podporovatellenžedoteraz najstarší CPU od AMD stál 4200 USD/ kus a len jeden z 22 jadier Intelu je lacnejší.. Takže máme nábeh na najdrahší CPU od AMD v histórii. 2-2,5× vyšší výkon je celkom sila 5000 USD za kus si môže AMD pýtať.
E7-8880 v4 (55M cache, 22 Cores, 44 Threads, 2.20 GHz (150W) 9.60 GT/sec Intel QPI, 14nm) $5,895 $5,895
E5-4669 v4 (55M cache, 22 Cores, 44 Threads, 2.20 GHz (135W) 9.60 GT/sec Intel QPI, 14nm) $7,007 $7,007
E5-2699A v4 (55M cache, 22 Cores, 44 Threads, 2.40 GHz (145W) 9.60 GT/sec Intel QPI, 14nm) $4,938 $4,938
E5-2699 v4 (55M cache, 22 Cores, 44 Threads, 2.20 GHz (145W) 9.60 GT/sec Intel QPI, 14nm) $4,115 $4,115
https://www.intc.com/investor-relations/investor-education-and-news/cpu-price-list/default.aspx
-
[joke]Mně se ty procesory nelíbí... víte, jak bude hnusnej htop, když bude muse zobrazit 128 jader? Fuj![/joke]
Ale vážně... fandím jim. Ne že bych hned chtěl objednávat nějaký AMD, to si počkáme na reálný testy a zkušenosti, v segmentu serverů nejde ani tolik o cenu, dolar sem, dolar tam, ale takový přetlačování Intel vs AMD o výkon, nový technologie atd, to by byla po dlouhá době krása... -
Ondra Satai NekolaZlatý podporovatelPokud to chapu, tak se chces dostat do stavu, ze ktereho se naopak tazatel tady chce dostat? ;)
https://unix.stackexchange.com/questions/127126/display-numbers-in-meters-of-htop
-
qwertz (neregistrovaný)
tupe opisovani nesmyslu z jinych webu by vam slo. Xeon E5 v4 totiž podporuje 1.54TB RAM / 2400MHz.
Ten test je průhledně zfušovaný. Skvěle to shrnul jeden comment na Techreportu:
"...So AMD showed off how badass they are when you don't put enough memory into the Intel system.
Just wait until Intel shows an Atom destroying the 1800X when the 1800X doesn't have a motherboard!..."http://techreport.com/news/31549/amd-naples-platform-prepares-to-take-zen-into-the-datacenter
-
tnr (neregistrovaný)
V prezentaci je jasne napsano,ze se jedna o hodnotu pro 16gb dimm. Coz neni uplne bez zajmu,amd zde vyuzije vetsiho poctu kanalu (rychlejsi) a vetsiho mnozstvi celkove ram. Je to samozrejme srovnani vybrane schvalne,ale me to docela zaujalo,16 gb moduly jsou totiz hodne levne oproti vyssim.
-
qwertz (neregistrovaný)
To moc není argument pro srovnání tohoto typu. Rozdil mezi nejlevnejsimi RegECC Kingston 16 a 32 GB na CZC je 3400CZK VS. 8800CZK, to je 4400CZK/16GB u 32GB modulu, to je úspora 28% při použití dvou modulů místo jednoho. A vyplatí se to? Jak vyčíslit ztrátu z potřeby většího místa v racku (plus energie, chlazení a pod.)? Prostě to srovnání nějaký kulhá a zbytečně shazuje test, který mohl být zajímavý.
-
qwertz (neregistrovaný)
A o kolik to zvedlo výkon a v které aplikaci?
Abyste mohl nad reálným přínosem mohl diskutovat, chtělo to právě osadit Intel stejným množstvím RAM. pak by bylo vidět který přístup v kombinaci s procesorovou architekturou je výhodnější. Takhle vám výsledek ovlivňuje ještě parametr "množství paměti".
-
tnr (neregistrovaný)
No, on ten test byl asi docela nesikovne prezentovany (nebo interpretovane novinari, co AMD prezentovalo). To, ze ma AMD moznost osadit vice modulu a 2x tolik kanalu, je jednoznacna vyhoda pro memory contrained aplikace (a tem ostatnim to muze taky jen prispet, navic stejna konfigurace pameti je pak levnejsi, takze to v podstate zadne nevyhody nema). Jak moc melo vliv mensi mnozstvi pameti u Intelu na vykon v prvnim testu je mozne spekulovat - spravne by nemel byt zadny nebo skoro zadny, pokud je to memory constrained / cpu constrained benchmark (a samozrejme za predpokladu, ze se ta data cela pohodlne vesla do pameti - coz predpokladam, ze ano - protoze jinak by ten rozdil byl radove jiny)
-
j (neregistrovaný)
Hezky ... a pak zjistis, ze realne v 99,9% aplikaci je rozdil 0,01%.
Kdykoli kupuju HW, davam do nej nejvetsi dostupny moduly co se daj sehnat. Protoze do budoucna je daleko hodnotnejsi volnej slot pro rozsireni ty RAM, nez 00prd vykonu navic.
A ze by kazdy jadro pristupovalo ke svymu modulu, tak to bych chtel videt, jak bys naprogramoval. To bys totiz musel pri kazdym spusteni ty aplikace resit na urovni HW, jak je zrovna RAMka organizovana, coz ti jaksi ten HW ani nerekne, takze bys sebou leda musel tahat databazi vzemoznyho HW, podobne jako to dela hwinfo a dalsi. A pak bys musel tak trochu ... vic ... vyradit z provozu system, aby sis moh zapisovat a cist tam kde chces ty, a ne kde ti prideli prostor system. Jo a jeste by sis musel sam ridit, na kterym jadre co pobezi, protoze on to system vubec nesoupe sem a tam podle toho jak se mu to zrovna hodi.
-
Ondra Satai NekolaZlatý podporovatel
Ty neumíš nastavovat afinitu? (Ne, že by to byla úplně běžná praxe, ale když se řeší výkon a zejména latence...)
-
VS (neregistrovaný)
> To bys totiz musel pri kazdym spusteni ty aplikace resit na urovni HW, jak je zrovna RAMka organizovana, coz ti jaksi ten HW ani nerekne
To HW samozřejmě řekne operačnímu systému, viz NUMA, a CPU affinity pak má pochopitelně vliv i na alokaci paměti na shodném NUMA uzlu (velmi zjednodušeně).
-
tnr (neregistrovaný)
Jo, tak to se urcite vyplati, koupit si jeden 128 GB modul misto 8x16GB, propustnost pameti sice bude zlomek te mozne, protoze vseho jaksi musi jit pres jeden modul, stat to bude nekolikanasobne vic, ale hlavne ze mas misto na rozsirovani, co kdyby nahodou :-D
Samozrejme, pokud to budeme porovnavat pri praci jedne aplikace, ktera navic neni zatizena propustnosti pameti (coz je presne ten duvod, proc to ve spouste benchmarku skutecne vyjde jako nula nula nic rozdil), tak ano, ale to neni uplne reprezentativni load vytizene serveru (napr. hypervisoru) -
Petr M (neregistrovaný)
Úplně normálně to podporuje systém, dokonce i Widle :D Proto se paměti prodávají v balíčku po dvou kusech (aby byly stejný tolerance) a v BIOSu ne desce PC se dá zapnout dual channel RAM... Měl jsem to už dávno, ještě za 32b multicore. A na desce jsou banky s různou barvou, hádej proč?
Druhou sběrnicí pro RAM se z 64b modulu stane 128b modul (dvojnásobná propustnost) a navíc každá půlka té "paměti" může pracovat pro jiný jádro a dělat něco jinýho. V praxi je tam jader víc než pamětí a občas se čeká na sdílený data v jednom modulu, proto to nevyletí o 100%.
-
j (neregistrovaný)
2Petr M: Ne, zadnej system to nepodporuje, system proste vidi hromadu RAM a na pozadavek o alokaci nejakou cast z ni prideli. Dokonce ani nemusi platit, ze ta pridelena pamet bude v jednom kuse, natoz ze bude v nejakym konkretnim modulu.
A barvicky tam rozhodne nejsou proto, aby bylo neco rychlejsi, sou tam proto, ze spousta desek/cpu podporuje jen nejaky konkretni konfigurace pameti, a je tudiz nekde popsano, jaky moduly v jaky organizaci je mozny do toho kteryho slotu napichat. Napriklad je treba vzdy osadit slot 0, a proto ma jinou barvu nez ostatni, protoze pri jednomodulovy konfiguraci je to jedinej osazenej slot. Pripadne sou barevne odliseny banky, ale to opet prozmenu predevsim proto, ze je nanejvys vhodny do nich davat moduly stejny, protoze jinak to mozna nebude fungovat.
A presne proto se i prodavaj moduly po dvou - aby spolu fungovaly.
Serverovy zelezo umi pak v tech modulet udelat treba zrcadlo (defakto pametovej raid). Ale rozhodne nemuzes urcit kterej modul bude pouzivat ktery jadro.
-
tnr (neregistrovaný)
Je to trosku slozitejsi, nez jak si to predstavujes
U AMD mame (resp. meli jsme, u Ryzenu jsem to jeste nestudoval) dva rezimy:
Ganged - pamet se prokladanim rozdeli na stridajici se adresy podle bloku a chova se to podobne jako RAID 0, vysledkem je jedna sbernice s teoreticky dvojnasobnou propustnosti.
Unganged - obe sbernice jsou nezavisle, tzn. muzeme udelat nekolik nezavislych requestu.
Oboji funguje celkem dobre - ganged rezim je vyhodny v sirce pasma (zejmena pro vetsi requesty na MC), unganged se nejlepe vyuzije u multithreadovych aplikaci.U Intelu se pouziva interleaving pameti, CPU rozdeluje pamet na jednotlive regiony a pristupuje k nim paralelne. Dale podporuje optimalizaci pristupu pomoci rankingu (v pripade vicerankovych modulu) v ramci jednoho kanalu. Cilem optimalizaci je snizit latenci pristupu k pameti. Takze pridelena pamet v kuse v modulu neni a to je vicemene i cilem.
Pointa celeho reseni je ale to, ze OS to nemusi do znacne miry resit - staci zahltit MC dostatecnym poctem dostatecne dlouhych pozadavku - coz se bezne deje, protoxe instrukce se zpracovavaji/dekoduji/vykonavaji out of order (a navic MC pozadavky jsou mnohem vice nizkourovnovou zalezitosti nez jedna x86 instrukce).
Kde to naopak OS musi resit (a resi, zcela bezproblemu), jsou NUMA systemy, kde je pomerne velky rozdil v pristupu k lokalni pameti CPU a k sdilene pameti. Ale to samozrejme vsechny serverove OS bezproblemu zvladaji a zajistuji tak lokalitu pametovych alokaci (coz je ale docela dobry napad obecne, treba kvuli caches).
ČLÁNKY DO MAILU
