Názory k článku ARM představuje serverové procesory Neoverse V1 a N2. Slibuje o 50 % vyšší IPC a až 192 jader

V tom grafu porovnavaji vykon na vlakno u multi thread procesoru vs single thread. Cili chceme-li ziskat vykon na jadro, tak musime vynasobit intel a AMD 2x? Pak rikaji, ze jednojadrovy vykon za 2 roky bude tam, co odchazejici generace x86 CPU
S tolika jadry to bude urcite slusny kombajn, ale jenom na to, co se da jednoduse skalovat.
Ted jeste kdy na to budou ty aplikace, kdyz CPU budou za 2 roky?

64+ jader? Takže opět střelba zcela mimo na pouhé tržní niky. Jako HW pro webový server někam do cloudového clusteru asi dobrý, jinak k ničemu.

aplikace už jsou. Takový nginx nebo apache z toho budou těžit IMHO docela dost, i když s příchodem HTTP/2 už ani to není taková trága. Ve světě opensource se to asi neztratí, ale nasmál bych se, kdyby na takovém stroji chtěl někdo provozovat SW, který se licencuje per-core (a že jich takových je!). :-)

Písal som to pred pár rokmi a o pár rokov to asi budem písať znova. Vtedy to bolo A72 vs Skylake, respektíve ešte predtým A57 ktoré Intel ľahko sfúkol Xeonmi-D. Ale ide o to, že ARM má stabilne desiatky % ročne, zatiaľčo Intel bol nastavený na 5% každých 18 mesiacov s tým, že posledných pár rokov sa im to zaseklo, potom (ne)vydali Kanónlake, Icelake ktorý je horší ako Skylake a Tigerlake, ktorý má vyššiu frekvenciu, ale nižšie IPC a hlavne 64W v ultrathin.

Výsledok: 3GHz A78 ~ 5GHz Icelake. To mám od niekoho, kto sa venuje optimalizáciám. S tým že ARM je podstatne lepšie v branch prediction, out of order (riešenie závislostí medzi inštrukciami), zatiaľčo Intel má stále výhodu v optimalizovanom softvéri, knižniciach a "návodoch" pre vývojárov.

Fajn by bylo, kdyby do x86 prisel nekdo dalsi, konkurence primo na x86 je vyssi zaruka ze maknou, preci jen ARM je konkurence neprima, ale nejaky vliv snad mit bude. Ono by hodne mohlo pomoct, kdyby se zacaly delat uz jen x64 CPU, ale na to je asi jeste brzo, 32bit je porad dost rozsiren.

Souhlas,

Zajimalo by mne, jestli je nejaky zasadni duvod zakopany v architekture, proc by nemohl ARM predstihnout x86 i per core? Mozna tam pak daji nakonec hromadu ALU a podobnych jednotek a pojede na to vse, kdo vi?!

Nikdo nový už nepřijde. UMC, NEC, a pár ještě menších to vzdali dávno, Cyrix a IDT koupila VIA, a i ta je s vývojem cca 10 zpátky. Transmeta dopadla jako sedláci u Chlumce.

všechny dnešní x86 CPU jsou x64, takže se opravdu už dělají jen x64 modely (opomíjím specialitky jako soudobé i486 do embedded segmentu). Odebírat instrukce nebo dokonce celé módy ale nikdo nebude, ztratila by se tím zpětná kompatibilita a navíc většina z toho je dnes stejně jen vrstva v mikrokódu...

Problém pro ARM je to, že z malých čísel můžeš růst velmi výrazně, tudíž "procenta" ti budou naskakovat vysoká. A pak to, že posun u x86 o 5% je v absolutním měřítku srovnatelný třeba s 10% u ARMu.

ARM je RISC, tudíž jeho strojový kód je daleko "řidší" - jednodušší, ale zato delší, pokud neprovádíš nějakou triviální operaci, u které si vystačíš s několika nejjednoduššími instrukcemi, které jsou na obou platformách podobné/stejné. Takže věřím, že existuje případ, který popisuješ jako "výsledok", nicméně ten ukazuje jeden konkrétní způsob aplikace, který zřejmě ARMu sedí. Nejedná se však o všeobecnou situaci.

