Dovedete si představit, že do budoucna ARM zcela převálcuje x86?
Prakticky všechny mobily a tablety běží na ARMu, embedded a "smart" zařízení rovněž tak, PC je pomalu na ústupu a na serverech se již ARM vyskytuje a zřejmě i vyplatí.
Ve spoustě počítačů, zejména někde v kancelářích, ARM výkonově dostačuje a jediný co x86 drží je zpětná kompatibilita software.
Na serverech se ale často vyplatí zpětnou kompatibilitu neřešit a v novém datacentrum prostě použít odlišnou technologii, která se zaplatí úspořenými provozními náklady.
Nepřeválcuje, ARM má z důvodů architektury RISC a nevhodně navržené instrukční sady vážné výkonnostní problémy a zaostává. V tabletech má Intel Atom již dobrou polovinu, v telefonech to dopadne podobně a na PC/Notebook/Server se nerozšíří asi nikdy.
Samozřejmě se ARM používat bude nadále, v embedded oblasti.
V čem zaostává ARMv8, což je úplně nová instrukční sada? I pro ARMv7 Intel sám přiznává, že pro některé NEON instrukce nemá ekvivalent.
Se kterými neblahými důsledky? Jediný neblahý důsledek RISC jsou chybějící instrukce, které lze dodat do CISC, což mnou odkazovaný článek jasně popírá, když mnoho instrukcí z ARM NEON intelácká CISC architektura ani neumí.
Itanium je EPIC, ne RISC. Stejně neblahé historické zkušenosti máme s CISCovou Motorolou 68k.
Velikost zabrané RAM není zrovna zásadní problém moderních počítačů s gigabajty prázdné paměti, a dost pochybuju, že ten rozdíl je výraznější než při použití jiných optimalizačních přepínačů. Pokud tedy vůbec existuje; knihovny, které tu mám, jsou každá pro ARMv7 o více než 20 % menší než totožná pro i686.
Závislost kódu na konkrétním modelu je u CISC IMO mnohem větší, protože každá nová iterace procesorů si přidává další instrukce, aniž by vytvářela novou instrukční sadu.
CISC se prosadil na úkor RISC ze stejného důvodu, proč se prosadily Windows na úrok UNIXu (nebo UNIX na úkor Plan 9): šlo ho rychle vyvinout a byl good enough.
Nemáš tušení o čem je řeč.
Zásadním problémem moderních počítačů je pomalost RAM, která je 1 000x až 10 000x pomalejší než by bylo potřeba a proto z nouze zvítězilo CISC které má průměrně víc instrukcí na stejnou délku kódu.
Závislost u CISC je minimální, CISC procesory dneska obsahují integrovaný překladač CISC->RISC a přeloží si to do RISC podle svých potřeb.
Speciální nové instrukce jsou jiná kapitola.
CISC chtěl zabít sám Intel v roce 1989, bohužel už v té době se ukázalo že cesta RISC není dobrá.
A to, že knihovny pro ARMv7 jsou výrazně menší než totéž pro x86, laskavě pomineme? Menší knihovna jaksi vyžaduje méně RAM. Či to, že x86 jakožto CISC sice umí mít krátké instrukce, ale vyplýtvalo je na velmi důležité operace pro moderní počítače typu práce s BCD?
Jaká je ta závislost u RISC? RISC jde mimochodem také překládat, přesně to dělá mnou několikrát odkazovaný Houdini od Intelu.
Intel se pokoušel měnit architekturu už několikrát. Ukázalo se jen to, že změnit zajetou architekturu je problém.
V tom pripade by asi neskodilo, kdyby bylo mozne ten procesor prepnout do RISC modu a na jeho CISC vrstvu se vydlabat. To ale asi nejde, jinak bychom uz nejspis videli RISC verzi Linuxu pro PC. Kdyz neumozni, aby to prepnout slo, aby ten RISC jednou nekdo mohl pouzit s tim, ze se to snad casem rozsiri, bude tam ta vrstva na zpetnou kompatibilitu na veky. Ostatne je otazka, jestli by dnesni Intely jako RISC procesory byly dobre.
Von ten RISC uvnitř může taky mít s každou generací jiný kódování instrukcí a nikde není zaručeno, že dýlky instrukcí jsou dělitelný 8 bitama. Klidně může mít instrukci dlouhou třeba 43 bitů.
Třeba taková 8086 mělo mikroinstrukce dlouhý 21 bitů a celej kód měl 504 instrukcí. K tomu byla nějaká tabulka s napevno zadrátovanejma návěštíma pro skoky.
Jen drobný detail: té paměti máme jen pár MB a je dost plná. Pokud máte na mysli RAM, tak té skutečně máme hodně, ale také je řádově pomalejší. Koukněte se někdy na jejich frekvence a počet cyklů nutných k načtení dat. Je zjevné, že pokud se bavíme o rychlém provádění programu, tak je kapacita RAM celkem irrelevantní a má smysl bavit se jen o velikosti cache.
Na druhou stranu je fakt, že dokud se rozdíly ve velikosti zabraného místa pohybují v desítkách procent, tak je to vlastně úplně jedno. Mnohem větší rozdíl je v tom, kolik cache jednotlivé procesory mají, tam to lítá o násobky.
Velká závislost na konkrétním modelu? Jako v čem? V optimalizacích? To snad bylo i na x86 a to odjakživa. 486 - některý instrukce začaly bejt deprecated a místo nich se používaly jiný (někdy i dvě místo jedný). Pentium - dvě fronty, jedna neuměla všechny instrukce, kód se musel psát / kompilovat přesně na míru. A tak dál a tak dál. S každou další generací se muselo optimalizovat jinak. Intel na to pak s každou generací vydával mnohasetstránkový manuály.
Jinak i860 neměl problém v tom, že byl RISC, ale že se těžko předvídalo kdy se jaký data dostanou do cache. Alpha byla svýho času zdaleka nejrychlejší CPU, PowerPC žádnej problém nemělo, G5 byla rychlostí srovnatelná s P4.
Nemáš tušení o čem je řeč. Drtivá většina dnešních procesorů je uvnitř RISC, tento vnitřek je skoro s každou verzí jiný a je téměř nemožné v software ošetřit všechny modely. U CISC to možné je, CISC má integrovaný překladač a tento přeloží kód do RISC optimálně.
Obě PowerPC i Alpha jsou slepé vývojové větve.
Sorry, ale tušení nemáš ty. Zasek ses ideově někde v pojmech v pozdních devadesátejch.
To že existuje nějakej front end, kterej překládá instrukce na micro-ops je nezávislý od instrukční sady, nedejbože to, že kdysi ideově vycházela z RISC nebo CISC. M68k byla takovej čistej CISC s poměrně komplexní instrukční sadou. x86 je spíš osmibit roztaženej do šířky. Historicky tam pár CISC instukcí bylo (ENTER, LEAVE, XLAT), ale ty se stejně přestaly používat a veškerý rozšíření od 486 nahoru už moc ideově CISC nebylo, protože ten koncept už byl překonanej.
PowerPC i Alpha jsou mrtvý, ale jejich smrt nebyla kvůli technologii, ale kvůli obchodním důvodům. Takže argumentovat tím je poměrně dost mimo mísu.
A to že moderní x86 procesory mají nějakej front end, kterej přikládá x86/64 instrukce na micro-ops, pak je dál něco přehazuje, fúzuje, atd. neznamená, že kompilátor nemusí řešit optimalizace na úrovni instrukcí a že tahle optimalizace není generaci od generace jiná. Podívej se třeba sem, oficiální optimalizační guide od Intelu: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
Sorry, nějak se mi zmotal text :-( Oprava:
Sorry, ale tušení nemáš ty. Zasek ses ideově někde v pojmech v pozdních devadesátejch.
To že CPU kdysi vycházely z RISC nebo CISC neznamená, že tyhle pojmy dneska až tak moc znamenají. m68k byla takovej čistej CISC s poměrně komplexní instrukční sadou. x86 je spíš osmibit roztaženej do šířky. Historicky tam pár CISC instukcí bylo (ENTER, LEAVE, XLAT), ale ty se stejně přestaly používat a veškerý rozšíření od 486 nahoru už moc ideově CISC nebylo, protože ten koncept už byl překonanej.
PowerPC i Alpha jsou mrtvý, ale jejich smrt nebyla kvůli technologii, ale kvůli obchodním důvodům. Takže argumentovat tím je poměrně dost mimo mísu.
A to že moderní x86 procesory mají nějakej front end, kterej přikládá x86/64 instrukce na micro-ops, pak je dál něco přehazuje, fúzuje, atd. neznamená, že kompilátor nemusí řešit optimalizace na úrovni instrukcí a že tahle optimalizace není generaci od generace jiná. Podívej se třeba sem, oficiální optimalizační guide od Intelu: http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
Právě M68k byl CISC se všema jeho výhodama. x86 je spíš takovej osmibit roztaženej do šířky. A říkat, že má dobře navrženou instrukční sadu... Jednobajtový instrukce zabírají nepoužívaný nesmysly typu DAA, AAA, osmibitový přesuny, operace s akumulátorem... Všechno pozůstatky toho, že je to jenom vylepšená osmibitová 8080. Pravda x64 v tom udělala trošičku pořádek, ale pořád nedůsledně. Přidala 8 obecnejch registrů, ale na jejich použití se musí použít prefix.
Navíc do L1 cache se stejně ukládají přeložený RISC micro-ops a ne původní CISC instrukce.
A délka kódu se s různejma kódováníma typu THUMB, MIPS16 taky zkrátila.
V cem ze mame s 68k neblahe historicke zkusenosti? S tim, ze kvuli nesmyslnym bublinkovym pametem kdysi v IBM usoudili, ze do PC narvou 8088 a ne 68k, takze to Intel dostal na zlatem tacu a Motorola celkem logicky nestihala zlepsovat technologie? Nebo jsem na neco vylozene technologickeho zapomel?
Jasně np: http://www.cpushack.com/CPU/cpu3.html#IBMPC
Zvláště si pro mistra kolemjdoucího dovolím vypíchnout větu: "Strategists were also not eager to have a microcomputer competing with IBM's low end minicomputers."
ARM se dostane i do serverů apod. Není a nebude to konkurence x86, ale vyhraje v aplikacích, kde x86 není efektivní. S tolika jádry je ARM dobrý na masivní virtualizaci. Na jednom jediném procesoru může efektivně běžet 20 virtuálních. Sice výkon na jádro docela slabý, ale pro farmu web hostingů zcela postačující.
x86 bude stále vyhrávat tam, kde je dobrá - ve výkonu na jádro. Pro úlohy, které nelze snadno paralelizovat, to zatím nemá konkurenci.
Snažím se říci, že ARM nevytlačí x86 z oblastí, kde je x86 efektivní. Ale existuje řada oblastí, kde ta x86 skřípe a tam má ARM naopak šance dobré.
Kolik promile SW bude asi tak na ARM behat? Kdepak, az na par specifickych vyuziti to nema proti x86 sanci. A kdybys tusil neco na tema virtualizace, tak bys i vedel, ze CPU neni problem. Problem dneska je prakticky vyhradne nedostatek RAM.
Pokud totiz vemu nejaky to 1Ucko, naladuju do nej mozna 256GB a 2x8 (ted uz mozna 2x12) jader, nebude to CPU kde mi dojde vykon, ale bude to RAM, co mi zabrani nasadit na to dalsi virtual. Kdyz totiz budu pocitat jen 8GB/stroj, tak mas limit 32. A 8GB neni pro spoustu aplikaci vlastne nic.
O serverech si totéž myslel Intel s Itaniem a jak to dopadlo…
Nicméně ten přesun od x86 na ARM je dost možný, i když to nebude nějak rychlé. Už dnes jsou x86 procesory interně RISC s překladačem, vynecháním překladače (či přesunutím překladače do OS, kde to stačí udělat jednou) se dá docela dost ušetřit. K tomu překladači: Intel vyvinul překladač ARMv7 na x86-64 (nazvaný docela výstižně Houdini) a docela to funguje, což umožňuje nasadit Atomy na tablety s Androidem a spouštět tam i nativní aplikace.
Co se týče počtu zařízení, ARM převálcoval x86 již někdy kolem roku 2000 a letos bude vyrobeno asi čtyřikrát víc zařízení s ARMem než s x86. U tržeb ARM překoná x86 možná příští rok, marže mají oba víceméně podobné (vzhledem k tomu, jak moc jim kolísají). Takový mezník nejspíš bude, až Apple ohlásí přechod Maců na ARM. Což ale nikdo neví, kdy či jestli vůbec to bude.
Je to můj odhad podle různých zdrojů IC Insights, např. porovnání podílů x86 a ARM firem v roce 2013 (přibližně 70:30 v té době) a jejich růst za 2014 a 1Q15. A je to jen možná.
Problém je, že ta linie mezi ARM a x86 firmami se stále více stírá, resp. x86 firmy přestávají být čistě x86, a nevykazují, jak si které části přesně vedou. Intel již vyrábí ARM čipy (prostřednictvím koupené firmy Altera) a AMD vyrábí procesory, které mají x86 i ARM jádra v jednom procesoru (Kaveri a Beema; možnost používání ARM části je ale poměrně omezená).
Na druhou stranu může růst ARM zpomalit, AMD zařízlo projekt Skybridge, který měl přinést ARM a x86 procesory se společnou paticí (není jasné, zda měly být i pro společné desky) a jeho plány pro ARM procesory se posunuly do vzdálenější budoucnosti, a Intel pro příští rok plánuje levné 14nm procesory, což by mu mohlo pomoct proti rostoucí popularitě ARM. Možná…
"O serverech si totéž myslel Intel s Itaniem a jak to dopadlo…"
Ale Itanium asi nemělo desetkrát menší spotřebu než x86, ne?
"Takový mezník nejspíš bude, až Apple ohlásí přechod Maců na ARM. Což ale nikdo neví, kdy či jestli vůbec to bude."
Tak toho bych se rád dočkal, nakonec mají v ARMu dost peněz a zájmů už pár desetiletí. A že na totální změnu platformy měli ohryzkáři koule už několikrát...