Nový ARM procesor pro servery jde na trh: 32jádra Ampere eMAG budou v serverech Lenovo

29

Letos se na trh dostaly 32jádrové ARM procesory pro servery Cavium ThunderX2, zatím asi nejlépe hodnocený pokus dostat tuto architekturu do datacenter. Nyní dostávají nového konkurenta. Na trh přichází rovněž 32jádrové procesory eMAG vyráběné novou firmou Ampere. Na té je pikantní, že má za CEO osobu, která jednu dobu byla prezidentkou Intelu, jehož Xeonům a obecně architektuře x86 tyto čipy logicky mají konkurovat.

 

DNA čipů X-Gene

Úplně nové eMAGy ovšem nejsou, pokud jste sledovali genezi firmy Ampere. Ta totiž vznikla z procesorové divize firmy AppliedMicro a eMAG je tak vlastně to, čím měly být třetí generace procesorů X-Gene od této společnosti. Prodej novým vlastníkům uvedení zdržel, ale výsledek projektu X-Gene 3 nyní konečně přichází na trh, právě pod označením Ampere eMAG.

Ampere eMAG je svým určením spíše než čipům ThunderX2 podobný Centriqům od Qualcommu – jde o procesor s relativně nižším TDP (125 W), určený jen pro jednoprocesorové servery a mířící spíše na efektivitu než na absolutní výkon. Čip vyráběný na 16nm FinFETovém procesu TSMC obsahuje 32 jader s 64bitovou architekturou ARMv8-A. Jádra běží na frekvenci až 3,3 GHz, což je turbo boost. Základní takt sdělen nebyl, podle některých údajů by ale mohl být na 3,0 GHz. Procesor má 32 MB L3 cache. L2 cache jsou v kapacitě 256 KB, ale to je sdíleno vždy pro dvě jádra. Jde tím pádem o poměrně malou kapacitu; relativně malé jsou také L1 cache (32 KB pro data + 32 KB pro instrukce).

Schéma procesoru Ampere eMAG (16nm generace Skylark)
Schéma procesoru Ampere eMAG (16nm generace Skylark)

Paměťový řadič je poměrně široký s osmi kanály paměti DDR4 s ECC a s oficiální podporou frekvence 2666 MHz. Podporováno je až šest slotů/modulů DIMM, tedy stejně jako u jednoprocesorových serverů s procesorem ThunderX2 (nebo AMD Epyc). Procesor eMAG dále poskytuje konektivitu PCI Express 3.0 o celkem 42 linkách (je možné vyvést až dva sloty ×16, jeden ×8 a dva ×1). Pro úložiště nepoužívající PCI Express/NVMe pak má řadič pro čtyři 6Gb/s porty SATA. Doplňkově je pak přítomno také USB, ovšem zdá se jen ve formě řadiče USB 2.0 (dva porty).

Vzorek procesoru Ampere eMAG na Open Compute Project Summitu (Zdroj: ServeTheHome)
Vzorek procesoru Ampere eMAG na Open Compute Project Summitu (Zdroj: ServeTheHome)

Procesor kromě základního ECC u pamětí podporuje i další pokročilé funkce pro lepší spolehlivost, například scrubbing pamětí a L3 cache na pozadí. Podporuje také izolaci chyb a data poisoning. Podporuje také virtualizaci I/O a přerušení. Podporován je i Secure Boot. EMAG je jinak kompatibilní se standardem ARM Server Base System Architecture. To by mělo zajišťovat dobrou kompatibilitu s operačními systémy a softwarem bez potřeby speciálního patchování nebo použití speciálních forků jádra.

BGA pouzdro eMAGu z druhé strany, kuličky kontaktů pro napájení na desku (Zdroj: ServeTheHome)
BGA pouzdro eMAGu z druhé strany, kuličky kontaktů pro napájení na desku (Zdroj: ServeTheHome)

Dvaatřicetijádra a šestnáctijádra

Nabídka se ještě v budoucnu má rozšiřovat, ale zatím Ampere nabízí jen dva modely procesoru eMAG, ovšem neuvádí pro ně nějaká přesná označení. Nejvýkonnější verze má 32 jader s již zmíněným maximálním taktem 3,3 GHz, TDP 125 W a cenu 850 dolarů. Podle některých zdrojů se zdá, že by mohla nést označení eMAG 8180, což připomíná highendový model Intelu Xeon Platinum 8180 z rodiny Skylake-SP. Tomu ale asi tento ARM nebude přímo konkurovat. I podle výrobce má 32jádro eMAG údajně mít výkon asi jako Xeon Gold 6130 (stojící 1894 $) nebo jako Xeon D-2191 (2407 $), což jsou obojí šestnáctijádrová CPU generace Skylake-SP.

Kromě tohoto modelu má být k mání také nižší, pro nějž zatím žádné modelové jméno nepadlo. Tento čip má mít jen 16 jader, také na frekvenci až 3,3 GHz. Pravděpodobně je tvořen částečně deaktivovanými čipy, cena zde má být 550 dolarů. eMAG jinak má pouzdro BGA pájené přímo na desku (s kovovým krytem/rozvaděčem tepla), takže procesor nepůjde upgradovat. Model si tedy vyberete při koupi desky.

Vývojářský server s procesorem eMAG od firmy Lenovo
Vývojářský server s procesorem eMAG, jde o systém vyrobený firmou Lenovo

