ARM představuje serverové procesory Neoverse V1 a N2. Slibuje o 50 % vyšší IPC a až 192 jader

25

ARM odhalil svůj nový úder na pozice procesorů Intel a AMD v serverech. Jádra Neoverse V1 a N2 s instrukcemi SVE mají mít až o 50 % lepší IPC a ST výkon a až 192 jader. Vyjdou sice až za rok za dva, ale i tak není jasné, zda jim x86 odolá.

Procesory ARM, ovládající dnes mobilní zařízení, už se nějakou dobu snaží dostat do serverů. V předchozích letech této dekády v tom ještě moc úspěšné nebyly, ale letos se dostala ven první CPU založená na architektuře ARM Neoverse N1 (Graviton2, následovaný Ampere Altra), která už měla docela velký ohlas.

Teď ARM oznámil další generace svých serverových architektur pro následující léta, které opět slibují agresivní zvýšení výkonu a měly by ještě zvýšit tlak na Intel (a AMD). Je možné, že tyto platformy už začnou výrazně ukusovat z podílu architektury x86 na trhu, ale samozřejmě teprv uvidíme, jak se slibované pokroky přenesou do reality.

ARM povede útok na dvou křídlech

Současná architektura Neoverse N1 odvozená od mobilního Cortexu-A76 nekonkuruje zatím procesorům x86 v maximálním jednovláknovém výkonu. Je podobně jako Cortexy navržená tak, aby dosahovala vysoké efektivity co do spotřeby a plochy, kterou jádro zabírá.

Tato strategie ovšem trošku ARM držela zpátky. Nyní proto nastupuje jiná a ARM bude mít dvě architektury. Jedna bude pokračovat v cílení na vysokou efektivitu, a bude tedy x86 ohrožovat vyšší úsporností, druhá se ale těchto limitů zbaví a půjde po absolutním výkonu, který by jinak byl výhodou Xeonů/Epyců. Zákazník si bude moci vybrat a specializace na jeden ze scénářů by měla být výhodou proti X86, kde Intel a AMD mají pro oba to samé univerzální jádro.

Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2 Zdroj: ServeTheHome

ARM Neoverse V1: maximální výkon

Architektura, která z nové generace serverových jader ARM bude zaměřená na absolutní výkon, se oficiálně jmenuje Neoverse V1. Není úplně překvapivá, v roadmapě už byla dřív vyznačená pod kódovým jménem Zeus. To není úplně náhodné – je totiž podobná jádru ARM Cortex-X1 (kódové označené Hera). Cortex-X1 také míří na vysoký výkon, i do nějaké míry na úkor energetické efektivity, takže v tomto si s V1 odpovídají. Nicméně jádro V1 bude mít svoje odlišnosti, nejde o stejnou architekturu.

Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2 Zdroj: ServeTheHome

Procesory s architekturou Neoverse V1 již mají typicky podporovat PCI Express 5.0 a používat paměti DDR5; ovšem také u nich bude možné použít jako mezistupeň velmi rychlé paměti HBM2e. Na platformě bude také podporované propojení CCIX 1.1, ale ještě ne CXL.

Podle ARMu budou typicky zákazníci s jádry V1 stavět procesory s 64 až 96 jádry. Jako o prvním kandidátu víme o firmě SiPearl, která připravuje serverové/HPC procesory pro projekt lokálních superpočítačů v EU – její čip kódově označený Rhea má 72 jader Neoverse V1 v mesh uspořádání. 4–6 kanálů DDR5 a bude opravdu používat paměti HBM2e jako cache s vysokou propustností.

Schéma procesoru SiPearl Rhea AnandTech
Schéma procesoru SiPearl Rhea (Zdroj: AnandTech)

Tip: Evropské procesory EPI pro superpočítače použijí ARM Neoverse, RISC-V na 6nm procesu

SVE

