Názory k článku Nový ARM procesor pro servery jde na trh: 32jádra Ampere eMAG budou v serverech Lenovo

A populární nebudou. Proč taky? Proč měnit ověřenou, funkční a cenově příjemnou platformu x86, která nemá problém s podporou karet, SW, apod. za plarformu, kde doslova číhá past vedle pasti?

Těch pár malých nik, kde vynikne ARM jako platforma to nevytrhne. Zleva to drtí AMD s Intelem, zprava zase Oracle. V podstatě si dokážu představit jen jedno nasazení, a to jako laciný webserver pro malé webíky, tedy něco, v čem kdysi excelovaly např. Cobalty s MIPSem. Jen tak mimochodem, i ten Cobalt nakonec přešel na x86...

Překlep: L2 (32kB+32kB), místo L1 (.....

Z malinko jineho soudku...
Vsiml jste si, ze Coffe CPUcka nehrazne zdrazili a zmizli i z nekterych nabidek? Viz treba czc, kde je skladem akorat i5 8600 za 6500,- a pak 8086K za 13990,-....
???

I kdyby firma Ampere s procesory eMAG neuspěla, nebude to až taková tragédie, během vývoje může nashromáždit zajímavé poznatky, o které by jinak zůstala ochuzena. Experimenty a "hledání nových cest" bych určitě nepodceňoval, při tomto přístupu jsou nějaké ty nezdary běžné, důležité je nebát se jich. Podle (zbytečně povýšeného a kategorického) postoje pana tynyta jsou lidi z firem Ampere a Lenovo nazdárci, mohli si ušetřit "zbytečné mrhání časem a prostředky" :-). K popukání (nebo spíše k pláči), tihle "vysokopřeosvícení vševědi", skálopevně zašroubovaní ve svých pozicích. Doufám, že Mr. tynyt se "nové konkurence" nebojí ! Budu držet palce, aby ověřená, funkční a cenově příjemná platforma vydržela :-).

"Proč měnit ověřenou, funkční a cenově příjemnou platformu x86,"
:D x86 je možno overená platforma ale určite nie až tak funkčná a rozhodne nie cenovo príjemná.

A k dôvodu: možno to že to má dvojnásobný výkon na wat v porovnaní s Intelom, čo je vo väčších serveroch dosť žiadané.

Musím souhlasit s Jojioo, že x86 určitě není "funkční a cenově příjemná", ověřená možná je.
x86 je CISC - složitá instrukční sada se stovkami instrukcí. ARM (a např. i MIPS) jsou RISC - redukovaná instrukční sada co obsahuje pouze rozumné minimum instrukcí (tzn. je nenáročná na HW (počet tranzistorů) a tudíž levná a s nízkou spotřebou) a dané instrukce provádí co nejrychleji. RISC tudíž zvládne rychleji zpracovat základní instrukce, ale pak příjde jedna CISCová instrukce a RISC jádro musí stejnou práci rozložit na např. 100 instrukcí.

To rozumné minimum počtu instrukcí je zrovna u ARMu a MIPSu (obojí 32 bitové varianty) tuším okolo 30-40 instrukcí. x86 za ty dlouhé roky povyskočila na několik TISÍC instrukcí.
Už teď je jasné, kde je hlavní problém x86 - obrovský počet (zbytečných, duplicitních i archaických) instrukcí šíleně komplikuje decode stage => tuna zbytečně spotřebované energie a tuna zabraného prostoru.
Ale to není vše. x86 podporuje jakoukoliv délku instrukcí od 1-15B (ale vždy musí být délka násobek Bytů, nemůže mít délku 10 bitů). Takže když dekodér dékóduje instrukci, musí v prvním Bytu přečíst určité bity a z nich zjistit, jak dlouhá je instrukce - ale dekodér nezjistí finální délku, zjistí pouze jestli je délka 1B, 2B nebo 3B+ (tohle je jen příklad, ve skutečnosti to je jinak). Takže dekodér pak musí skočit do 3B a zjistit jak dlouhá ta instrukce je. To opakuje dokud se nedočká finální délky. Hurá, konečně (teprve) jsme zjistili délku instrukce. Teď může dekodér konečně začít zjišťovat délku druhé instrukce a zároveň musí dekódovat tu první - zjistit co to vlastně je za instrukci z těch několika tisíc. Např. jádro Zen je dělané na 6 instrukcí za takt. Teď si vemte, jak šíleně komplikovaný musí být decode stage, aby během každého cyklu zvládli dekódovat 6 instrukcí. A navíc to nejde ani paralelizovat - nelze dekódovat druhou instrukci dokud se nezná délka první. To samé třetí a čtvrtá instrukce.

Instrukce ARM a MIPS jsou dlouhé 32b. Všechny. Tudíž jde dekódování jednoduše paralelizovat, protože předem známe délku všech instrukcí. Ale ona ta paralelizace není ani zas tak potřeba, když je nutné vybrat jen z 30-40 instrukcí.

