Arm introduceert Arm v9-architectuur

Het Britse Arm heeft een nieuwe generatie van zijn Arm-architectuur aangekondigd. De v9-architectuur volgt de in 2011 uitgebrachte v8-generatie op en moet het komende decennium in miljarden apparaten gebruikt worden.

Socs op basis van de Arm v9-architectuur worden onderverdeeld in drie profiles: m, voor microcontrollers, a, voor applicatieprocessors, en r, voor realtime-processors. De v9-architectuur zet zwaar in op kunstmatige intelligentie en beveiliging. Voor betere verwerking van AI-gerelateerde berekeningen heeft de Arm v9-architectuur een vernieuwde Scalable Vector Extension, SVE2, gekregen, die samen met Fujitsu is ontwikkeld. Bovendien zouden AI-workloads met verbeterde matrixberekeningen in de cpu-cores en vernieuwingen in de Mali-gpu en Ethos-npu, de neural processing unit, versneld worden. Ook Nvidia zou bijdragen aan versnelling van AI-berekeningen.

De beveiliging van data zou gewaarborgd moeten worden dankzij de Confidential Compute Architecture, of CCA, waarmee de soc data en code effectief kan compartimentaliseren, zodat verschillende processen niet ongewenst bij elkaars data kunnen. Arm noemt de compartimenten Realms en data kan daar ongeacht of het in gebruik of idle is, veilig in worden opgeslagen. Daarmee lijken de realms ietwat op virtuele machines of sandbox-omgevingen en zou data onder meer tegen veelgebruikte geheugenexploits als buffer overflows en reuse after free-kwetsbaarheden beschermd worden. Daarnaast werkt Arm mee aan het Morello-project, een beveiligingsinitiatief in samenwerking met de Britse overheid.

Naast beveiliging en AI is ook effectief ontwerp een speerpunt van Arm. Niet alleen beoogt het de komende twee generaties dertig procent meer prestaties uit cpu-cores te halen, maar het bedrijf wil ook meer inzetten op systeemgedreven soc-ontwerp. Bij die Total Compute-ontwerpfilisofie moeten socs speciaal voor specifieke toepassingen ontworpen worden, om hardware optimaal voor het beoogde doel te produceren. Diverse partners hebben aangegeven aan Arm v9-producten te werken, waaronder Google, Marvell, MediaTek en Samsung.

Er zijn volgens Arm in de afgelopen zesentwintig jaar inmiddels zo'n honderd miljard Arm-processors in gebruik geweest. Het bedrijf verwacht de mijlpaal van de volgende honderd miljard Arm-socs de komende vijf jaar te passeren. Die groei zou door steeds meer compute-eisen voor iot en cloud-diensten veroorzaakt worden, waarbij steeds meer data lokaal in plaats van in datacentra verwerkt wordt, om de explosie van data in te dammen.

Reacties (31)

[Balance]

AnandTech heeft een uitgebreid artikel: Arm Announces Armv9 Architecture: SVE2, Security, and the Next Decade

Edit: WikiChip ook: Arm Launches ARMv9

[Reactie gewijzigd door Balance op 31 juli 2024 11:44]

[marcovtjetje]

Even door Anandtech gebladert, maar er is maar weinig over de architecturale kern. Tuurlijk, alle periferie is leuk, maar in praktijk gaat het toch over power/performance van de centrale core.

Zeg maar wat doet de RPI5 ?

[Reactie gewijzigd door marcovtjetje op 31 juli 2024 11:44]

[Natean]

zoals ik het begrijp is het een architectuur.

De werkelijke performantie hangt van de implementatie af.
(DIE-size, power requirements, ASIC capabilities, ...)

Als een producent (Samsung, Snapdragon, ...) ervoor kiest om bepaalde dingen toe te voegen (5G, GPU etc) kan dit bijvoorbeeld ervoor zorgen dat de temperatuur zo oploopt dat de clocks terug worden gebracht.

Om maar aan 1 geval te denken

[marcovtjetje]

Normaal wordt er wel met wat IPC verbeteringen geschermd, instructie latency verlagingen/throughput verbeteringen, aantal poorten/execution units, muopcode cache, branch TLB grootte, load/store veranderingen e.d.