Důležitý element bude přidání podpory SIMD instrukcí SVE (to je právě jedna z odlišností proti X1). To je pokročilejší vektorové rozšíření zaměřené na HPC (výkonné výpočty, superpočítače). Zatím SVE používala jen HPC architektura Fujitsu, ale s příští generací instrukční sady ARMv9 možná bude ve všech jádrech coby součást standardu. Jádro V1 ještě není ARMv9, ale jen ARMv8, nicméně instrukce SVE již má. V jádru by měly být dvě SIMD pipeline se šířkou 256 bitů (tedy jako u AVX/AVX2).

Neoverse N1 ještě mělo jen instrukce Neon se 128bitovou šířkou, které jsou srovnatelné s SSEx na platformě x86, takže toto je značné zlepšení. Ovšem samozřejmě bude nutné, aby SVE začaly využívat programátoři, přidali tento kód do svých projektů, nebo aspoň použili autovektorizaci. Tam, kde se autovektorizuje kompilátorem, to může být celkem snadné a automatické, v multimédiích (FFmpeg, x264/x265 a další enkodéry) to typicky bude vyžadovat ruční přepsání v asembléru. Mimochodem, kromě SVE budou podporovány také výpočty s hodnotami bfloat16 pro AI.

Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2 Zdroj: ServeTheHome

Pořád bez SMT

Co procesory pořád nemají, je SMT, jedno jádro tedy stále bude jen jedno vlákno. Toto nechává nějaký potenciální výkon jednotek v jádře nevyužitý, ale ARM se vyhne sdílení jader různými procesy/uživateli (problém v cloudovém využití) a absence SMT výrazně usnadňuje návrh a validaci architektury. Plus se samozřejmě zmenší plocha jádra.

+ 50 % IPC/výkonu jednoho jádra proti dnešku

ARM Neoverse V1 má proti jádru N1 mít až 50% navýšení jednovláknového výkonu, ale poté je řečeno, že je to na stejném procesu a při stejné frekvenci, takže by šlo přímo o 50% zlepšení IPC. ARM počítá s tím, že tato jádra se budou realizovat na 7nm nebo 5nm procesu, takže možná nad rámec tohoto budou i nějaké frekvenční zisky z 5nm technologie.

ARM uvádí, že podle jeho očekávání budou procesory s těmito jádry výrazně napřed před tím, co dnes nabízí AMD a Intel na bázi x86, alespoň v celočíselných zátěžích. FPU a SIMD jednotky tedy asi pořád nebudou mít takový výkon proti AVX-512 u Intelu (a potenciálně i AMD, tam uvidíme).

Je ale třeba říci, že reálně dostupné budou procesory s těmito jádry až za nějakou dobu, takže mezitím bude konkurence také dál. Nyní ARM v podstatě ještě jen ukazuje roadmapu a ačkoliv už nějací výrobci na vývoji křemíku pracují, na trh se mohou dostat třeba až za rok, ne-li třeba až v roce 2022. Například procesory Neoverse N1 teď teprve začínají být dostupné (Ampere Altra; Graviton2 byl k mání dřív, ale jen distančně přes cloud AWS).

ARM Neoverse N1: maximální efektivita

Druhé linie, tedy ta, která má zachovávat zaměření na vysokou efektivitu, byla do roadmapy přidána až nyní, pod kódovým označením Perseus (původně byl v oficiálním plánu jen Zeus). Jádro N2 bude asi podobnější N1, bude mít menší buffery (hloubky out-of-order front) a cache. Teoreticky také může jádro V1 mít více výpočetních jednotek (ALU, AGU, FPU) a vícestupňovou pipeline pro vyšší frekvence, než jádro N1, ale to je zatím nepotvrzené. Přesná schémata a údaje zatím ARM nedává.

Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2 Zdroj: ServeTheHome

N2 bude menší jádro co do těchto struktur (takže bude mít nižší IPC a možná i frekvence), ale díky tomu bude zabírat méně místa a mít nižší spotřebu. Výkon na jeden watt a na jeden milimetr čtvereční jádra bude tedy asi vyšší než u V1.

