Nejspíš na úkor ARMu, protože výsadní postavení x86 je zpětná kompatibilita a vysoký výkon za cenu mnoha chyb a velké spotřeby.
Oproti tomu procesory na architektuře ARM jsou zpravidla s malou spotřebou a cenou na úkor výkonu a (takřka) neexistence zpětné kompatibility (spíše co se týče periferií, nikoli instrukční sady).
Výjimky z pravidla, jako byl třeba Transmeta Crusoe, ponechme stranou.
Jenomže ARM limituje spodní hranici ceny tím, že výrobci musí platit za licenci jádra. Proto se někteří výrobci snažili najít jinou cestu, kde by si nahrabali víc a přitom nabídli lepší cenu než konkurence. Odpověď zní RISC-V, protože je zdarma a protože zčásti už někdo udělal práci za ně.
Stačí se podívat na záplavu procesorů z Číny. Klony 8051 s různými vylepšeními. Třeba N76E003AT20 za pětikorunu. Nebo CH551-CH559 za šest korun (ty levnější modely). Pak tu jsou vyloženě čínské podivnosti, jako třeba Padauk PMS150 za 70 halířů.
Sice by se mohlo zdát, že když se dá "slušný procesor" STM32F030F4P6 od ST koupit okolo 8 korun, tak už je jedno, jestli ten procesor stojí 5 nebo 7 korun, ale v okamžiku, kdy jde o procesor do nějakého křápu, kterého se prodá sto tisíc kusů, pak to lidii zahodí a v další vlně si podobného křápu koupí další tisíce, tak už je to dost peněz, o které by výrobce použitím dražší komponenty přišel.
Navíc už se notnou chvíli nedá říct, že RISC-V by byly jen pomalejší napodobeniny ARMů. Stačí se kouknout třeba na Kendryte K210, který je výkonem prakticky na úrovni slabších "aplikačních" ARMů. A navíc - viděl někdo někdy ARM s koprocesorem pro konvoluční sítě?
To s tím výkonem už tak úplně neplatí, nejnovější 64-bitové ARMy mají výkonu na rozdávání (při poměrně nižší spotřebě), třeba ten Qualcomm v Surfacu je zhruba na úrovni i5 a Apple má ještě lepší výkon (absolutní i poměrný), ovšem Apple má svá vlastní vylepšení. A nové Gravitony Amazonu se už také dotahují na serverech na Intel.
Ne, Skylake ne. Mám Intel na 10 nm a topí víc než srovnatelné (starší) modely na 14 nm. Prostě fail. Výkon hluboko pod A11 (taky 10 nm, pokud to teda pro někoho má význam). Ale jo, až se Intel někdy mezi 2025–2030 dostane na 7 nm, bude zajímavé porovnat ho s ARMem znova. Ten ovšem taky nebude spát na vavřínech. A je otázka, jestli v laptopech ještě bude převládat AMD64, klidně se může stát, že Apple nasadí ARM i do svých vyšších modelů a Windows na ARM taky bude růst (Surface Pro X má výkonu na rozdávání).
Ice Lake má výkon pod A11 Bionic? V Geekbench? SPEC2006? Počítám, že jste četl recenzi Galaxy Booku na Notebookcheck. Škoda je, že zatím nezměřili výdrž baterie při normální činnosti. Sledování videa je specifický scénář, kde hraje důležitou roli úsporný režim a video akcelerace. Pokud bude výdrž podstatně větší než porovnatelné x86 za normální činnosti tak OK. Co se výkonu týče, zatím nikdo to neotestoval třeba v 32bit Blenderu, byť emulovaném. Tam by se ukázala pravá síla toho CPU a emulace. Někdy v budoucnu i na ARM verzi pro GNU/Linux. Až pak budu přesvědčen
25. 2. 2020, 11:35 editováno autorem komentáře
Je to Cannon Lake. Kdysi jsem porovnával výsledky GeekBenche, ale nešlo mi teď ani tak o výkon, jako o jeho funkci topného tělesa, ta technologie je otřesná, když 10 nm topí více než 14 nm. Ice Lake se podle recenzí chová stejně, rozdíl je v pár AVX-512 instrukcích navíc.
Popravdě nějaká čísla z benchmarků asi nejsou pro běžného uživatele moc důležitá (v reálných testech se navíc projevuje výrazně i rychlost paměti), tomu stačí “pocit svižnosti,” a tam se projevuje i GPU a případně hardwarová podpora pro ML, jako mají CPU Applu nebo i ten SQ1 v Surfacu. A taky disk. Proto předpokládám, že ARM se v laptopech a možná i na desktopu postupně prosadí, všechny běžné překladače generují slušný kód pro ARM64, dokonce i MSVC. Ale křišťálovou kouli nemám, musíme si počkat, hlavně vývoj CPU pro servery mě zajímá, tam ARM zatím moc neválí.
BTW tu recenzi jsem nečetl a o Galaxy toho moc nevím. Šlo o S? To má téměř stejný procesor jako Surface Pro X, nepletu-li se. Tady můžu porovnat Surface s ARMem a (novým 10 nm) Intelem, oba svižné až až, ale Intel vydrží na baterku o polovinu méně při stejně práci a topí (podle recenzí brutálně snižuje frekvenci, aby to ustál). Až na tento kiks to je také slušný stroj.
Nějak z toho RISC-V pořád odvázaný nejsem. Samotná instrukční sada je sice svobodná, ale to přece nijak nezaručuje, že konkrétní čipy nebudou mít proprietární mikrokód případně i se zadními vrátky, jako je to u Intelu a AMD? Kromě toho, když je ISA úplně volná, nebude to mít paradoxně ten efekt, že se každý výrobce bude snažit implementovat svá vlastní nekompatibilní "rozšíření", aby uvěznil zákazníky, jako to bylo za dob války mezi unixy?
Zatím je praxe pozitivní. Pár větších firem, co RV dotáhlo už do křemíku (SiFive, Western Digital, GigaDevice, určitě i další) se předhání v tom, kdo dá komunitě víc (a naprosto správně počítají s tím, že se jim taková investice vyplatí).
Př. https://www.westerndigital.com/company/innovations/risc-v
To je právě otázka. Model "kooperativního soutěžení" funguje výborně, ale jen ve specifických případech, jako je např. jádro Linux. Intel, AMD, ARM a další do něj významným způsobem přispívají, protože žádný z nich nemá za cíl být dodavatelem OS, ale zároveň evidentně nemá šanci prodat nový mikroprocesor, pokud tento nebude mít prvotřídní podporu na straně OS a to konkrétně Windows a Linuxu. Snažit se "ohnout" Linux tak, aby byl nekompatibilní, není v zájmu žádného z těchto výrobců (a kromě toho to GPL neumožňuje).
Ale u instrukční sady je situace jiná, kdyby dejme tomu někdo začal používat RISC-V pro androidní zařízení, těžko bude odolávat (naivní, ale silné) představě, že nejlepší bude, když si ISA rozšíří po svém, začne tlačit na vývojáře aplikací, aby své appky "optimalizovali" tak, aby využívaly "výhody" jejich proprietárního čipu, a bude doufat, že si tím zajistí budoucí odbyt.
Mám přiznávám trochu tunelové vidění, dělám silně embedded vývoj, ale na svém písečku vidím přesně opačný trend — já i kolegové z různých Boschů, Siemensů a podobných oblud dnes velmi těžko obhájíme proprietárním řešení. Tlak proti vendor lock-inu je obrovský a vidí to i velcí výrobci součástek. Ti se sdružují do asociací a aliancí, kterými zastřešují danou technologii a tvrdě vystupují proti proprietárním modifikacím do takové míry, že tyto prakticky už neexistují. Dnes můžu nakoupit komponenty od různých výrobců a nemusím se bát, že spolu nebudou mluvit. Od relativně primitivních technologií jako komunikační sběrnice až po složitější periferie nebo MCU, všude je to znát. Posledních pár let je samozřejmost mít driver v mainline linuxu a definici v buildrootu.
Na jednom workshopu (Pizza Workshops :-] pořádá SOS Electronics) jsem se zakecal s lidma z NXP a TI kteří, ač soupeři, spolupracují na toolingu pro svá řešení. Podle nich komplexita softwaru raketově roste a spolupráce už je jediná ekonomická možnost. Před deseti lety ještě nebyl problém vyrábět hardware a k tomu prodávat kompilátor, debugger. Dneska jim bez first-class podpory v gcc/llvm nikdo nepodepíše smlouvu.
S tím se musí počítat.
Ale jsem přesvědčen, že kdyby se nějaká velká firma (čti AMD nebo alespoň VIA) pustila do vývoje takového čipu, pak by byla poměrně velká naděje, že by vznikl.
Problém je spíše podpora OS (asi by se tak neprodával jako x86 procesory).
Musel by mu pomoci buď Google nebo Amazon, které by je dávaly do svých farem...
CISC... x86/amd64 je v křemíku RISC. Na tom běží mikrokód, a ten teprve tu širší CISC emuluje. Rozdíl je tedy jen v dělbě práce - co na ARMu musí dělat kompilátor, to na Intelu proběhne až v mikrokódu.
Nemyslím, že tady je velký prostor k nějakému zrychlení, maximálně se zpřístupní víc optimalizací, které JIT v mikrokódu nemůže dělat, protože nemá tolik informací, co kompilátor.
Vykonavani v jednom taktu je "imaginarni" predstava o RISC (vs CISC). Typicky pseudoformat velice primitivni instrukce je:
DST := SRC1 OP SRC2
Takze se musi ziskat 2 zdrojove operandy (at uz z registru, z pameti, z instrukce samotne), provest operace, a pak zapsat vysledek (do registru, ci pameti).
Tohle je rozlozeno v case - do minimalne 5-ti taktu v pipeline - viz https://en.wikipedia.org/wiki/Classic_RISC_pipeline
O pipeline vím, ale domnívám se, že některé CISC instrukce se musí dekódovat na více po sobě jdoucích RISC instrukcí.
Což, předpokládám, potřebuje více inteligence procesoru (minimálně nějaký speciální "překladový" procesor, do kterého se sype mikrokód, scheduler, optimalizátor...) a tedy zase více křemíku...
Mohl by být určitě menší (méně mm² na jádro), díky čemuž by šlo snadněji vyrábět CPU s velkým počtem jader. Ostatně přesně takto se používají jádra ARM Cortex — např. komplex čtyř populárních A53 syntetizovaný 16nm technologií zabírá 8.4 mm², zatímco jeden core complex AMD Zen2 (také 4 jádra) zabere 31.3 mm², přestože je syntetizován mnohem jemnější 7nm technologií.