A tohle je jen jeden z mnoha problémů 50 let staré (!!!) x86. AMD a Intel (a VIA a Cyrix) kolikrát přidávají/li úplně zbytečné nebo duplicitní instrukce, Intel několikrát přidal instrukce se stejnou opcode jako používala už konkurence pro jinou instrukci - konkurence pak musela implementovat speciální módy, kdy při módu x daná opcode znamená instrukci A a při módu y je to instrukce B. Celá ta instrukční sada je roztříštěná, je v ní doslova bordel a má kořeny v 50 let starém procesoru.

Kdyby se vytvořila nová instrukční sada, která by byla správně regulovaná (tj. všechny nové instrukce by byly zhodnoceny odbornou porotou/komunitou a až pak přidány /zavrhnuty) povyskočil by výkon minimálně na dvojnásobek oproti dnešním x86 CPU. O něco takové se snaží Forwardcom.

Tudíž se určitě nedá říct, že by x86 byla funkční a levná. Je drahá, protože jen decode stage může být 10x (i mnohem víc krát) větší než u RISCU (nebo normálního nezpackaného CISCU).

Není nad to argumentovat ad hominem, když už ty věcné argumenty chybí, nebo jsou chabé, že?
To s tou "cenově příjemnou platformou" byl zřejmě žánrový vtip.

Směj se jak chceš, ale pohádky o 2x výkonu na watt si nech pro dětičky ze školičky. To platí možná na nenáročné aplikace typu web, ale na klasické aplikační nebo SQL servery je ARM krátký. A bude krátký. Protože jakmile dokopeš ARM na výkonnostní level x86, tak spotřeba se dorovná taky - a protože půjde o malosériovou výrobu, bude to dražší než bulkové 1U a 2U servery třeba od dellu, který se v lowcostu už dostal na cenu lepšího domácího PC. Tyhle marketingové žvásty o efektivitě jsou prostě jen žvásty, nic víc.

Nakonec zjistíš, že podpora toho skvělého ARMu se omezuje na malé množství linuxových distribucí, pro které, jaké překvapení, je málo aplikací (pokud si člověk nevystačí s tím apačem nebo nginxem z distra) a co hůř, komerční closed source aplikace nejsou, nebo jsou dražší, než jejich x86 verze, protože co? No přece náklady na další platformu a podporu.

Jen pro info: alternativními platformami se zabývám už 20 let (začínal jsem kdysi právě tím Cobaltem), za tu dobu jsem zkompiloval stovky různých projektů, dokonce i dělal úpravy jednoho většího aplikačního balíku, aby vůbec na dané platformě fungoval. Takže si myslím, že o tom něco málo vím. Storky o efektivitě ARMu (s výjimkou výše uvedeného případu farmy malých webserverů) pokládám za lež, realita je úplně jinde.

A ještě k tomu má x86 tunu typů (formátů) instrukcí. MIPS má pouze 4 (R, J, I, F). To taky zrovna decode stagi neulehčí práci.

malé překvapení: x86 je RISC už dávno. Jen je obalený mikrokódem, který "emuluje" CISC sadu x86.
O to ale nejde, ty směšuješ dvě různé věci - instrukční sadu a registry+výpočetní jednotky, které tyto instrukce provádějí. A jak správně píšeš, jde o univerzalitu, kterou dnes x86 nabízí. Vývoj x86 je totiž protkán tím, že tato platforma postupně na sebe nabaluje koprocesory. Kdysi dávno v dobách i80386 jsme jásali nad integrací MMU, pak u i80486 nad integrací FPU, atd. atd. Nyní dříve či později přijde integrace GPU - nikoli jako grafického čipu, ale jako výpočetního koprocesoru (signály tu už jsou pár let). Proti tomu ARM zatím zaintegroval pouze dekodéry videa, a to ještě nestandardně, tj. každý výrobce to má trochu jinak, což ovšem u Linuxu nevadí, pokud jsou k dispozici OS zdrojáky. Je tak logické, že ARM svou efektivitou nemůže v desktopu konkurovat vysoce specializovanému, ale zároveň vysoce univerzálnímu x86. A já myslím, že to tak je dobře, ARM je specializován na mobilní zařízení, kde exceluje a skýtá přesně ty vlastnosti, které jsou tam potřeba (a naopak x86 nemá moc šancí, protože nemá jak předvést, že toho umí víc). Je to jako srovnávat traktor a supersport, obojí má kola, volant a pedály, ale zcela rozdílné zaměření. Se supersportem se dá jezdit téměř všude, ale ne po poli. Naopak, traktor je na poli jako doma, ale na silnici je to brzda a na dálnice se s ním nesmí.