Servery s architekturou ARM nejsou zatím natolik populární, jak jejich propagátoři doufali. O tom, zda může mít X-Gene 3 (a nyní eMAG) ještě úspěch – který se u prvních dvou generací nedostavil – se tedy často pochybovalo (a nadále pochybuje). Ovšem při vydání eMAGu bylo prozrazeno, že servery s těmito procesory bude nabízet Lenovo, má jít o 1U a 2U rackové servery. Nějaké klienty tedy nyní Ampere už má. Kromě toho by firma měla nabízet i vlastní OEM servery. A určitou zatím nekonkrétní podporu má zřejmě i od Oracle. Tato společnost totiž zdá se má v Ampere 20% podíl.

Roadmapa procesorů Ampere eMAG (Zdroj: Wikichip)
Roadmapa procesorů Ampere eMAG (Zdroj: Wikichip)

Následovat bude 7nm Quicksilver

Současná 16nm generace procesorů eMAG nemá samozřejmě být jedinou. Po 16nm procesorech eMAG (jejich architektura má interní označení Skylark) má následovat další generace „Quicksilver“, snad označená eMAG 2. Ta již má používat 7nm výrobní proces a tyto čipy by měly být uvedené (či odhalené) asi již v roce 2019. Údajně by měly mít vyšší počet jader, podporu PCI Expressu 4.0 a DDR4 na frekvenci 3200 MHz a také konektivitu CCIX a podporu víceprocesorových systémů. Také architektura jader CPU má být vylepšena, údajně má mít vyšší IPC. V roadmapě má Ampere teď ještě dvě další generace, k nimž ale zatím nic řečeno nebylo.

Nový ARM procesor pro servery jde na trh: 32jádra Ampere eMAG budou v serverech Lenovo

Ohodnoťte tento článek!
5 (100%) 12 hlas/ů

29 KOMENTÁŘE

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

    • „Proč měnit ověřenou, funkční a cenově příjemnou platformu x86,“
      😀 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é.

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

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

            • Ale preco to za stovky eur kupovat, ked sa to da za desiatky eur na mesiac prenajat? Ak je potrebny vyssi vykon, tak sa prenajme a plati sa viac. Ak nizsi, tak sa prenajme nizsi vykon a plati sa menej.

            • dfx: ak potrebujes maly web maly email a maly eshop, tak mas 30000 hostingov, kde ceny su 80€ rocne = pri 5rocnej zivotnosti servra to mas 400€, pri 10rocnej 800€ = je nezmysel si kupovat vlastny server.

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

            • Ale o tom nehovorím. Podľa toho čo tu viacerí píšete to vyzerá že si pod tým predstavujete tie ARMv7 pokusy o serverové zlepence, čo samozrejme nemohlo fungovať keďže tie jadrá boli skutočne navrhnuté na mikropočítače/DSP… Toto (ARMv8) je ale trocha iné.

              Samozrejme zatiaľ to nieje riešenie pre každého a ani to netvrdím ale uplatnenie to má. Také veci chcú čas, Intelu to trvalo koľko, 20 rokov? Prvé seriózne pokusy s ARM prišli len minulý rok (tie 28/40nm ARMy predtým proti 14nm x86 nemali šancu).

              Výraznejší zlom príde keď ARM dokončí dedikované jadro a uncore pre servery, už pár rokov na tom pracujú a myslím že niektoré časti sú už verejné.

            • No zase tak kategoricky bych to neviděl, ale holt mají ty alternativy různé praktické překážky vyplývající ze softwarové podpory a ceny kvůli tomu, že to není masové řešení. Holt musí jít proti proudu což je těžší než plout po.

            • J.O.: no jo, ale TCO je přesně to, nač se tě zeptá finanční ředitel, když přijdeš s nějakou nestandardní divočinou.

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

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

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

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

            • Změna instrukční sady taky nebude mít nulový přínos, stejně jako přechod z HDD na SSD. Zvýší se výkon (razantně) a/nebo sníží spotřeba.

              U toho ARMu souhlasím, že ten přechod nemusí (ale může) být moc přínosný. Protože i kdyby ARM byl v některých úlohách o něco úspornější a výkonnější, příjde pak úloha kde x86 bude díky širšímu instrukčnímu setu excelovat (třeba analýza DNA).

            • Zatím žádná taková pozitivní změna není.
              ARM exceluje nízkou spotřebou v porovnání s výkonem v malých zařízeních, které používají specifické aplikace, ušité na míru – z mého pohledu jde o klasickou specializaci (jako např. SPARC u Oraclu). A to prostě univerzální CPU není a nikdy nebude a jakýkoli pokus o univerzalizaci rozbije plnou zpětnou kompatibilitu (jako ARMv8) a zároveň ztratí původní pozitivní vlastnosti.

            • To razantní zvýšení výkonu a/nebo snížení spotřeby jsem myslel ve spojení s komplet novou instrukční sadou, ne ARMem.

              ARM, jak píšete, určitě nenahradí x86, protože v některých úlohách bude x86 díky specializovaným instrukcím vždy rychlejší.

      • ARM má instrukcí taky mnohem víc, jde to IIRC do stovek. On je taky dost starej a taky se tam toho dost nabalilo. ARMv8 je nová instrukční sada, ne kompatibilní rozšíření, ale taky jich je určitě mnohem víc než 40.

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

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

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

  2. 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 :-).