Intel investeert 1 miljard dollar in RISC-V

Intel investeert een miljard dollar om samen met andere bedrijven en start-ups de adoptie van RISC-V te versnellen. Het chipconcern werkt daarbij samen met onder andere Andes Technology, Esperanto Technologies en SiFive.

De investering van omgerekend 880 miljoen euro komt van Intel Capital en Intel Foundry Services en moet ervoor zorgen dat Intel marktaandeel wint bij de productie van chips op basis van de belangrijkste instruction set architectures: x86, Arm en RISC-V. Dat streven is onderdeel van Intels IDM 2.0-strategie, die het bedrijf een jaar geleden presenteerde. Het doel daarvan is om chips voor derde partijen te produceren en zo de concurrentie met Samsung en TSMC aan te gaan. Intel investeert miljarden dollars in de uitbreiding van zijn chipproductie om dat mogelijk te maken.

RISC-V is een opensource-ISA die in populariteit stijgt. Intel hoopt het ecosysteem verder te laten groeien en mee te liften op de populariteit door in een vroeg stadium te investeren in start-ups en groeiende bedrijven die hier mee bezig zijn. Intel wijst onder andere op het gebruik van RISC-V-chiplets op packages, die dan gecombineerd kunnen worden met Xeon-cores en waarbij de verbinding via interconnects verloopt die door Intel ontwikkeld zijn.

Intel meldt graag samen te willen werken met bedrijven om tot een open standaard voor dit soort die-to-die-interconnects op een package te komen. Een van de bedrijven waar Intel mee samenwerkt voor zijn RISC-V-initiatief is SiFive. Vorig jaar waren er geruchten dat Intel dit bedrijf wilde overnemen. Meer informatie over RISC-V is te lezen in De opmars van RISC-VPlus - Op weg naar opensource-processors.

Reacties (46)

Hoe staat RISC(-V) tegenover ARM? Ik vind dit wel interessant, heb al tijden niets meer over RISC gehoord.

RISC en ARM zijn gelijk(w)aardig. Het grote verschil is dat RISC-V open source is en ARM gesloten.
Lang antwoord: https://bootcamp.uxdesign.cc/arm-vs-risc-v-3bf32a78ac3a

Gaat een open source instructieset niet heel snel tot versnippering van het platform leiden? Dat zie je tenminste bij open source software aan de lopende band gebeuren.

Ik heb begrepen dat de instructieset vastligt (evenals de extensies/uitbreidingen).
Je implementatie, dus hoe jij het in hardware maakt, mag je zelf bedenken. Of jij die chip dan multicore maakt, van een forse cache voorziet, wat voor soort transistors je gebruikt, welk fabricageproces je gebruikt - allemaal up to you.

Niet helemaal: je kunt een subset of ook extra custom instructies implementeren. Dit is het risico op versnippering en problemen met compatibiliteit.

Als dat geblokkeerd zou worden is dat weer risico op stagnatie van innovatie. Als je die chips in een kant en klaar product gebruikt is het niet relevant of de software compatible is met de CPU's van de concurrent...

Zou dit een voordeel kunnen zijn van de gekochte invloed van Intel? Zodat er gegarandeerd nog iemand toeziet op de compatibiliteit etc.? (maar die kan weer rare streken uithalen vanwege de invloed).

Of juist een nadeel: Embrace extend en extinguish is door Microsoft al een tijdje niet meer relevant, maar ik zie het een rijke kat in het nauw zo maar doen.

Ik heb je een +1 gegeven, maar ik ben stemmonddood gemaakt op de FP.

Versnippering komt voornamelijk omdat er niet centraal geïnnoveerd wordt. Er zijn simpelweg te veel partijen in software land. In hardware land verwacht ik dat het wat minder een probleem is. Maar er bestaat altijd kans op wat versnippering. Echter ik denk niet dat je dat moet willen voorkomen.

RISC-V draait al in de echte wereld maar niet op het toneel waar ARM en x64 momenteel de dienst uitmaken. Je hebt wel dev kits voor chips met PCIe en DDR-geheugen maar je zult nog even moeten wachten op de eerste open concurrent voor de i3. Je ziet wel meer RISC opkomen in de embedded space, tot op het punt dat je ESP32-achtige modules steeds vaker met een RISC-V-chip ziet verschijnen.