Voor absolute getallen doen andere dingen (en b.v.cache size er ook toe), maar de kern an sich heeft ook parameters. Het viel me erg op dat die totaal ontbraken, terwijl anandtech daar normaal wel pap van lust in zijn zg deepdives

[Reactie gewijzigd door marcovtjetje op 31 juli 2024 11:44]

[graey]

De RPi 5 doet waarschijnlijk ongeveer hetzelfde als nu +5-10%, als je kijkt naar de geschiedenis: toen de RPi 1 uitkwam was de 7-instructieset er al een tijdje, en toch duurde het tot de RPi 2 voor ze overstapten. De zero en zero w zitten zelfs nog steeds op een v6-chip. Het is koffiedik kijken natuurlijk, maar de kans is groot dat ze bij de pi foundation de kat nog even goed uit de boom kijken, en ze zijn natuurlijk afhankelijk van welke implementaties er komen van bijv. broadcomm.

[specs2021]

De RPI5 is nog helemaal niet in beeld.

Anno nu is de RPI4/8GB op 1.5GHz het meest vooruitstrevende product van Raspberry (de gepimpte RPI400 even niet beschouwd). De concurrentie biedt sinds jaar en dag de Rockchip RK3399 (2GHz) of de Amlogic S922X (2.2GHz). Beide rennen rondjes om de RPI4. De opvolgers (RK3588 en S908X) staan in de startblokken voor het eind v/h jaar na vertragingen in 2020 (don't hold your breath). Bij introductie lopen deze dan opnieuw 3-4 jaar achter (maar minder dan de RPI).

In vergelijking met de concurrentie als Pine64 en Odroid zie je dat de Raspberries ook nog enorm achterlopen op de inzet van de RPI4 als arm64 platform. In de zin van de doelen van de Raspberry Foundation is de Pi Zero misschien wel hun beste product (prima geschikt voor hobbyen en educatie).

Als je serieus naar een Arm SBC voor de desktop kijkt, kijk je niet naar een Raspberry.

[duke99]

Hebben dit soort vernieuwingen van ARM (veel) invloed op Apple die nu vol inzet op ARM gebaseerde processoren?

[Carbon]

Hebben dit soort vernieuwingen van ARM (veel) invloed op Apple die nu vol inzet op ARM gebaseerde processoren?

Geen, want Apple maakt geen gebruik van standaard ARM designs.

De extra SVE instructies (SVE2) zijn bedoeld voor DSP en ML workloads en niet relevant voor Apple want de A en M SoC's bevatten al dedicated DSP en ML hardware.

btw Ik lees net dat er op dit moment maar één ARM cpu is die SVE ondersteunt, de Fujitsu A64FX

[TetsuoShima]

Dit is niet helemaal correct. Het gaat hier om een architectuur, geen processor design. Apple maakt wel degelijk gebruik van ARM processor achitecturen, dat is net wat hun design's ARM maakt. Meer nog, ze lopen zelfs voor in het gebruik van nieuwere architectuur op de ontwerpen van ARM zelf. Zo maakten de laatste Apple CPU's gebruik van ARM 8.4 en 8.5, terwijl de ontwerpen van ARM zelf nog op 8.2 zitten.

Het zit er dus dik in dat Apple nog voor ARM zelf met een design op basis van v9 komt en dit kan dus wel degelijk een grote impact hebben op Apple. Als deze nieuwe architectuur daadwerkelijk voor snelheidswinst kan zorgen zoals verwacht wordt, dan zal de voorsprong van Apple op traditionele x86 ontwerpen alleen maar toenemen, hoewel avx-512 daar ook wel een game-changer is voor bepaalde toepassingen.

[Carbon]

Dit is niet helemaal correct. Het gaat hier om een architectuur, geen processor design. Apple maakt wel degelijk gebruik van ARM processor achitecturen

Ik had misschien wat duidelijker moeten zijn, met 'ARM designs' bedoelde ik de reference chip designs

[ari3]

De extra SVE instructies zijn wel relevant als je in de toekomst Java wilt draaien op een Apple met ARM-processor. Er loopt momenteel een incubator om de Java runtime SVE instructies (op ARM) en SIMD instructies (op x64) te laten genereren.

De eigen DSP en custom SVE implementaties van Apple zorgen alleen maar voor fragmentatie van instructiesets en zijn daarom ongewenst.

[sympa]

De v9 heeft nieuwe instructies. Nou is Apple groot genoeg om dat soort dingen zelf te bedenken en toe te voegen, maar het heeft ook zin om over te nemen wat mainstream is natuurlijk.

[Wolfos]

Als Apple slim is doen ze dit voorlopig even niet dus. De verhuizing naar ARM levert de komende jaren nog genoeg werk op zonder nog een extra architectuur erbij, die weer nieuwe instructies heeft.

[svenk91]

Nouja, er is een groot verschil tussen of het instructies toevoegt, maar optioneel zijn om te gaan gebruiken, of dat je instructies vervangt. Ik moet mij nog inlezen, maar verwacht ergens dat de impact voor het draaien van oude software minder groot zal zijn dan toen Apple ging vereisen dat alle ARM software 64 bits is. In het OS zelf zal er wel wat werk verzet moeten worden, maar dat zullen ze hebben met elk processor ontwerp.

[elteck]

Voor Apple maakt het denk ik helemaal niets uit. Zij gebruiken hun eigen compilers, eigen software, dus enkel als die extra instructies ook voordeel opleveren zullen ze overwegen die in de volgende generatie mee te nemen.

Degene die hier echt wakker van moet liggen is Intel/AMD. Want de ARM komt steeds dichter in hun buurt qua prestaties. En iedereen kan het ARM ontwerp oppakken.

[Femme]

Apple heeft er geen baat bij om uit de pas te gaan lopen met ARM. De reden dat je nu zo makkelijk Linux en Windows voor ARM kunt virtualiseren op een M1 is dat een M1 een standaard ARM-instructieset implementeert. Ik zie geen reden waarom Apple dat zou willen blokkeren. Het maakt een Mac alleen maar veelzijdiger. De geschiedenis laat ook zien dat Apple er als een van de eerste bij is om nieuwe versies van de ARM-instructieset te implementeren.

[GeroldM]

Dat verwacht ik niet. ARM maakt een standaard concept ontwerp welke rechtstreeks overgenomen kan worden door een fabrikant die ARM chips wil gaan gebruiken. Apple ontwerpt qua CPU echter alles zelf, en negeren dus het grootste deel van het standaard ontwerp.

Vandaar dat ik weinig invloed verwacht op de prestaties die Apple nu al kan leveren. In hoeverre ARM een kijkje heeft mogen nemen bij Apple (waar ik niet van uitga), zal het verschil tussen standaard concept ontwerp en Apple's ontwerp nog altijd ver uit elkaar liggen.

[well0549]

Alles zelf?

Apple ontwerpt qua CPU echter alles zelf, en negeren dus het grootste deel van het standaard ontwerp.

Denk dat het net andersom is. Op slimme punten heeft Apple er wat extra sillicon bij gezet. Maar het is echt grotendeels en arm chip hoor

[Reactie gewijzigd door well0549 op 31 juli 2024 11:44]

[Jaco69]

Hebben dit soort vernieuwingen van ARM (veel) invloed op Apple die nu vol inzet op ARM gebaseerde processoren?

Voor Apple maakt het extra uit want die maakt een eigen implementatie van de ARM architectuur en kan nu dus aan de slag met deze ARMv9 architectuur.
Fabrikanten die geen eigen CPU implementatie ontwikkelen en simpelweg een ARMv9 implementatie in licentie willen nemen moeten wachten tot er één beschikbaar komt.

[Reactie gewijzigd door Jaco69 op 31 juli 2024 11:44]

[Jan Onderwater]

Dat blijft giswerk. Apple heeft licenties van ARM en maken gebruik van de instructie sett. Maar wat Apple allemaal aan zijn chips sleutelt en er meer inzet is hun geheim.
Dat ze er erg goed in zijn blijkt wel uit de resultaten. Apple heeft hier vooral het voordeel dat hun OS en HW totaal op elkaar zijn afgestemd en geoptimaliseerd.

[ktf]

Ik neem aan dat een groot bedrijf als ARM zijn simulaties op orde heeft, maar ik vraag me toch altijd af hoe de afweging tussen toenemende complexiteit van de instruction set en de performance van doorsnee workloads is.

Stel dat een ARMv9 core met alle toeters en bellen 25% meer chipoppervlak nodig heeft dan een ARMv8 core (geen idee of dat percentage ook maar enigszins in de buurt komt bij werkelijke getallen), zouden 4 ARMv9 cores het dan winnen van 5 ARMv8 cores, bij algemene workloads? En zo nee, dan zullen er vast gebruikers (dat zijn in dit geval dus SoC-fabrikanten) blijven vragen om ARMv8 ontwerpen of deze zelf uitwerken lijkt me.

[Reactie gewijzigd door ktf op 31 juli 2024 11:44]

[dasiro]

en dat mogen licentiehouders dan ook nog vrolijk blijven doen als het hen meer op brengt

[Froos]

Definieer "groot bedrijf". Dat valt namelijk nog wel tegen. In de wereld van IT hardware bedrijven zoals Intel, Broadcom and co, stelt ARM als bedrijf niet heel veel voor. Rond de 7.000 medewerkers.

ARM zelf maakt behalve chip ontwerpen eigenlijk niks. Ze verkopen hun de licenties op hun ontwerpen aan de echte hardware bakkers en verdienen zo de kost. Die bakkers kunnen er ook voor kiezen om er zelf vrolijk mee aan de slag te gaan, zoals Apple of NVidia dat doen. Vandaar dat standaardisatie in de ARM wereld wel een dingetje is. Iedere IoT chip die ARM based is, kan dusdanig zijn aangepast dat het OS van de ene totaal niet werkt met de CPU van de ander.

Misschien wist je dit al, maar ik wilde 't toch even aanstippen

[Jan Onderwater]

Goede ontwikkeling, ARM SOC fabrikanten moeten niet achterblijven, hoe meer concurrentie hoe beter. Hoe sneller de concurrentie, hoe beter men zijn best moet doen en hoe sneller de SOC, hoe meer CPU fabrikanten hun best moeten doen, om niet alleen met elkaar maar ook met ARM SOC te concurreren.
Spannende tijden.

[Icelus]

SVE2 is een interessante update en een mooiere implementatie dan SSE/AVX omdat het "upwardscompatible" is door mee te schalen met toekomstige CPUs.

Er was een kleine verwachting dat Apple de M1 al ARMv9 compatible zou maken, net als dat de Apple A7 de eerste 64-bit ARMv8 SoC voor smartphones was.

[psychicist]

Ik zie het dan ook als de ARM tegenhanger van de vectorextensie van RISC-V en ben blij dat dit er zo snel doorheen is gekomen. NEON bestaat uiteraard nog, maar ik denk dat ik mezelf eerst maar SVE2 ga aanleren, omdat het hopelijk snel in alle nieuwe chips zit.

[Jan Onderwater]

Ik ben erg benieuwd er naar met welke real world prestaties de RISC-V processoren gaan komen.
De eerste berichten zien er veelbelovend uit
https://arstechnica.com/g...ing-performance-per-watt/

[psychicist]

Dat is inderdaad de vraag, maar bij RISC-V implementaties zoals die van Esperanto Technologies is het geheel belangrijker dan de absolute prestaties van de CPU cores. Dat is dan een beetje zoals bij Apple Silicon met de heterogene architectuur.

Verder zijn er nog de transitie van de Chinese Loongson naar RISC-V en de ontwikkeling van Shakti in India.

[Jan Onderwater]

Ja, het in dedicated chips zetten van taken die rekenintensief zijn is voor de snelheid erg goed. Het Decoderen en Encoderen van Video, Compressie, Machine Learning, Encryptie en nog meer is veel sneller als het Hardware encoded is op gespecialiseerde chips als wanneer het in SW gebeurd op generieke chips. Maar ook minder flexibel, je kan echter altijd nog terugvallen op SW als de HW een nieuwe codec of standaard niet ondersteund.
Spannende tijden, het is mooi te zien dat er veel ontwikkelingen zijn in verschillende architecturen.