A ještě douška. To, že je něco starého ještě neznamená, že to je k ničemu a překonané, často je to právě naopak. Zejména to platí v ICT (což je paradox), kde spousta důležitých systémů běhá na starých systémech, protože jsou kriticky důležité a tyto systémy se během let projevily jako extrémně stabilní a spolehlivé. Zpětná kompatibilita x86 je jednou z takových skvělých kotev, které ICT drží pohromadě, navzdory Nadellům, Jobsům a podobným metroajťákům. To, že x86 v počítačích nemá konkurenci dokazuje, že platforma jako taková byla navržena dobře (ačkoli i v dobových konkurenčních bojích nebyla nejlepší, např. MC68k byl o dekádu jinde) a stále si udržuje svůj statut defacto standardu. Umělé pokusy začít "znova a lépe" jsou naprostým nepochopením evoluce, nepochopením principů ICT a jsou předem odsouzeny k nezdaru. Jako příklad lze uvést Transmetu, která to kdysi chtěla nenásilně změnit s Crusoem a zcela logicky neuspěla...

Fór je ale v tom, že když ti nejde o nejnižší spotřebu, tak CISC má díky složitějším instrukcím daleko kompaktnější kód. To má za následek potřebu menší cache, nižší datové přenosy. Pro "plnotučné počítače" je tedy CISC architektura paradoxně sice složitější, ale lepší, než RISC.

Ak niekto potrebuje maly web server s mailovym servrom a nejakym internetovym obchodom za ktory plati par desiatok eur mesacne, tak server s ARM procesorom mu moze viac vyhovovat a byt za nizsiu cenu ako server s xeonom, ktory je spomaleny kvoli meltdown, spectre a dalsim opravam a v niektorych OS ma uz vypnuty hyperthreading. Vsetko je to o prioritach.

Instrukcí jako takových je tam opravdu jen okolo 50-60, ale samozřejmě když se započítají různé varianty dané instrukce (např. rozdílné adresovací módy - ADD který sečte dva registry a ADD který k číslu v registru přičte číslo obsažené přímo v instrukci) tak jejich počet vyletí na několik stovek.

To, že jsou instrukce rozděleny na micro opy nic nemění na tom, že decode stage je až ohavně pomalý.

Já se na daný problém díval čistě na HW úrovni, vy do toho taháte situaci na trhu (tzn. že x86 je dlouhozavedená a ověřená platforma). V momentě kdy si odmyslíte to zázemí co x86 má, zůstane Vám prehistorická instrukční sada kterou zatěžuje spousta problémů.

"Umělé pokusy začít „znova a lépe“ jsou naprostým nepochopením evoluce, nepochopením principů ICT a jsou předem odsouzeny k nezdaru."
S tímhle postojem by jsme zůstali někde ve středověku. Vždyť s tímhle přístupem by tu nebyly ani SSD - HDD jsou dlouhodobě ověřené a jsou tu už postavené továrny, proč začínat znovu a lépe s SSD? Nokia a její Symbian dlouhé roky dominovali trh s telefony, proč začínat znovu a lépe s Androidem/iOS/Windows phone? Do jisté míry to platí i s přechodem na 64 bitů (nové CPU sice uměly 32 bitové programy, ale staré CPU 64 bitové programy neumí), vy si dokážete představit že by všechny CPU měly max 4GB RAM?
Když se podíváte na vývoj IT z jakéhokoliv směru, zjistíte, že trh se sice drží standardu, drží se ho dlouho, ale po určité době vždy nastane bod, kdy se zahodí kompatibilita a jede se od znovu. Ať už je to životnost socketu nebo instrukční sady.

To je nezmysel a x-krát to bolo vyvrátené. Tá variabilná dĺžka totiž v prípade x86 znamená že niektoré inštrukcie majú až 15B (tj. 120 bitov).

Ono čisto logicky a všeobecne, na zakódovanie určitého množstva informácií (o presunoch a operáciách s dátami vrámci programu) je nutné približne rovnaké množstvo bitov bez ohľadu na architektúru, pokiaľ sú ISA navrhnuté rovnako optimálne.

Na druhej strane v prípade variabilnej dĺžky inštrukcie je nutné mať uschovanú informáciu o jej dĺžke. V prípade x86 kde v začiatkoch nerátali s takouto dĺžkou a preklad teda prebieha postupne to znamená pri že pri granularite 8b zaberá 12% kódu len samotná informácia o dĺžke inštrukcií.

Na malý web ti bude bohatě stačit blade osazený nějakým serverovým Atomem - teda pokud už na takovou věc budeš plýtvat baremetalem a nevyřešíš to virtualizací (což je teda IMHO lepší řešení) např. na EPYCu (pokud ti nevoní Intel)

Jednoduše řečeno, možnosti tady už jsou, a jejich univerzálnost/variabilita je v podání x86 větší/lepší.

Sám jsem fanda alternativ (MC68k, PPC, MIPS, ARM, ...), ale jsem realista - tyhle platformy dnes v klasickém segmentu serverů nemají co nabídnout. (jejich místo je dnes v oblasti mikrokontrolérů, řadičů apod.)

Jenže SSD není umělý pokus, který nic nepřinesl.
A podobně Symbian, který byl evolučně první, ale kvůli své architektuře (a nevoli Nokie) nešel tou evolucí dál, takže byl předběhnut Applem a Googlem.

Já se totiž znova ptám: kde je přínos ARM platformy? Kde je ten rozdílový element oproti x86? Já žádný nevidím, kromě "pocitového" elementu že to není x86. A to je IMHO málo.