RISC als concept doet het uitstekend met de performance die Apple en Qualcom uit ARM weten te halen (ARM is tenslotte een RISC-architectuur) en Intel heeft met moeite de M1 bijgehouden met hun huidige processoren op het vlak van desktopprocessoren. Ik denk dat op dit punt de populaire RISC- en CISC-architecturen een beetje beginnen samen te smelten als je kijkt naar hoe microcode tegenwoordig wordt toegepast.

ARM is ook een RISC architecture (Reduced Instruction Set Computer).

RISC-V maakt gestaagd voortgang en lijkt de opvolger van ARM te gaan worden, SiFive is een van de bedrijven welke het verst is met RISC-V. Er komen steeds meer processoren met RISC-V op de markt en de adoptie groeit snel, over meerdere jaren kan je het denk ik zeker regulier voorbij gaan komen.
Als ik een ongegronde gok moest wagen zou ik zeggen dat we ergens 2028-2030 RISC-V producten op de markt voor consumenten gaan zien komen.

En velen zijn er in aan het investeren, zo nu ook intel dus weer. Zal alleen maar sneller gaan.

[Reactie gewijzigd door Randomguy369 op 8 februari 2022 17:44]

Sterker nog, de naam ARM is een afkorting waar RISC in staat...

De ARM-processor (de afkorting staat tegenwoordig voor Advanced RISC Machine) werd nadien doorontwikkeld door ARM Ltd, een verzelfstandigde dochteronderneming van Acorn, en is tegenwoordig de meest gebruikte processor voor smartphones en tablets.

ARM is een RISC instructieset. RISC-V is een andere RISC instructieset. Wat RISC-V interessant maakt is dat er geen licentie nodig is om deze te mogen gebruiken.

Intel heeft de boot gemist met ARM en heeft natuurlijk nog genoeg inkomsten met x86 maar er is een degelijke kans dat RISC-V in minder ingewikkelde toepassingen de toekomst zal hebben. Eventueel zal het later ook in high end chips terugkomen.

Intel maakte vroeger ARM processoren (middels StrongARM) maar heeft later het zaakje verkocht.

Mooi dat Intel RISC-V omarmt maar ergens ook vreemd want ik had begrepen qua performance het allemaal niet zo veel uitmaakt welke instructieset je gebruikt. Zie link Jim Keller; wellicht dat iemand betere informatie heeft.

Elke volwaardige CPU doet intern een vertaalslag naar de echte instructieset die direct wordt gedraaid. De vertraging zit sowieso meestal niet zozeer in het uitvoeren van de instructies zelf, maar in het het foutief voorspellen.

De meeste code staat vol met beslismomenten: als de vorige berekening antwoord A heeft, doe dan X en doe anders Y. Vroeger wachtte de processor dan tot de berekening van antwoord A klaar was, waarna deze pas verder kon. Maar bij het sneller worden van de CPU's, betekende dit dat de processor steeds langer zat te wachten op een eerdere berekening. Een processor doet namelijk heel veel parallel. Ook binnen een enkele core kunnen meerdere berekeningen (en IO-acties) tegelijkertijd gebeuren.

Nu blijkt dat heel vaak dezelfde keuzes worden gemaakt, met name in loopjes waar precies dezelfde code heel vaak wordt uitgevoerd en bij code die parallel meerdere keren draait. Dit is nu net de code die vaak heel veel CPU-tijd kost. Dus als je in de CPU bijhoudt welke keuze je vorige keer maakte, dan kun je heel vaak goed voorspellen wat de uitkomst gaat worden. En zelfs als je de code voor de eerste keer ziet, kun je op basis van heuristiek een stuk beter voorspellen dan 50/50.

Dus ipv een groot deel van de processor te laten wachten op de eerste berekening, kun je alvast de gok wagen dat het antwoord A is en de berekening van X doen. Als je goed gokt, dan heb je een grote winst. Als je verkeerd gokt, dan is er niets verloren ten opzichte van wachten op de eerdere berekening. Je gooit dan het resultaat van berekening X weg en gaat berekening Y doen.