Zakopaný pes je v tom, že když do toho ARMu narvete všechno, co mají x86 jádra, přijdete o to, co na tom ARMu obdivujete, tedy o malá jádra s malou spotřebou, a získáte to, co nechcete, tedy velké drahé čipy s velkou spotřebou, které pak už nepřinášejí žádnou konkurenční výhodu, kterou byste přesvědčil zákazníky, aby si je začali kupovat místo těch x86.

viz předřečníci. Smysl, fór, architektur postavených jako čistý RISC je v tom, že mají velmi omezenou sadu instrukcí, které ovšem díky tomu, že jsou jednoduché, vykonávají velmi rychle. To může, a taky je, být velká výhoda u jednodušších aplikací, které se specializují na prosté I/O operace, případně se spokojí s omezeným výpočetním potenciálem. Jako příklad lze uvést právě různé webservery, fileservery (NASy) apod. Zrovna webserver nebo reverzní proxy, kde existuje milion threadů a samotný server víceméně pouze vyhodnocuje html požadavky, je takové řešení optimální. V okamžiku, kdy začneš počítat "matematiku" apod., jde takové řešení k šípku (pokud nemá k tomu speciálně určené rozšíření)

"A pak to, že posun u x86 o 5% je v absolutním měřítku srovnatelný třeba s 10% u ARMu."
No povedzme že hej, ale stále bude platiť, že relatívna pozícia ARM sa zlepší.

A teraz pridajte to, že Intel pol dekády zlepšil IPC o 0%.

"ARM je RISC, tudíž jeho strojový kód je daleko „řidší“ – jednodušší, ale zato delší,"
To sa tu už riešilo, a s modernými kompilátormi je to skôr naopak.

Navyše x86 má problém so spätnou kompatibilitou ktorá spôsobuje že jedna inštrukcia zaberá príliš veľa miesta. (x86 má variabilnú dĺžku inštrukcií)

Všetky "krátke" miesta sú už zabraté starými inštrukciami a preto musia byť nové inštrukcie extrémne dlhé, najdlhšie majú až 120b, čo je drastický rozdiel oproti 32b ktoré potrebuje ARM (pritom tá inštrukcia nerobí 4x viac mikrooperácií).

Je to problém aj pri cache, pri fetch... a najmä kvôli tomu, že Intel má síce 5 dekóderov, ale len jeden komplexný, a súčet dĺžok inštrukcií nesmie presiahnuť 128b. (Icelake)(AMD má všetky dekódery komplexné a maximum 256b).

To znamená že v prípade moderných inštrukcií padá Intel na 1IPC zatiaľčo ARM pokračuje plnou rýchlosťou (Intel to potom samozrejme dobieha starými MOV, ADD, SUB inštrukciami kde má proti ARM samozrejme výhodu).

Pak dava cesta ala lakefield smysl... kombinace ruzne vykonych jader jedne architektury pro laptop/desktop

Konfigurovane chiplety pro nasazeni v serverech site na miru.

to je velký omyl. Pozice ARMu se zlepší jen těch triviálních operacích, nikoli celkově. IPC totiž není srovnatelné (jak jsem už psal výše).

Nevím, co se kde řešilo, ale naopak to moc být nemůže, když ve většině případů je instrukce kratší, než zpracovávaná data. A opět zapomínáš, že to, co "CISC" zvládne třeba jednou instrukcí (byť dlouhou), tak u RISCu musíš "oběhat" delším kódem, často pak i několika cykly, abys nabral stejný objem dat. (srovnej si třeba počty a délky registrů). Ono to totiž není tak úplně jednoznačné.

Je logické, že kvalita kódu závisí na kvalitě kompilátoru.

AMD přežilo IMHO hlavně kvůli tomu, že do x86 přispělo nemalou měrou (měli už z dob i8080 celkem velké knowhow okolo FPU).

https://en.wikipedia.org/wiki/Intel_8231/8232


Intel a AMD jsou historicky provázaní docela hodně.