Podle ARMu typicky zákazníci asi budou s těmito jádry tvořit 128jádrové procesory, ale výkonnější prý mohou mít až 192 jader a TDP až 350 W. Takovéto maximální konfigurace mohou teoreticky mít i vyšší vícevláknový výkon než architektury Neoverse V1 díky tomu, že do určitého limitu TDP a plochy čipu nacpou výrazně více jader (ovšem samozřejmě je pak třeba, aby úlohy škálovaly, jinak výkon nemusí být lepší).

Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2 Zdroj: ServeTheHome

IPC má být až o 40 % vyšší než u Neoverse N1 (takže ne zas tak o moc nižší, kupodivu). Opět se ale bavíme o procesoru, který reálně může být k mání až za dva roky (a později než V1). V roadmapě je architektura N2 uvedená pro příští rok, ale fyzická dostupnost od klientů ARMu jako je Ampere/Amazon atd. bude zase asi trvat déle. Tyto procesory už také údajně mají být cíleny jen na 5nm proces, takže při srovnávání s dnešními 7nm to je třeba brát v potaz. Mají podporovat PCIe 5.0, DDR5, už i paměti HBM3 a CCIX 2.0 a nyní už i standard propojení CXL 2.0.

Jádro N2 není zřejmě sesterská architektura Neoverse V1, je vlastně o jednu generaci dál, základem má být asi příští ještě neodhalené jádro Cortex (A79?). I u tohoto jádra bude podpora SVE, ale bude méně výkonná. ARM využije variabilní šířky SVE a jednotky budou mít pořád šířku jen 128 bitů jako Neon. Pipeline budou stále dvě. Numerický SIMD výkon/propustnost tedy bude proti V1 poloviční na jeden cyklus.

Next-gen: Poseidon

Po této dvojici jader bude následovat další generace architektur, která má souhrnné označení Poseidon (jména jader ještě ARM nesděluje). V plánu je uvedení v roce 2022, ale skutečné čipy asi zase budou později než to. Tyto procesory mají opět přinášet minimálně 30% zlepšení výkonu a mají nastat i nějaká zlepšení ve výkonu SIMD a ve výpočtech umělé inteligence (patrně pomocí nějakých speciálních akcelerátorů/jednotek). Tyto procesory typicky budou 5nm nebo 3nm a počítá se u nich s podporou nových generací propojení CCIX a CXL a volitelně i s PCI Expressem 6.0.

Velké problémy pro Intel/AMD?

Cíle ARMu jsou hodně agresivní a slibné, takže je možné, že výrobci x86 procesorů už opravdu budou mít velké problémy. Zejména si AMD. Intel bude déle těžit ze zabetonovanosti svých pozic a dominantního postavení, ale AMD teprv dobývá zákazníky. A může se mu stát to, že když už se někdo odhodlá odpoutat od Xeonů, řekne si, že už rovnou může změnit i celou platformu.

Je nicméně třeba opět zopakovat, že tu srovnáváme procesory ARM, které byly oznámené, ale přijdou třeba až za dva roky, se současnými/minulými procesory Intel/AMD. Neoverse V1 už bude soupeřit se Saphire Rapids od Intelu nebo Epycem Milan s jádry Zen 3, ne-li už s Genoa/Zenem 4. A samozřejmě se pořád bavíme o výkonnostních slibech a očekáváních, kdežto v praxi to může vypadat trošku komplikovaněji.

Galerie: Prezentace serverových architektur ARM Neoverse V1 a ARM Neoverse N2

Zdroje: ServeTheHome, ARM

ARM představuje serverové procesory Neoverse V1 a N2. Slibuje o 50 % vyšší IPC a až 192 jader
Ohodnoťte tento článek!
4.7 (94.29%) 7 hlas/ů