Dit is zo belangrijk voor de performance dat het relatief gezien niet zo veel uitmaakt als de verwerking van instructies ietsje beter of slechter is, omdat de instructieset wat beter of slechter is. Bij het ontwikkelen van RISC dacht men dat dit niet zo was en dat x86 ten dode opgeschreven was, maar dat bleek helemaal niet waar. Het kost wel wat meer moeite om x86 snel te maken, maar het geld is er om dat te doen, omdat er zoveel van worden verkocht.

Het verhaal van Jim Keller is eigenlijk hetzelfde als bij programmeertalen. Elke nieuwe programmeertaal is strak en consistent, maar gaandeweg komen er steeds nieuwe eisen en nieuwe trends, die toegevoegd worden. Je kunt echter niet de oude API weggooien om een nieuwe strakke API te maken, want dan stapt niemand over naar de nieuwe versie. Dus gaandeweg wordt het steeds lelijker en blijft er allerlei spul achter dat vrijwel niemand gebruikt (zoals CORBA support in Java).

Als echt vrijwel niemand het gebruikt kun je het weghalen, maar als voldoende mensen het gebruiken, dan kan dit eigenlijk niet.

Overigens kan juist een taal als Java een oplossing zijn om makkelijk van instructieset te wisselen, want Java draait op een interpreter die de code pas compileert wanneer je het draait (met allemaal slimme trucjes om het sneller te maken). Dus als je 30 jaar geleden Java-code geschreven hebt, dan kan die nu draaien op een instructieset die toen nog niet bestond en profiteren van allerlei verbeteringen in de processor en in de interpreter, terwijl 30-jaar oude gecompileerde C-code dat niet kan.

Je kunt gecompileerde code trouwens ook via een interpreter draaien. Apple heeft dat drie keer gedaan om te zorgen dat mensen hun oude applicaties konden blijven draaien (maar dan niet optimaal), bij de overstap van Motorola 68k chips naar PowerPC, de overstap naar x86 en vervolgens bij de overstap naar ARM. Zo zou je instructies ook kunnen verwijderen uit CPUs en code dan via een interpreter draaien, die de verwijderde instructies omzet naar code die gebruik maakt van andere instructies. Zo zou de x86 instructieset kunnen worden versimpeld.

Al zal strak geoptimaliseerde code die zonder tussenlaag draait op een CPU een interpreter altijd verslaan. Al is veel code niet strak geoptimaliseerd (maar juist dingen die echt snel moeten zijn vaak wel, zoals game engines).

Zo zou je instructies ook kunnen verwijderen uit CPUs en code dan via een interpreter draaien, die de verwijderde instructies omzet naar code die gebruik maakt van andere instructies. Zo zou de x86 instructieset kunnen worden versimpeld.

Dat heet microcode. x86 processoren maken er al intensief gebruik van zodat de core van de CPU simpeler kan worden. Het is geen manier om de instructieset te versimpelen maar juist zodat ze die compatible kunnen houden met oude code zonder dat de architectuur van de CPU te complex wordt.

Microcode zit in de CPU zelf. Dus hoe groter de instructieset wordt, hoe meer ruimte je in de processor moet reserveren voor de microcode om die instructies te verwerken. Dat gaat ten koste van de ruimte voor cache of verwerkingseenheden. Mijn idee is dat je bepaalde instructies buiten de CPU vertaalt. Dan hoeft de CPU zelf niet meer compatibel te zijn, maar is de combinatie van de CPU en de interpreter buiten de CPU nodig om die instructies te kunnen verwerken, zodat oude code toch blijft draaien.

Uiteraard heeft dat alleen zin als die instructies relatief zelden worden aangeroepen, anders wordt het te traag.

Een interpreter buiten de CPU noem je gewoon emulatie. Dat bestaat al decennia en heeft serieuze issues met performance.

