Bylo.
x86/64 jádro je komplikovaný, velký a rozežraný. Fyzicky se na jeho místo dá narvat několik menších jader jiné architektury (protože odpadne řada věcí - paměť mikrokódu, nějaký stavový automaty pro vykonávání instrukcí,...) .
Jestli pro čtyři virtuály máš jedno jádro, nebo pro každý z nich extra jádro s 1/4 výkonu je z pohledu plochy čipu, spotřeby a výpočetního výkonu celkem jedno. Co není jedno je, že oddělený jádra můžou mít dedikovaný FSB a řadiče pamětí, takže se zvýší propustnost pamětí. A že si virtuály nevidí pod pracky.
A hodně blbý na architektuře x86 je, čím si prošla a s čím vším drží (částečnou) kompatibilitu.
- Od osmibitu (8088)
- Na 16b s obskurním segmentovým 20b adresováním,
- Pak na 32b s 16b sběrnicí,
- Následovaný 32b s memory managementem,
- s vestavěním FPU (původně extra brouk x87)
- Překlopený interně na RISC, doplněný o hafo řezů a opičáren jako branch prediktory.
- Překopaný z von Neumanna (sdílení paměti programu a dat) na maketu von Neumanna z harvardem uvnitř a přilepením I cache a D cache
- Následně přebouchaný na 64b AMD64
- a to celý okořeněním sdílením jednoho jádra mezi dva procesy
- a s několikrát překopanou a rozšířenou instrukční sadou (MMX, SSE, SSE2, ...)
- rozšířený na mutiprocesorový monstra
- navíc s několika úrovněma CACHE, všelijak pochybně sdílenýma
V tom už se ani jeho výrobce nevyzná.
* miliardy USD na vývoj CPU s jinou architekturou výkonnostně porovnatelných se současnou x86
* biliony USD na portování stávajících aplikací na novou architekturu, včetně řešení chyb, které vzniknou takovou portací.
Výsledek? Možná to bude bezpečnější a jednodušší. Teda pokud nová architektura nebude ve výsledku stejně zabugovaná jako x86.
Současné CPU rozpůlit, půlku nechat v současném stavu kvůli kompatibilitě 16 a 32 bitových aplikací (s vypnutými nebezpečnými features) a drůhou půlku navrhnout moderně bez zpětné kompatibility pro nevé aplikace. A vzajemnou velikost těch "půlek" postupně s dalšími modely měnit.
Nebo dvě patice na CPU vedle sebe (klidně pod jedním chladičem) a uživatel si rozhodne co a s jakým výkonem potřebuje.
Prdlajs.
1) Nepotřebuješ miliardy na jinou architekturu. Ty miliardy šly do litografie, ne do zapojení čipu. Je úplně jedno, jestli do 10nm technologie hodíš x86, nebo něco jinýho.
2) Frekvenci jádra budeš mít pro stejnou technologii stejnou. Pokud v dané technologii x86 dá 3GHz, hádej, kolik dá jiný jádro? Rozdíl výkonu je v mikroarchitektuře.
3) Správně napsané aplikaci je na 99% jedno, pro jakou architekturu ji zbuilduješ, pokud se optimalizace kompilátoru chovají podobně. Nejede totiž na železe, ale nad OS, popřípadě nad VM který zůstanou stejný. Takže třeba Java, JavaScript, C# a další prostě pojedou, pokud bude stejný runtime a stejný API. Mega částky půjdou maximálně do aplikací, kde se obchází systém - a to je většinou kvůli neznalosti vývojářů. Takový soft je už teď zprasený a neudržovatelný a může se rozbít při jakékoliv aktualizaci. Měli jsme embedded SW, který běžel na ARM9EJ-S. Ty samý zdrojáky v C jsme buildovali i pro x86 pro ůčely dema a testování, jediný požadavek byl oddělení HAL.
4) K přepisu bude část ovladačů. Ony totiž periferky většinou jedou už nad nějakou abstrakcí (PCIe stack, USB stack0, platí to, co pro aplikace. Nezměníš-li interface, řádek se změní na jinou řadu jedniček a nul, ale dělá to samý.
5) Takže co se změní nejvíc, je HAL vrstva kernelu a ovladače věcí přímo v procesoru. A s vzdáleností od jádra úsilí na portaci exponenciálně klesá.
Krásná teorie, ovšem praxe říká něco jiného. Když je to tak jednoduché, proč tedy Microsoft pracně vyvíjel nové Windows na telefony a první Surface, když mohl prostě jenom portovat svoje x86 Windows prakticky s celým ekosystémem na Lumie a kompletně smazat všechny ostatní hráče na trhu s telefony? Vždyť přece stačilo jenom vybrat jinou cílovou platformu a zmáčknout F7.
Tak napřed si ze "všech aplikací, co běží na Windows" odpočítej
- aplikace v Javě, ty jedou na fitkivním SW stroji a stejný bytecode spustíš na jakékoliv platformě, náklady 0
- multiplatformní aplikace, kde je interakce se systémem skrytá v knihovnách ( Qt, ... )
- aplikace, který jedou nad skriptovacím nebo interpretovaným jazykem (na vedlejším monitoru mám zrovna něco v Tcl/Tk, ale i Python se počítá).
No a pak uvidíš, že tahle "migrace" se už jednou povedla - z WinAPI na .NET. Pravda, ještě pár věcí jede nad WinAPI, ale už je to minorita.
A jeden přímo nesouvisející detail - problémy se side kanály jsou nejhorší na serverech (virtualizace pro několik zákazníků). Tam je těch aplikací podstatně míň, než BFU "nutně potřebuje". Systém, hypervizor, ssh daemon, SQL, PHP, web server, mail server a pár dalších. Pokud to nová architektura vezme přes servery a pak přeteče i do spotřebky...
První co mě napadne jsou drivery třetích stran které se budou muset překopat, na většinu driverů, které stále ve Windows fungují už ani není podpora ze strany výrobců, takže se spousta zařízení prostě vyhodí a když uvážíme kolik lidí křičelo když jim pod novým Windows 10 nefungoval skener nebo tiskárna, tak po kompletní migraci na jinou procesorovou platformu by to byla všeobecná hysterie na úrovni Francouzské revoluce.
Navíc jak krasně funguje portování mezi jednotlivými architekturami je možné vidět když se hra z PC portuje pro konzoli a naopak. Ty hry jsou na takovou akci většinou navržené a i přesto, pokud se hra pořádně neotestuje a neopraví se chyby vzniklé portací, výsledek je velice špatný.
On už tady jeden pokus byl, Intel IA64 pro servery a byly i k tomu příslušné OS a ze strany MS i další serverové aplikace. Bylo to drahé a celé nové. A pak přišlo AMD s "namontováním" 64bit architektury na 32bit procesor a instrukční sadu a trh rozhodl, že se půjde touto cestou, protože ta zpětná kompatibilita měla obrovskou hodnotu. (A CPU byly levnější.) Takže po této zkušenosti a slepé uličce se jen tak někomu do pokusu o migraci hlavní platformy chtít nebude.
2Durill: Mno ono to hlavne taky bylo celkove vykonejsi a min zravy a ... pro IA neexistovaly naprosto zadny aplikace, a ti kteri je potencielne chteli napsat, zjistili, ze k tomu neexistuej ani zadna poradna dokumentace a ze na tom vlastne vubec nic nefunguje.
AMDcko udelalo proste to, ze stavajici instrukcni sadu jen rozsirilo na 64bit. Zadny zmeny funkcionality.
To nepochybňuju. Jde o to, že pokud řekněme za 1E9$ vyvinu komplet procesor i s technologií (litografie, leptání, zmenšování masek, ...) a se stavbou nové fabriky, můžu vyvinutý zařízení opakovaně použít a pro další čip už dám třeba 1E7$. A jak získám zkušenosti s vývojem v dané technologii, bude potřeba míň prototypových koleček, odladím výtěžnost a dostanu se ještě níž,...
Nikdo to nezaplatí. Peníze, které by to stálo, resp. ktré by stály nové čipy oproti stávajícím, a to ještě s tím, že nebude zpětná kompatibilita a pravděpodobně by byl min. za začátku i výrazně nižší výkon (viz. ARM stahy v HPC).
Prostě se to bude lepit dále. ADost možná další desítky let, protože ta investice je nenávratná. Kde o to opravdy jde, jsou už dávno zavedená opatření - systémy jsou např. fyzicky izolované od internetu....