25 KOMENTÁŘE

  1. 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?

    • 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!). 🙂

      • 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?!

        • 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.

            • no… ani moc ne – aspoň u x86. Problém je v instrukční sadě. Pokud to má být opravdu jedna architektura, bude muset to „malé“ jádro umět všechny instrukce toho velkého, aby byla zajištěna koherence kódu. A z toho plyne, že můžeš ušetřit tak max. na L1, možná L2 cache – a z „malého“ jádra je opět velké. Tudy cesta nevede. Opačný přístup (tj. zakázat instrukce, které neumí malé jádro) předvedl právě Lakefield a kvůli tomu taky blbě dopadl, protože tím to plnotučné jádro zkriplil.

            • no nevim laicky si dokazu predstavit, ze scheduler bude vedet co muze na kterem spoustet a co ne. Je imho zbytecne spoustet chromova okna na velkem jadre, stejne jako herni engine na malem jadre.

              Dalsi moznost je, ze instrukcni jednotka (treba AVX2) bude sdilena mezi dve mala jadra a pripoji si ji vzdycky jadro, ktre ji zrovna potrebuje. Jadro ktere nebude mit zrovna volnou jednotku bude pocitat pomaleji na SSE (je to asi najivni predstava, ale proc ne?)

        • 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í)

          • On ARM už moc RISC není, ta 64bitová verze má IIRC dobře k tisícovce instrukcí, leccos je poměrně netriviální, teď když se k Neonu přidá SVE, tak to bude další kopec instrukcí.
            Takže už to ta jednoduchá architektura není, ta komplexnost už se na tu úroveň „velkých CPU“ dostala.

            Co z RISCu v ARMv8 přetrvává, to je hlavně konstantní délka instrukcí (32 bitů). Ta má výhody, protože to, že instrukce vždycky začínají na stejném místě, zjednodušuje instrukční dekodér proti x86, kde jsou různé prefixy a instrukce mají variabilní délku (= problém).

            ARMv8 má pak ještě druhou výhodu a tou je, že je to takové relativně čisté, protože to bylo navržené v tomhle tisíciletí (skoro i v této dekádě), není tam moc historických a už zastaralých věcí a zabetonovaných chyb z minulosti.

            Takže reálně návrhář ARM CPU bude mít proti návrhářovi x86 CPU za identických podmínek určitou výhodu. Tu fandové/antifandové asi leckdy přeceňujou, ale nějaká tam bude. Na druhou stranu x86 ji může často kompenzovat tam, kde se software léta na něj ladil. Ale když kód optimalizovaný není nebo je nový a prostě se kompiluje, tak to nebude.

            Ještě bych řekl, že doteď měly x86 výhodu v silnějších SIMD instrukcích (256bit). SVE to teoreticky může vyrovnat nebo i obrátit, ale taky třeba ne, uvidíme, jestli třeba ta univerzální šířka vektoru nebude mít i své nevýhody a nebude to zhoršovat výkon dosažitelný v ručně optimalizovaném kódu.

    • 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.

      • 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.

        • „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).

          • 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.

      • Myslím že „3GHz A78 ~ 5GHz Icelake“ úplně platit nebude (minimálně 5GHz Ice Lake neexistuje, heh…).
        Tiger Lake má ~stejné nebo horší (max. bude tak o 2% lepší) IPC jako Ice Lake a ve SPEC2006, které celkem ARMům jde, má vyšší single-thread skóre než Apple A13 a proti Snapdragonu 865+ (Cortex-A77 až na 3,1 GHz) má o 47-53 % vyšší skóre. Pokud bychom normalizovali frekvence na těch 5 a 3 GHz, tak vychází, že Tiger bude mít o 58 % až 65 % vyšší výkon. Cortex-A78 má mít jen o 4-7% lepší IPC než A77, takže když přičtu 7%, tak je pořád Tiger o 48-54 % lepší. ( https://www.cnews.cz/nova-jadra-arm-cortex-a78-cortex-x1-vykona-architektura-proti-intel-amd-apple/2/ ). A i kdyby mělo jít o Cortex-X1, tak tam nebude tak velké navýšení.
        Je možný že by ta ekvivalence platila, třeba kdyby se ten ARM zoptimalizoval hodně dobře a Ice Lake ne.

        https://images.anandtech.com/graphs/graph16084/111168.png

        Problém bych viděl spíš v tom, kolik spotřebuje Intel u Tiger Lake na těch 4,8 GHz (okolo 21 W iirc) a kolik potřebuje ten Cortex na své 3 GHz (tak 3-4 W tipuju). Tam je Intel pozadu (částečně svým 10nm procesem, částečně asi i architekturou).

  2. Chybí ale odpověď na kardinální otázku. Co na tom poběží a k čemu se to bude používat. Do té doby to jenom hypotetická konkurence Intelu nebo AMD.

    Přiznejme si ale, že by to bylo fajn kdyby byla opravdová konkurence x86.

    • 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.

      • 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…

        • A AMD přežilo jenom proto aby Intel nebyl jako monopol rozdělen. Intel si ho proto udržoval na hranici bytí aby mu nedej bože tato „konkurence“ nechcípnula. Kdo by si tehdy pomyslel kam až to může dojít.

  3. Myslienka je nadherna, ale ARM je na serveroch vo velkom nepouzitelne. Aspon zatial. Dam par dôvodov, preco by som ho rad nasadil, ale aj to, preco nemôzem a zial, negativa zatial vyhravaju.
    1. Vela jadier je super vec, napr pre databazy ako Firebird, MSSQL a podobne, kde kazdy pouzivatel ma svoj vlastny proces a teda viem pripojit velmi vela pouzivatelov.
    2. Energeticka efektivita je skvela a pouzit napr 400W zdroj, namiesto 600W zdroj v 6-8 serveroch je citit na uctoch, ale aj na chladeni. (taketo zdroje preto, pretoze ide aj o spotrebu RAM, radica diskov, samotnych diskov a podobne, na samotne CPU a urcite staci menej)
    3. Vela jadier sa vyuziva najmä ked virtualizujem – no a tu je problem. ARM zatial nevie (aspon podla mojej skusenosti) virtualizovat, konkretne vmware, hyper-v. Ostatne nepouzivam/neriesim. No a pokial nebude priama virtualizacia, aj vela jadier je nepouzitelnch. Malokto spusta OS priamo na zeleze, pretoze je to narocne skalovat, backupovat a pod. Ked to mam napr. pod esxi, zalohujem celu virtualku a ak mi odide zelezo, vymenim ho a fungujem dalej. – toto je hlavny dôvod, preco to nemôzem pouzit.
    4. Podpora instrukcii – toto je vyhoda aj nevyhoda ARM architektury. Vdaka tomu, ze si nenesie zeleznu gulu historie, nemusi mat extremne vela instrukcii a preto je efektivna. Ale väcsina aplikacii nebola napisanych vcera, ani pred rokom, ale funguju kludne aj desatrocie a nikto ich nebude prekopavat na ARM, pokial na to nebude extremne silny tlak. Rovnako ako napr. uctovnictvo na Linuxe alebo na MacOS nespustite (vynimka su webove).
    5. Nepodpora velkych vyrobcov. HP(E), Dell, Lenovo… Pokial to nezacnu tlacit oni, ARM sa nepresadi. Preco? Lebo oni robia support, riesia zaruku, na druhy den Vam poslu nahradny diel a vymenia ho. Robia aktualizacie, upravuju OS priamo na svoj hardware a podobne. Nebudem drzat okrem redundancie aj treti zalozny server ako sklad nahradnych dielov.

    Kde by to mohlo byt pouzitelne su napr storage (lun, san, nas) a obdobne veci, kde ide o jednoucelove zariadenie. Pripadne aktivne sietove prvky.

    Co som popisal je moja skusenost a plati pre komercnu sferu. Specializovane aplikacie, vypocty a podobne neriesim. Ak mi ale vyvratite moje skusenosti a date linky, rad sa priucim.