Als ik me goed herinner (CPU's zijn mijn vak niet) zit het zo: Een groot probleem met emulatie is het decoderen van instructies. Dat is bij x86 processoren een complex proces omdat x86 met instructies van variabele lengte en complexiteit werkt en dat heeft nogal impact op performance en de mogelijkheden om de verwerking te optimaliseren.

Dat is juist waarom RISC zoveel beter dan CISC was: De sterk vereenvoudigde decoding van instructies doordat elke instructie 32-bit lang was en de versimpelde pipeline omdat elke instructie in 1 clock cycle uitgevoerd kon worden (bij x86 is dat ook variabel). En decoding moet in hardware in de CPU om de performance acceptabel te houden.

Microcode is dan een compromis. Je haalt complexiteit uit de CPU core om die te optimaliseren maar laat het decoding proces intact om compatible te blijven zonder veel performance te verliezen. Microcode kun je zien als een soort macro's die simpele (RISC) onderliggende instructies uitvoeren. Het is een compromis maar wel veel beter dan emulatie in software.

Het is niet zozeer iets wat ze omarmen. Ze willen de klant ervaring veranderen Het doel lijkt te zijn geworden dat ze een soort van Samsung / TSMC worden.

Misschien is Samsung wel de beste vergelijking... Ja ze maken hun eigen soc's maar ze maken ook soc's voor derde partijen.

Intel maakte vroeger ARM processoren (middels StrongARM) maar heeft later het zaakje verkocht.

En ze probeerden ook smartphones te voorzien van x86, zoals in de Motorora Razr i, maar ook dat ging niet van een leien dakje. Hoewel het fantastisch draaide. Ik heb de Razr i nog in de kast liggen en ook vandaag de dag is 'ie nog altijd retesnel. Bijna alle apps openen nog even snel als op een moderne smartphone.

[Reactie gewijzigd door TheVivaldi op 8 februari 2022 19:27]

ARM = RISC architectuur

X86 = CISC architectuur

Alle smartphones gebruiken ARM (RISC)

RISC-V = "open source"

ARM gaat V9 versie introduceren van hun processors, M2 chip van Apple wordt waarschijnlijk de eerste chip met V9.

V8 is de afgelopen 10 jaar (?) in gebruik geweest.

[Reactie gewijzigd door obimk1 op 8 februari 2022 18:18]

ARM = RISC architectuur

X86 = CISC architectuur

Zoals vandaag hier in de comments onder een ander artikel reeds werd opgemerkt is dit een achterhaalde stelling. Ook moderne x86-64 processoren zijn gebouwd op een RISC architectuur waarbij de vertaling van de oude CISC instructies in microcode gebeurd.

RISC gaat ook over instructie sets, en ARM verkoopt zowel HW licenties en ISA licenties.

Hardware matig heeft X86 wat geleend van ARM, maar de instructie-set van X86 blijft CISC; "Complex".

Apple heeft met software (Rosetta2) een vertaal laag gemaakt tussen X86 instructies en ARM instructies.

X86 zal nooit RISC zijn.

Alle smartphones gebruiken ARM (RISC)

En de Motorola Razr i dan?

Volgens dit artikel is RISC-V in tegenstelling tot ARM erg geschikt als basis voor coprocessors (zoals voor AI). Hier wordt zelfs de mogelijkheid benoemd om een RISC-V coprocessor aan een ARM processor te hangen.

Een ander voordeel van RISC-V wat hier benoemd wordt is dat het door de minimale minimum instructieset erg makkelijk is om met heel weinig silicium toch een snelle processor te maken. Dit heeft Nvidia gebruikt toen ze een controller nodig hadden voor hun GPU's.

Iemand een idee welke bedrijven in Nederland hier veel mee bezig zijn?

NXP, die maakt vooral de machines die het mogelijk maken om deze produce's te fabriceren. Ze zijn volgens mij ook marktleider op dit gebied.

"If you can't beat 'm, buy 'm!"

Maar serieus, Intel heeft geen voordeel in het legitimeren van een potentiële concurrent voor zijn x86 architectuur. Een high-end RISC-V processor zou makkelijk een bedreiging kunnen gaan vormen voor de high-end Xeons en Core processoren en de winstmarges van het bedrijf kunnen ondermijnen.

Intel kan wel een fab worden, net als TSMC dat nu ook is, maar dat zal voor veel concurrenten een probleem zijn, want die willen niet dat Intel bij hen in de keuken kijkt.

Maar serieus, Intel heeft geen voordeel in het legitimeren van een potentiële concurrent voor zijn x86 architectuur.

Hmm. Tenzij ze met hun x64 architecturen niet competetief denken te kunnen zijn.

Intel is op de goede weg. Duidelijk te zien dat de invloed van Pat Gelsinger goed is.

Het doel daarvan is om chips voor derde partijen te produceren en zo de concurrentie met Samsung en TSMC aan te gaan. Intel investeert miljarden dollars in de uitbreiding van zijn chipproductie om dat mogelijk te maken.
...
Een van de bedrijven waar Intel mee samenwerkt voor zijn RISC-V-initiatief is SiFive. Vorig jaar waren er geruchten dat Intel dit bedrijf wilde overnemen.

Intel wil deze markt gewoon in een vroeg stadium kopen of toch tenminste beheersen zoals ze met x86 hebben gehad, maar dat zal ze (jammer voor hen) niet lukken gezien het licenseless opensource aspect. Vroeger en tot op de dag van vandaag hadden ze nog hun patenten om anderen zoveel mogelijk buiten te sluiten, dat zal met RISC-V onmogelijk zijn, tenzij ze héél ingrijpende veranderingen doorvoeren

Risc-V is onze enige hoop om van ARM en Apple bevrijdt te geraken.

Dat zal nooit lukken, want Apple is meer dan een CPU alleen. Mocht Risc-V beter dan Apple's chips worden, zal apple niet schromen om erop over te stappen, En ze hebben ook nog es extra code om zuiniger te zijn dan de standaard ARM, dus ze hebben al een voorsprong.

[Reactie gewijzigd door Shark.Bait op 9 februari 2022 13:32]

Intel wil met hun funding open ISA projects gewoon aan hun binden, that's all. Rechtstreeks naar hun pioprietary fabs en proprietary connecties on-die... niks meer niks minder. Het is en blijft Intel.

Op dit moment zullen ze het ook wel jammer vinden dat de itanium cpu reeks het niet is geworden. Daar hadden ze ook een aardige nieuwe 64 bits cpu mee neergezet.

Niet alleen op dit moment hoor. Destijds baalden ze ook al stevig.

Vooral HP die met een dood partnership is blijven zitten, een beetje zoals IBM met OS/2 en Microsoft

'Aardig' in de zin van een aardig doodlopende weg.

Intel heeft onderschat wat er nog mogelijk was met x86. Nadat AMD niet alleen flink snellere processors ging maken (Athlon) en ook nog een 64-bit extensie voor x86 verzon moest Intel wel mee. En Itanium kon dat tempo niet bijbenen. Alleen als peperdure server chip leek het nog ergens op.

Het tweede punt waar Intel de mist in ging. RISC is ontwikkeld door te kijken wat compilers kunnen. Welke instructies worden er door compilers gebruikt, en laten we dan die instructies snel maken. Niet, zoals bij CISC bakken met instructies die wel leuk zijn voor assembler programmeurs maar helemaal niet handig voor compilers.

Waar Intel de mist in ging met Itanium, is dat ze wel een architectuur hadden, maar niet de compiler om er gebruik van te maken. Intel heeft gegokt dat compilers wel efficiente code voor de Itanium konden genereren, maar in de praktijk viel dat vies tegen.

Hier kijk je misschien wel te veel alleen naar intel en itanium. De itanium processor was ook een product van HP die er met HP-UX een mooi operating system.

Het was microsoft die (tot windows 2008) ook een itanium windows server product leverde. Maar daar zat een 'andere' prijs en verkoop politiek achter. Details zullen we nooit weten.

Oracle had een database implementatie op itanium, al weet ik niet of dat hp-ux only was of ook voor mswindows. Maar verder weet ik niet van grote software leveranciers die zich duidelijk uitspraken voor itanium.

En natuurlijk niet vergeten: er waren veel linux distributies die wel voor itanium beschikbaar waren.

Zo ongeveer alle wintel gebaseerde software leveranciers hebben gretig gebruik gemaakt van de glijdende upgrade mogelijkheid die amd bood met de 64 bits extentie op het x86 platform. Dat was natuurlijk voor veel zo niet alle partijen een veel te mooi platform om zomaar langs te laten gaan. En de rest is geschiedenis.

Ik zie niet in waarom HP-UX of Windows, Oracle, etc. op itanium iets positiefs over itanium zou zeggen.

Ja, voor AMD64 was x86 een 32-bit platform, waarbij het einde duidelijk in zicht kwam. Maar er waren natuurlijk al veel 64-bit processors.

Het rare is dat vrijwel iedereen z'n eigen architectuur opgegeven heeft met de komst van itanium. Alleen IBM is nog over.

Blijkbaar heeft Intel een heel goed verhaal verteld over hoe fantastisch het zou worden. De specs van de architectuur zijn natuurlijk fantastisch.

Maar met een enorm grote en complexe archtectuur is het natuurlijk bijna onmogelijk om er ook nog wat snelheid uit te halen. Wat Intel probeerde met een enorm transistor budget met bijbehorende chip oppervlakte en warmte ontwikkeling. Dus veel te duur en alleen geschik voor een paar high-end toepassingen.

HP-UX, Windows en OracleDatabases waren de grote 'gebruikers' van het itanium platform. HP en Intel hebben het samen ontwikkeld. HP voor haar HP-UX unix platform, als opvolger van het pa-risc processor platform. En Intel als opvolger van het toen nog echt 32 bits x86 platform. microsoft was toen nog bezig om het windows server platform groot te maken en had dus ook een 64 bits platform nodig. Die partijen waren allen met hun eigen achtergrond op zoek naar een 64 bits platform en vonden elkaar in itanium. En misschien ook wel in de belofte van een schoon en nieuw platform zonder 'legacy'.

Met de komst van itanium heeft alleen HP met haar pa-risc processor haar 64 bits platform 'opgegeven'. De overigen 64 bits processoren uit die tijd waren bij andere partijen: Sun met de sparc processor was nog niet onder de oracle vleugels. Digital (DEC) was nog niet opgegaan in compaq, IBM timmerde met haar power processor aan de weg en zo waren er meer ontwikkelingen.

Digital is overgenomen door Compaq. Daarmee werd de cpu van digital zo een klein radartje in die machine dat ik daar niets meer van heb vernomen. Ondertussen is compaq opgegaan in HP.

Zoals gezegd: Sun is opgegaan in Oracle waarbij oracle de hardware ontwikkelingen aan de sparc processor op een laag pitje heeft gezet, ook niets meer van gehoord. Oracle heeft haar eigen bewegingen met en rond hardware, zowel bij sparc als bij itanium waren ze belangrijk bij het stoppen van de ontwikkelingen.

HP is naar mijn idee de laatste die is gestopt met itanium, volgens de berichten omdat ook oracle de stekker er uit trok.

IBM is inderdaad nog de laatste van de grote organisaties met een eigen unix (of ander os) implentatie op een eigen cpu.

Over de complexiteit van de architecturen is veel te vertellen. Vroeger was het duidelijk, je had 'risc' en 'cisc' maar die tijd is al lang gepasseerd. Er was ook nog eens spraken van 'transputers': cpu-s die nog eenvoudiger waren dan risc (en hopelijk belachelijk veel sneller) en dan met firmware een risc of cisc cpu konden emuleren of zo iets. Transmeta is de enige naam die mij hier nu te binnen schiet.

Op dit moment zullen ze het ook wel jammer vinden dat de itanium cpu reeks het niet is geworden. Daar hadden ze ook een aardige nieuwe 64 bits cpu mee neergezet.

Volgens mij waren er nogal wat parktische problemen met de EPIC architectuur. Voor Intel wel jammer, ja, dan hadden ze nagenoeg de alleenheerschappij gehad over hét 64-bit PC-platform...

De verdere ontwikkeling van CISC zal naar Europa gaan ondersteund met veel subsidie.
Die van RISC_V is meer profitabel en zal in de USA gebeuren.

Ik weet nog goed dat ik het een paar jaar terug met mijn universiteits professor over RISC V had en ik vroeg me toen al af waarom daar niet meer in geinvesteerd werd, goed om te zien dat Intel hier nu toch mee bezig gaat.

Ik zie zeker een toekomst in RISC V, en intel ook zo te zien.

[Reactie gewijzigd door Akamatsu op 8 februari 2022 23:52]