Reuters: Nvidia en AMD gaan Arm-processors voor Windows-pc's maken

Nvidia en AMD werken aan Arm-processors voor gebruik in Windows-pc's. Dat melden ingewijden aan persbureau Reuters. De bedrijven brengen deze cpu's mogelijk in 2025 uit. Momenteel heeft Qualcomm een exclusieve overeenkomst om Arm-chips voor Windows te maken.

Nvidia is 'stilletjes' begonnen met het ontwerpen van zijn processor, die gebruikmaakt van de Arm-architectuur en Windows kan draaien, melden bronnen aan Reuters. AMD doet hetzelfde. Volgens Reuters maken die plannen deel uit van Microsofts poging om chipbedrijven te helpen bij het maken van Arm-processors voor Windows. De techgigant wil zo beter concurreren met de Arm-socs van Apple. Zowel Nvidia als AMD kan de processors in 2025 al uitbrengen. Er zijn nog geen concretere details of specificaties van de chips bekend. Woordvoerders van AMD, Arm, Microsoft en Nvidia reageerden niet op vragen van Reuters.

Microsoft werkt sinds 2016 samen met Qualcomm aan Arm-socs voor Windows. Qualcomm heeft tot 2024 een exclusieve overeenkomst om Arm-socs voor Windows te maken. Dat bleek eerder al uit geruchten en wordt opnieuw onderschreven door bronnen van Reuters. Qualcomm introduceert op dinsdagavond naar verwachting nieuwe Snapdragon-socs voor Windows-pc's, die voor het eerst gebaseerd worden op zelfontworpen Arm-cores van Nuvia. Microsoft zal deelnemen aan die presentatie, zegt Reuters.

Het zou niet de eerste keer zijn dat Nvidia aan Arm-chips werkt. Het bedrijf biedt al Tegra-socs op basis van Arm aan. Die worden onder meer gebruikt in de Nintendo Switch en in tablets, waaronder Microsofts Surface RT uit 2012. Eerder dit jaar bracht Nvidia zijn Grace-datacenterprocessor met Arm Neoverse-cores uit. Nvidia wilde Arm overnemen voor 40 miljard dollar, maar zag daar vorig jaar van af wegens concurrentiezorgen van markttoezichthouders.

AMD, dat tot op heden vooral met Intel concurreerde op het gebied van x86-cpu's, werkte eerder al aan K12. Dat zou een zelfontworpen Arm-microarchitectuur voor servers worden, maar AMD schrapte die plannen. Ook Microsoft werkt volgens geruchten aan eigen Arm-chips. Die zouden in eerste instantie bedoeld zijn voor servers, maar komen mogelijk ook naar Surface-apparaten.

De SQ1-soc die Qualcomm samen met Microsoft heeft ontwikkeld voor Surface-apparaten. Bron: Microsoft

Reacties (153)

[Kalief]

Ik begrijp dit niet, arm's zijn toch bedoeld voor dedicated devices die een beperkte instructieset nodig hebben, wat heeft een pc daar dan aan?

[CrazyJoe]

Ik denk dat je niet helemaal begrijpt wat RISC voor staat. De term komt uit de tijd dat processoren allerlei specialistische instructies in hun instructie set hadden, die a) bijna nooit gebruikt werden en b) veel clockcycles kosten om uitgevoerd te worden. Het idee dat destijds opkwam bij de mensen van Acorn Computers was dat door de instructie set te vereenvoudigen, ze deze konden versnellen doordat deze in minder clockcycles uitgevoerd konden worden, waardoor de prestaties veel beter zouden zijn.

Toen ze de eerste ARM RISC chips geproduceerd hadden bleek dit inderdaad het geval te zijn.

De moderne ARM instructie set en architectuur volgt nog steeds deze filosofie, maar natuurlijk hebben ontwikkelingen in SIMD ervoor gezorgd dat ook voor ARM nu extensie blokken beschikbaar zijn om hier gebruik van te maken.

Je moet ook in de gaten houden dat de zogenaamde CISC architecturen (waarvan Intels X86 en de daaruit voortvloeiende 64 bit extensies eigenlijk de enige belangrijkste proponent zijn) intern naar een RISC achtige microcode geconverteerd worden. Dus CISC is eigenlijk ook niet meer CISC.

[dmantione]

Even voor de duidelijkheid: We rekenen de ARM-instructieset tot de RISC-instructiesets vanwege load-store en omdat de instructieset orthogonaal is. ARM-instructies verzetten per klokpuls evenwel een boel werk, vaak meer dan bij x86. Niet omdat de instructies specialistisch zijn, maar omdat je alle delen van de processor met één instructie kunt activeren: ALU, barrel-shifter, voorwaardelijke uitvoering e.d. En ARM heeft net zoals x86 complexe krachtige adresseermodes. Het is daarmee conceptueel een heel andere instructieset dan fundamentalistische RISC-architecturen als MIPS en RISC-V.

Een kwestie die het ontwerp van moderne RISC-processoren wel definieert is de pragmatische instelling dat CISC werkt. ARM-processoren hadden lange tijd geen instructie om te delen. Wil je ook niet in een RISC-processor, want daar is microcode voor nodig. Maar ga maar eens proberen een processor te bouwen die met softwarematig delen sneller is dan de hardwarematige deler in een x86... niet te doen. Of ga maar eens een processor bouwen die Rijndael sneller uitvoert dan de hardwarematige Rijndael-instructies in x86.

Ook ARM-processoren hebben daarom tegenwoordig microcode met typische CISC-instructies als hardwarematig delen. En ze vertalen ook ARM-code naar een interne RISC-code, want de 16 zichtbare registers van ARM zijn al lang niet meer concurrerend tegen de 160 interne registers van een Zen. Ook moderne een ARM-processor heeft dan ook een veel grotere intern registerblok dan de 16 zichtbare registers en doet aan register renaming om de zichtbare instructieset naar de interne instructieset te converteren.

CISC is dus geen CISC meer, maar RISC is ook geen RISC meer. Er is gewoon een moderne wijze van processoren bouwen ontstaan en die wordt zowel voor "CISC"- als "RISC"-processoren toegepast.

[Reactie gewijzigd door dmantione op 22 juli 2024 20:30]

[xorpd]

Kleine correctie, ARM heeft 32 general purpose registers, wat nog altijd het dubbele is van x86-64. Dit maakt veel code efficiënter, ongeacht hoeveel rename registers je hebt.

[dmantione]

Ik dacht het niet? https://roboticelectronics.in/arm-registers/

In thumb-mode zijn het er zelfs maar 8.

[xorpd]

We hebben beiden gelijk, het zijn er 16 in 32-bit mode en 32 in 64-bit mode.

[Hans1990]

De instuctieset is maar de helft van een processor. De andere helft is de microarchitectuur. Daar proberen Intel en AMD elkaar al jaren in te verslaan bij het x86 platform: snellere/betere decoding, iets bredere dispatch, meer ALUs, betere branch prediction, betere speculative execution (en betere lekken ), en ook 'betere' microcode.
Daar omheen zit ook nog een stuk cache, bus en geheugen infrastructuur waar ook de nodige verschillen bestaan.

Dit zelfde truukje kan je ook voor ARM en RISC-V processors doen. De 'straight forward' implementatie van zo'n processor is een lineaire pipeline die data hazards oplost. Dat soort processor implementaties zie je veel in microcontrollers of low-end SoCs. Mid-range breidt al uit naar superscalar executie (meerdere instructies tegelijk) en/of speculative execution.

[Snow_King]

Net zoals mijn MacBook met M2: Gewoon werken!

Primair gebruik ik deze voor Mail (Thunderbord), Browsen (Firefox) en daarnaast de Microsoft Office suite nog.

WhatsApp, Telegram, Spotify, ook allemaal applicaties die gewoon op de M2 chip werken.

Heel veel laptops en desktops hebben helemaal geen i386/i686/amd64 nodig, maar hebben werkende applicaties nodig. Als je deze op Windows werkend kan hebben met lager stroomverbruik en hogere prestaties is dat super!

Prima als er een beetje blijft worden geknaagd aan de poten van Intel.

[theduke1989]

maar we praten hier met Nvdia en AMD, dat zijn toch geen standaard huis-tuin-keuken gebruikers zoals jij met je M2 macbook die alleen wat surfen doet? Die heb je toch alleen voor de hardware.
- Gaming als zelfs in bedrijf waar veel rekenkracht nodig is.

Of gaan ze beide ook nog andere PCs bouwen? Dus ik snap inderdaad niet die logica van ze.
Behalve dat ze zien dat het verkoopt bij Apple, dus ook die kant op gaan?


Want dan zou Intel later ook toevoegen?
dus alle hardware boeren die gpus, cpus etc maken, later standaard hardware gaan bouwen

[Reactie gewijzigd door theduke1989 op 22 juli 2024 20:30]

[Frame164]

Huawei gebruikt ARM architectuur in hun data center servers en die doen niet onder voor x86 servers.

[vlaaing peerd]

Het feit dat deze in Huawei datacenters worden gebruikt zegt niet per definitie dat ARM niet onderdoet voor x86_64. Eigenlijk zegt hethelemaal niks, behalve dat de ARM waarschijnlijk het meest geschikt was voor hun.

Datacenters en rekenclusters worden met een specifiek doel ontworpen en dat bepaald de keuze voor een architectuur. Als schaalbaarheid, verbruik of bredere worload ondersteuning van belang is, kan de ARM de geschikte processor zijn.

Als het echter gaat om brute performance per processor, beschikbaarheid van hardware, toepasbaarheid van bestaande software, virtualisatiemogelijkheden dan kom je sneller uit op een traditionele AMD/Intel x86

ARM is vooral goed in paralelle taken, en x86 vooral goed in single core complexere taken.

[ItMeAedri]

Deze chipfabrikanten kunnen ook de gewone huis-tuin-en-keuken gebruikers bedienen in wat voor vorm dat gaat gebeuren valt nog te bezien. Maar kan mij voorstellen dat AMD/Nvidia een partnerschap aangaan om de chips te slijten.

[OruBLMsFrl]

AMD heeft al een aardig marktaandeel in laptops van budget tot high end. Niet gek dat die ARM voor echt low power en ultraportable zouden willen kunnen meepakken. De M1 en M2 draaien ook prima photoshop en zo als je ook maar wat werkgeheugen hebt, die chips kunnen echt wel wat. Laat staan over een paar jaar extra doorgroeien...

[ashwin911]

De ARM processors van Apple zijn echt wel krachtig genoeg voor power user. Bijvoorbeeld muziek producenten gebruiken bijna allemaal Apple hardware en ja ook die met de nieuwe chips van Apple. De ARM CPUs van Apple kunnen zich goed meten met de x86 CPUs van Intel en AMD. Het enige waar Apple achter loopt is de GPU. Dat NVidia nu ARM chips maakt betekent niet dat ze de GPUs die ze maken bij het vuil gooien. Niemand houd hardware boeren tegen om een ARM chip te combineren met een grafische kaart.

[terror538]

Niet om flauw te doen, maar muziek produceren is imho niet echt een power user gebruik.
Audio is niet zodanig zwaar dat je niet wegkomt zonder SIMD e.d.

Bijvoorbeeld (live) video bewerking daarintegen is een stuk zwaarder. (En daar scoren MacBook's ook goed qua populariteit vziw)

[ashwin911]

Hoezo is het niet power user gebruik? Ja als je een simple project met een dozijn tracks hebt die zal niet heel zwaar zijn. Maar een film muziek producent zoals een Hans Zimmer kan een volledig uitgekitte Mac Studio echt wel laten zweten.

Maar over SIMD gesproken ARM heeft toch al sinds v6 een SIMD extension in de instructie set?

[Reactie gewijzigd door ashwin911 op 22 juli 2024 20:30]

[terror538]

Hoezo is het niet power user gebruik? Ja als je een simple project met een dozijn tracks hebt die zal niet heel zwaar zijn. Maar een film muziek producent zoals een Hans Zimmer kan een volledig uitgekitte Mac Studio echt wel laten zweten.

Zelfs dan betwijfel ik het Het aantal samples dat je bij audio per seconde moet verwerken is gewoon vele malen lager dan bij video. Werk je op 48khz dan krijg je 48000 samples per seconde per track voor je kiezen, als pro waarschijnlijk floating point, en anders 32bit. Dat staat imho in het niet met de ~248832000 pixel samples per seconde die je verwerkt bij video (YUV 4:2:2, 60FPS, 1080P). Goed, dat zijn dan natuurlijk wel 16bit waardes per pixel sample.

Dat maakt dat de CPU vele malen minder een beperkende factor is bij audio dan CPU/GPU bij video.

Maar over SIMD gesproken ARM heeft toch al sinds v6 een SIMD extension in de instructie set?

Jep ARM NEON Nog niet mee gewerkt overigens, al mijn projecten zijn X86

[tweaker29789]

Jij lijkt meer te denken aan afspelen van muziek.

Bij muziek produceren zijn het de real-time effecten en grote multisamples die een pc de nek om kan draaien. Die real-time effecten (afhankelijk van betreffende plugins) kunnen veel CPU kracht eisen. En bij multisampled akoestische instrumenten, ook geheugen.
Per track eist het waarschijnlijk minder dan video bewerken, maar met genoeg tracks ga je er qua performance eisen makkelijk overheen.

Keyword is productie hier.

[tweaker29789]

Muziek produceren kan op zoveel manieren en in zoveel stijlen , dat je dit niet zomaar kunt stellen. Met genoeg real-time effecten, hoge kwaliteit sample libraries (denk bijv aan kwaliteit piano multi samples),kun je wel een dikke pc gebruiken.
Een snelle CPU met veel cores, dedicated audiokaart en veel geheugen zijn in sommige gevallen toch echt nodig.
Het enige wat niet echt boeit is de GPU.

[Anoniem: 532949]

M2 macbook die alleen wat surfen doet

Dat is wel een erg denigrerende kijk, de M1 en M2 system on a chip zijn enorm krachtig en zuinig. Hun performance per watt is ook unmatched.

[willieverhoef]

Dat klopt, maar wel voor wen beperkt aantal taken. Bijvoorbeeld geheugen intensieve integer bewerkingen. Want het geheugen is immers omderdeel van de CPU.
Ik denk als het gaat om virtuele memory, custom encryptie (welke niet in een co processor zit) het zeker andersom zit. Maar ja heeft de huis tuin en keuken gebruiker dat nodig.
Verder is de software van Apple snel overgezet naar de nieuwe technologieën. En werkt de 'oude' versie langzamer.

[Luuk1983]

Dat zeg je zeker goed. Performance per watt is super goed. En de absolute performance is heel behoorlijk. Maar een stevige x86 processor kan veel sneller zijn, maar verbruikt meteen een stuk meer. En x86 heeft bepaalde instructies die bepaalde taken heel erg kunnen versnellen. Ik persoonlijk verwacht x86 vooral nog in stevige desktops en ARM voor de rest.

[batteries4ever]

Mijn probleem met de Mac is dat 90% van alle applicaties prima werkt, maar de rest niet of minder, zelfs bij PowerPoint komt het soms tot afwijkingen met speciale fonts e.d. Daarvoor krijg je bij Apple dan een mooi geintegreerdee hard/software combo terug, ook al kost dat wel wat.
Hier krijg je, zeker in het begin een nog duidelijk lagere compatibiliteit en geen "Apple bonus". zeker voor de early adopters geldt: wel de lasten, niet de lusten.

MS heeft een lange traditie van systemen die volledig gefaald hebben, b.v. Windows RT, hele stapels telefoon OS-en, tot schade van klanten en ontwikkelaars: ik zou mensen aanraden er voorlopig met een grote boog omheen te lopen tot bewezen is dat het platform toekomst heeft!

[SPee]

Als Windows niet werkt, kun je overstappen naar Linux

[BruceLee]

Ik zou zelfs willen zeggen dat ze veel veel sneller en efficiënter zijn dan x86 cpus. Een macbook pro m2 pro of max loopt rondjes om de windows laptop en al helemaal als je de netstroom er uit trekt dan doet de windows laptop het niet zo goed. De performance per watt is gewoon zoveel beter.

[willieverhoef]

Dus geen rondjes. Maar performance per watt. De huidige processoren zijn echt een heel stuk sneller maar hebben meer energie voor nodig.

[Onbelangrijk]

Welke delen van office gebruik je? Als dat vooral word is kun je het ook af met een laptop van 12 jaar oud. De andere apps kunnen ook op die oude dingen.

Alleen grote database en spreads niet

[Snow_King]

Outlook, Office, Teams, Excel, Word.

Die M2 Pro is gewoon heerlijk snappy, dat is echt fijn werken.

[Onbelangrijk]

Outlook, Word en teams gaat prima op een ouwe bak. Heel grote databases en spreadsheets is wat lastiger, maar 99.98% kan ook prima op een oud lel.

En die ouwe dingen zijn dan snappy zat.

[Silentek]

For windows betekend niet gelijk een desktop PC, denk hierbij aan tablets, kleine laptops etc.
Ook Microsoft doet steeds meer in de cloud (denk ook aan Office 365), daarvoor heb je niet gelijk hele zware processoren en videokaarten nodig.

Waarschijnlijk zal een groot deel zijn voor Kantoor pc's en laptops, dus gewoon voor je gemiddelde kantoor medewerkers die enkel Word en een browser gebruiken.
Ik denk dat de gemiddelde Tweaker dit niet op hun thuiskantoor gaan gebruiken.

[checkpointx]

Ik denk dat het een grove misvatting is om te denken dat ARM low performance is, Apple silicon veegt de vloer aan met de performance van de gemiddelde PC. Grootste probleem is zoals al eerder werd genoemd compatibiliteit van apps/windows/libraries. Apps als Wine / Crossover laten zien dat je zelfs hele zware 3d games (Cyberpunk, Diablo 4) in emulatie prima kan draaien op een ARM chip, nu alleen nog native

[d3x]

niet te veel overdrijven.... de M1 mag dan op een moment komen dat de competitie wat achterop lag maar dat is vooral omdat er met intel vergeleken wordt . Ook vandaag is dat nog het geval want Intel loopt nog steeds achter (desondanks het meerendeel nog steeds een intel koopt in hun laptop, maar soit, de naam doet ook iets)

een AMD phoenix APU kan perfect mee met een M2 design, alhoewel ik niet fervent gebruiker ben vna benchmarks, hier is een vergelijk
https://www.notebookcheck...14975_14948.247596.0.html

de vloer vegen is er sterk over, nog wel iets efficienter, maarja veel code zit dan ook op minder geoptimaliseerd x86.

[Reactie gewijzigd door d3x op 22 juli 2024 20:30]

[Coolstart]

een AMD phoenix APU kan perfect mee met een M2 design

Dat is echt appelen met peren vergelijken. De AMD R9 7940HS wordt nooit als enkel de CPU gebruikt in laptops. Altijd met een GPU wat de totale efficientie van de laptop doet dalen.

M2 Max laptops gaan 18u mee op een acculading. https://www.laptopmag.com...s-are-in-it-just-wont-die

De M2 Max is op de koop toe veel minder efficient dan de M2. Ik ga niet zeggen dat M2's de vloer vegen met AMD maar wat efficientie betreft loopt de M2 echt wel een generatie voorop en in een laptop heb je daar veel aan. Je kan immers koeling ruilen voor een extra batterij omdat je minder warmte moet disiperen.

Op elke ARM post komt er ook wel de opmerking: "Ik begrijp dit niet, arm's zijn toch bedoeld voor dedicated devices die een beperkte instructieset nodig hebben, wat heeft een pc daar dan aan?"

@Kalief Als je weet wat een instructieset is neem ik aan dat je weet dat M2 succesvol op ARM draait. Apple heeft toch bewezen dat ze heel praktisch bruikbare laptop én desktop CPU's kunnen bouwen op basis van ARM chips dus ik begrijp uw sentiment niet dat ARM slecht zou zijn.

[d3x]

ben jij dan niet appelen met peren aan het vergelijken? je spreekt over technologie en dan ineens klopt het niet meer in je plaatje.Het is niet omdat leveranciers beslissen om hier de betere gaming laptops van te maken dat de apu zelf niet in staat is om degelijke prestaties/power neer te zetten.
De benchmark die ik link zijn nogthans allemaal op cpu basis en ook de power metingen zijn van cpu benchmarks.

de phoenix heeft ook een hoge efficientie, zelfs met die theoretische claims van een leverancier zullen ze dichter bij elkaar zitten dan het statement " de vloer aanvegen"
https://wccftech.com/amd-...20the%20CES%20this%20week.
dat ze dan in realiteit niks in die zin bouwen dat is dan weer zeer typisch aan al die OEM, het apple design is er nu net ook met een bepaalde reden.

Er is niks mis mee met die apple designs, zeg ik ook niet, als dat je keuze is, so be it, het is duidelijk je ding om uber lange batterij te hebben en je geeft er andere dingen voor op en je hebt er veel aan blijkbaar. Fantastiisch, jouw keuze. Ik heb een Lenovo thinkpad met amd 5000 serie nu al bijna 3j en die doet ook nog steeds met gemak 8-10u op batterij en die kost geen arm en been en gewoon op x86, voor mij voldoende toen al. Maar zeg niet dat er tegenwoordig niks anders is op de markt die niet capabel is... als je power vraagt van die M chips dan zal de batterij ook weldegeljik minder zijn en hier haal je wederom een vergelijk met een waardeloos x86 MS OS tegen een sterk optimised apple IOS, er zijn ook x86 laptops die 13-14h meegaan. Het is niet hetzelfde, maar gewoon het statement ver voor zijn tijd is het gewoon niet. Ja het M design is anders en heeft voordelen met shared ram etc, het is dan ook een volledig eigen eco systeem, ze doen wat ze willen kwa architectuur en OS. AL duwen ze zelfs de gehele shabang weg van x86 intel naar de eigen cpu remember, het eco systeem moet mee. Als dit gesloten eco systeem je ding is dan is dat je keuze. Een ARM based architectuur voor desktop zal evenmin onderdoen, de laatste generatie chromebooks gaan ook gigantisch lang mee op batterij. Het is altijd een combinatie van architectuur+os.

tegenwoordig op deze site moet het altijd zijn: dat is de betere, dat is de efficienste, dat is de beste en er is geen alternatief want dat is slecht en niet voldoende voor niemand.

[Reactie gewijzigd door d3x op 22 juli 2024 20:30]

[epo]

"tegenwoordig op deze site moet het altijd zijn: dat is de betere, dat is de efficienste, dat is de beste en er is geen alternatief want dat is slecht en niet voldoende voor niemand."

Volgens ben jij heel druk bezig met bepaalde keuzes hard te verdedigen, dus kijk eens in de spiegel

[d3x]

als dat je conclusie is op mijn verhaal dan is er geen verder gesprek mogelijk want dan kan je duideljik niet lezen... mijn eerste antwoord was op "veegd de vloer met"

of mogelijks vervomen sommige OS'en de tekst of AI enhanced zodat ze er anders uitkomen speciaal voor jouw. Als je fruitjes je een beter gevoel geven, heel goed voor jouw. Mij maakt het niet uit en ik koop wat ik nodig voor wat ik nodig heb en het laatste wat ik zal volgen is wat feedback uit deze chats met veel blabla.

edit, je antwoord hieronder zegt wederom alles. je bent zo eentje van kampen.

[Reactie gewijzigd door d3x op 22 juli 2024 20:30]

[epo]

Het zit duidelijk dwars en je doet er alles voor om lezers voor jouw kamp te laten kiezen, ik snap dat nooit die drang.

[Onbelangrijk]

Vrijwel niemand gebruikt een laptop 18 uur, en veruit de meesten hebben gewoon hun voeding er naast staan.

[nehal3m]

Totdat het kan. Ik heb een 14" M1 Pro en als die mee gaat in de tas blijft de oplader meestal thuis. Een werkdag haal ik altijd met ruim gemak, als ik thuis kom is de accu nog half vol. Zo'n belachelijk lange accuduur geeft je heel erg veel vrijheid qua gebruik van je laptop.

Ik zou niet meer terug willen.

[Gropah]

Daarbij moet men ook niet vergeten dat de M1/M2 van apple naast ARM nog een ander significant verschil is in ontwerp. De M-chips van apple zijn SoCs. Ze bevatten naast de CPU en GPU, ook het RAM. Doordat het allemaal zo dicht bij elkaar zit, is het makkelijker om hogere snelheden en throughput te halen. Dit zorgt er op zijn beurt weer voor dat CPU en GPU minder lang hoeven te wachten bij cache-misses en dergelijke, waardoor ze sneller zijn.

[Simyager]

Weet iemand hoe AMD en Apple de TDP meten? Ik weet dat Intel en AMD dat anders meten en ik wil niet Apple's met peren vergelijken (pun intended ).

AMD Ryzen™ 9 7940HS verbruikt 3554W
en Apple M2 Max Volgens Tweakers komt die niet boven 33W

Maar volgens Notebookcheck zou de CPU niet boven 25W moeten uitkomen:

The M2 Max is manufactured in 5 nm at TSMC (second generation) and integrates 40 billion transistors. The power consumption of the CPU part is up to 36 Watt according to powermetrics. When fully loading the CPU and GPU cores, the chip uses up to 89 Watt and the CPU part is limited to 25 Watt.

Dus als ik het goed begrijp is AMD met maximaal 54W de CPU+GPU combi en M2 max doet maximaal 79W-89W?

Dan doet AMD het super goed met "maar 54W". De GPU van M2 Max is waarschijnlijk wel iets beter.

Maar dan snap ik niet waarom in jouw link AMD ineens 130W verbruikt?

Power Consumption - Cinebench R15 Multi Power Consumption - external Monitor *

R9 7940HS: min: 89 avg: 109.5 median: 107.6 (20%) max: 134 Watt
M2 Max: 72.8 Watt (13%)

[Reactie gewijzigd door Simyager op 22 juli 2024 20:30]

[GromuhlDjun]

Het is zeker waar dat de performance per watt zeer goed is op Apple silicon momenteel.
Wat ik opvallend vind, zijn altijd die scheve vergelijkingen die ik vaak zie bij apple laptops/desktops versus een doorsnee pc.
De vergelijking gaat niet op omdat het prijsverschil dan astronomisch is. Wanneer je een apple laptop vergelijkt met dezelfde prijsklasse x86 laptop/desktop, dan ligt het ineens een stuk dichter bij elkaar. Soms "wint" apple, soms "wint" de x86 variant.
De apples met peren vergelijkingen ook altijd

[StGermain]

Prima als in met gezeìk en vage crashes.

[checkpointx]

Daarom ben ik ook naar apple overgestapt, dan ben je daarvan af

[HerrPino]

De performance van een gemiddelde PC?? Volgens wie, volgens Apple zeker ... en dan komen ze waarschijnlijk met foto en video bewerking toepassingen. Bij video en fotobewerking toepassingen hebben de M1 en M2 voordeel doordat het geheugen dichterbij de CPU zit. Dat is een voordeel dat Apple heeft,.. voor hoe lang is de vraag want bij Intel zijn ze daar ook mee bezig. Apple vergelijkt ook op hun website hun eigen CPU's met elkaar. Waarschijnlijk omdat ze weten dat ze het op pure performance afleggen tegen de snelste x86 CPU's van AMD en Intel.

Apple silicon is vaak energie efficienter, Intel silicon is tijd efficienter... en tijd heeft ook waarde.

[checkpointx]

Zoals je zelf al aangeeft ligt het eraan wat je doet welke processor de beste keuze is.
Belangrijker is dat ARM cpu's allang niet meer de langzame cpu's die in embedded spul zitten, het feit dat we deze discussie alleen al hebben bewijst dat al...

ohh enne, sowieso is apple sneller/beter/goeier

[dmantione]

ARM is geen beperkte instructieset. Wellicht denk je dat omdat het een RISC-processor is of omdat je het met RISC-V verwart. ARM is niet kreupel en volledig functioneel en anders dan dat x86 de industriestandaard is, is er weinig reden waarom een PC geen ARM-processor zou kunnen hebben.

[Finraziel]

RISC staat letterlijk voor reduced instruction set computer dus ja dat is het wel... Alleen betekent dat niet dat de computer ook beperkt is in wat het kan, daar zal de verwarring in zitten.

[MSalters]

Dat is wel de historische achtergrond van de term, maar een moderne 32 bits ARM chip met de verschillende ARM floating-point vector extensies heeft véél meer instructies dan de originele CISC 8086.

Een feitelijk verschil wat nog steeds relevant is, is dat x86 een heleboel operaties direct op geheugenwaardes kan doen, terwijl ARM diezelfde instructies alleen op registers kan uitvoeren. De trade-off is dat ARM daardoor historisch meer ruimte op de chip had voor registers. Maar een moderne x86 heeft al meer dan honderd registers per core, dus dat voordeel van RISC is verdampt.

[Blokker_1999]

De verschillen zijn ook gewoon grotendeels weggewerkt en termen zoals RISC en CISC zijn simpelweg achterhaald. Net om snelheid te kunnen winnen heeft men bijv. ook hardwarematige instructies op x86 laten vallen bijvoorbeeld.

[Aaargh!]

RISC heeft niet minder instructies, het heeft eenvoudigere instructies. En het 'eenvoudige' slaat hier dan met name op de adresseringsmodes. Op CISC, en dan specifiek x86 heb je van elke instructie een enorm aantal varianten met verschillende mogelijkheden om aan te geven waar de data vandaan komt en waar deze naartoe moet. Als voorbeeld een 'add' instructie die 2 getallen bij elkaar optelt. Op RISC heb je alleen een instructie die de inhoud van 2 registers bij elkaar optelt en in een 3e register opslaat. Op CISC heb je deze ook, maar daarnaast heb je een versie die een v/d waardes van een geheugenadres haalt. En een variant die het resultaat naar een geheugenadres wegschrijft, En een variant die een waarde ophaalt vanaf het adres in register X met een offset van de waarde in register Y, etc. etc. In x86 is dit een enorme waslijst met adresseringsmodes, en dat voor bijna elke instructie.

In RISC heb je 2 groepen instructies: instructies die data van/naar het geheugen verplaatsen en instructies die bewerkingen uitvoeren op data in registers. Op RISC moet je dus altijd eerst data ophalen met 1 instructie (LOAD) daarna bewerken, en dan weer wegschrijven naar geheugen (STORE). RISC word dan ook wel een load/store architectuur genoemd.

In x86 kan je zoiets in 1 instructie doen. Je zou denken dat dit sneller is maar dit is niet noodzakelijk zo. De processor moet nog steeds dezelfde acties doen, de opdracht is alleen wat efficiënter opgeschreven. En dat is precies waarom CISC zo populair was. Een andere manier om tegen CISC aan te kijken is dat het ene vorm van compressie is, instructies zijn efficiënter gecodeerd en nemen dus minder ruimte in beslag. Heel aantrekkelijk toen elke byte geheugen kostbaar was.

RISC code is dus iets groter dan CISC code, en een RISC processor is dus meer afhankelijk van geheugenbandbreedte om snel de instructies aan te voeren. Daarom zie je in RISC processoren vaak relatief grote caches. Dit is een klein nadeel van RISC.

Het grote voordeel van RISC is dat elke instructie exact even lang is. Elke ARMv8 instructie is 32-bits lang (4 bytes). Ter vergelijking: een x86 instructie kan van 1 tot en met 15 bytes lang zijn. Dit maakt de instructie-decoder op RISC veel eenvoudiger en maakt het mogelijk om simpel meerdere instructies tegelijk te decoderen (je weet immers precies waar de volgende begint, dus je kan dit simpel parallel doen). De apple M1 bijvoorbeeld decodeert 8 instructies tegelijk, waar dit bij x86 (IIRC) maximaal 4 is.

Deze brede decoder maakt het mogelijk een enorme reorder-buffer te vullen, en hoe groter je ROB hoe makkelijker het is om alle execution units in een CPU core aan het werk te houden. Je CPU wordt hierdoor dus een heel stuk efficiënter, er staan minder vaak delen van de CPU niets te doen.

RISC vs CISC is dus zeker niet achterhaald het maakt nog zeker verschil (code size, bandbreedte afhankelijkheid, decoder complexiteit, efficiëntie)

[Aaargh!]

Dat is wel de historische achtergrond van de term, maar een moderne 32 bits ARM chip met de verschillende ARM floating-point vector extensies heeft véél meer instructies dan de originele CISC 8086.

Daar zit veel verwarring in bij de term RISC. Je moet het niet lezen als Reduced (Instruction Set) maar als (Reduced Instruction) Set.

[xorpd]

x86 heeft misschien wel 100+ registers maar van de belangrijkste, de general purpose registers, er maar 8 in 32-bit mode en 16 in 64-bit mode. Dit terwijl ARM er 32 van heeft. Dat is een aanzienlijk voordeel en nog steeds niet verdampt dus.

[MSalters]

Nope. Ice Lake bijvoorbeeld heeft al 280 registers in de register file. Waar jij aan denkt zijn general purpose register names, maar sinds register renaming is er geen vast verband meer tussen de register file grootte en het aantal namen. Namen zijn dynamisch en veranderen letterlijk per uitgevoerde instructie.

Het voordeel van weinig register names is dat je instructies korter zijn, en er dus meer in een cache passen. SPARC deed om die reden bij elke functiecall een expliciete, simpele register rename. Maar op moderne x86 fungeert de top of stack als een uitbreiding van je register names. "POP R13" plakt hoogwaarschijnlijk het R13 label op één van die 280 registers, eentje die daarvoor nog geen naam had.

[xorpd]

Hoe meer general purpose registers je hebt, hoe efficiënter de compiler code kan genereren. Daar kunnen rename registers niet tegen op. En ik moet toegeven dat de stack engine snel is, maar nog altijd niet zo snel als een register.

[MSalters]

"rename registers"?! Jouw model van CPU's is ongeveer een kwart eeuw verouderd. Die 280 registers van Ice Lake zijn de General Purpose registers. Er is nooit een x64 geweest met maar 16 General Purpose Registers. Alle GP registers kunnen renamed worden.

De Vector Register file (AVX/floating point) is ook renamed, maar dat zijn tegenwoordig 256 of 512 bits registers.

Je idee over de "stack engine" is iets minder verouderd, maar ook al weer een decennium achterhaald. De waardes op de top of stack zijn fysiek te vinden in unnamed registers, en een stack pop is dus óók een register rename. Dat wordt door de instructie-decoder afgehandeld, en kost daardoor 0 cycli - letterlijk. De rename gebeurt tegelijkertijd met de voorafgaande instructie.

[xorpd]

Semantiek. x86-64 heeft 16 general purpose registers (%rax t/m %r15), en Ice Lake 280 rename registers. General purpose registers zijn direct adresseerbaar, maar onder water rename registers. De stack engine heeft een maximale diepte. Code die alleen registers gebruikt is sneller dan code die ook de stack gebruikt om extra registers te creëren (op AMD 5000 series getest, geen idee wat Intel doet).

[MSalters]

De "stack engine" die jij voor je ziet bestaat simpelweg niet. Het is niet zo dat "code" de stack gebruikt om extra registers te "creëren". Die registers bestaan fysiek; genoeg die shots te vinden op Internet waar je ze letterlijk aan kunt wijzen. Wat code kan doen is register waardes naar de stack pushen (of een stack-relative offset). En wat jouw Ryzen dan doet is de register naam vrijgeven. De bits blijven fysiek in de register file staan.

Jouw Ryzen kan zelfs een fysiek register gebruiken voor dingen die volgens je code nooit in een register hebben gestaan: https://www.agner.org/forum/viewtopic.php?t=41

[redniels]

Arm is in die zin "kreupel" in dat het een soc is. Daardoor niet modulair, niet open.

Maar of dat in 2023 nog steeds een nadeel is.... (ik denk het niet)

[dmantione]

Wat verplicht je om een ARM als SoC uit te voeren? Niets.

[slamhk]

Yup Ampere maakt ARM CPUs die gecombineerd kunnen worden met DDR4/5 RAM en ondersteuning heeft voor NVIDIA GPUs.

Dit is iets wat NVIDIA ook kan doen

[youridv1]

Arm is in die zin "kreupel" in dat het een soc is.

Dit heeft niets met ARM te maken. Niets weerhoudt fabrikanten om socketed ARM cpu's te maken. Dat ze dat nog niet gedaan hebben, heeft andere redenen, zoals dat er nog weinig desktop usecases zijn voor ARM chips.

"Er zijn geen socketed ARM chips met standaard moederbord support te koop" is je punt

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[youridv1]

Alle smartphones en tablets zijn arm based en zijn niet gelimiteerd tov "conventionele pc's" behalve in hun interface die meer voor touch gemaakt is dan traditionele pc taken.

Het is al eerder gezegd, maar ik kan als software engineer geen beperkingen bedenken voor ARM tov x86 anders dan dat het niet zo standaard is momenteel.

[MSalters]

x86 heeft een sterker cache coherence model. Voor multi-threaded software betekent dat dat je minder moeite moet doen om te zorgen dat een write van één thread ook zichtbaar is voor andere threads. In de praktijk een relatief klein voordeel; je gooit als programmeur er gewoon een mutex omheen en het werkt overal.

[blorf]

Prijs/prestatie? Volgens mij maakt elke x86 gehakt van een ARM-processor die ongeveer hetzelfde kost.

[fastedje]

Bij AWS geld precies het omgekeerde. Ook de performance voor integer operaties doet bij ARM niet onder voor x86 (ARM is zelfs sneller). Voor floating point ops is het omgekeerd, hangt dus van de workload af.

[blorf]

Vergeleken met mijn Ryzen 7 3800X, welke ARM-CPU komt daar in de buurt? Dat moet wel iets extreems zijn. Het gemiddelde aan SoC's haalt daar de 10% niet van in benchmarks.

[fastedje]

Een voorbeeld van een benchmark tussen intel en arm bij AWS:
https://youtu.be/KLz8gC235i8?si=iOJGEFqA9BwodEeu

[blorf]

Een AWS Graviton?

[fastedje]

https://aws.amazon.com/ec2/instance-types/t4/

[youridv1]

Bij mijn weten kan de Apple M2 Pro uit de Mac Mini zich heel aardig meten met een R7 5800X. Benchmarks moet ik even terug zoeken.

Benchmarks tegen andere laptop chips: https://www.youtube.com/watch?v=FWfJq0Y4Oos
Kerel die zn macbook tegenover een R7 5800X zet in cinebench https://www.youtube.com/watch?v=tC2jpahyTSE

Dat is dus een M2 in een laptop die binnen 5% van een moderne dekstop chip zit die 4x zoveel vermogen verbruikt.
Let ook goed op bij de laptop benchmarks hoe de M2 zich meet met high end laptop chips, terwijl hij 1/2-2/3 van het piek en sustained vermogen verbruikt.

Apple is over op ARM. Mobile is over op ARM. Server spul timmert hard aan de transitie. De enige remmende factor voor ARM op dit moment is het kip-ei probleem op de desktop markt. Windows ARM is een onderschoven kindje omdat er geen hardware aanbod is voor desktop users en vice versa.

Als microsoft nu zou zeggen "we kappen met native x86 voor windows 12 en gaan over op ARM" a la Apple, dan is de desktop transitie zo voorbij.

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[TERW_DAN]

Daar kun je ze voor gebruiken. Maar ik zou je telefoon niet per se een apparaat noemen met een beperkte instructieset. Of de nieuwe Apple Silicon MacBooks. Dat draait allemaal op ARM.

[Kek]

De aanname die je doet is niet (meer) correct. ARM kan alle devices zitten waar x86(_64) in zit. Kijk maar naar telefoons, alle Apple computers..

[fastedje]

Als je ooit assembly voor ARM hebt geschreven dan zie je dat de instructieset eigenlijk heel fijn is om mee te werken. Als voorbeeldl elke instructie kan je conditioneel uitvoeren afhankelijk van de uitkomst van de vorige instructie(s). Verder zijn er voldoende registers om tijdelijke vars in op te slaan. Als je de add instructie bekijkt dan kan je 3 registers opgeven: 2 voor de input en 1 voor de output. Dit maakt de instructies efficiënt maar ook fijn om mee te werken. Verder zit deze filosofie verwerkt in de meeste instructies.

[Reactie gewijzigd door fastedje op 22 juli 2024 20:30]

[jangineer]

ARM/RISC-based CPU's doen het, kort door de bocht, in performance per watt vaak een grootteorde beter dan hun x86-concurrenten. Er is een goeie reden dat je geen x86 vindt in smartphones of tablets.

Vroeger werden ze gezien als 'speelgoed'-processortjes, maar o.a. Apple's M-series chips bewijzen tegenwoordig het tegendeel.

Als hier een ietwat deftig product uitkomt is x86 op langere termijn ten dode opgeschreven.

[xorpd]

Ook ARM is op de lange termijn ten dode opgeschreven als RISC-V volwassen is. Alles kan namelijk nog zuiniger, nog efficiënter en nog goedkoper.

[Wolfos]

ARM word al heel lang gebruikt voor general-purpose computers, en heeft ook geen beperkte instructieset meer. Die extra instructies zijn gewoon nodig, en veel x86 extensies hebben dan ook een directe tegenhanger op ARM. Zo is Neon vergelijkbaar met SSE.

Het voordeel van ARM ten opzichte van x86 is niet dat het kleiner is, of sneller of efficiënter. Dat is aan de CPU die de instructieset implementeert. Het voordeel is dat ieder bedrijf een ARM chipset kan maken.

[Hennek[]]

Er zit een fundamenteel verschil in aanpak tussen de X86 en ARM / RISC in de manier van een CPU aansturen en ontwerpen. De x86 is een complex instructie set computers (CISC). Dit houdt in de de instructie set groot is en complexere taken in 1 instructie kan uitvoeren. Voordeel is dat je met weinig code complexe taken kunt uitvoeren, na deel is dat je grotere en complexere CPU architectuur nodig hebt.
De reduced instruction set computer (RISC) heeft minder instructie. Dit heeft voor deel van de CPU architectuur eenvoudiger is. Je kun je net zo veel mee allen zul je meerder instituties aan elkaar moeten plakken om complexe taken te uit te voeren.

Voorbeeld (alleen voor de gedachte)
8^3 uit rekenen.
x82 - heeft een kwadraat instructie en deze opdracht gaan uitvoeren
ARM - heeft geen kwadraat instructie en je moet er dus meerder eenvoudigere instructie van maken bv. 8*8*8.

Windows voor ARM zal dus de taken 'onderwater' moet omzetten naar de juiste instructies.

https://en.wikipedia.org/..._instruction_set_computer
*fixed typo

[Alxndr]

Zou je een Chromebook niet ook een 'PC' (laptop) kunnen/willen noemen?

Hoeveel % van de mogelijkheden die een PC biedt gebruikt de gemiddelde gebruiker nooit in z'n leven?

Als ik geen PC gamer zou zijn, zou ik alles wat ik doe op een niet x86 machine kunnen doen: office taken, media consumptie, email, er is eigenlijk niets wat nog lokaal ipv in de cloud gebeurt (of hoeft te gebeuren).

En als ARM systemen daarbij vele malen zuininger zijn (en dus actieve koeling achterwege kan blijven..)

[1Mark]

Energie efficient zijn: mijn m1 max 25W is sneller dan mijn 9700k+2080rtx die samen 400W verstoken..

[computerjunky]

Is maar net welke applicaties je draait. Leuk in benchmarks dat die M1 sneller is (mede door gebrek aan hyperthreading in die chip) maar veel applicaties zijn vele malen sneller in de praktijk en veel draait er helemaal niet op.

[1Mark]

Ik bedoel meer dat de architectuur veel potentie ivm de x86 architectuur en al helemaal ivm de intel varianten ervan.

Sommige zaken gaan op de m1 ook factoren sneller..

[vstrien]

Een beperkte instructieset (RISC) is al heel lang geleden efficiënter gebleken dan een complexe instructieset voor eigenlijk alle processors. Zelfs Intel gebruikt sinds de Pentium Pro achter de schermen een vertaalslag om de "complexe" (CISC) instructies te vertalen naar beperkte instructies (RISC) (waarom ze dan toch CISC blijven aan de buitenkant).

Toen de M1 uitkwam bleek opeens dat een ARM-proc op veel vlakken een (toenmalige) i9 kon evenaren of voorbijstreven. En dat voor veel minder energieverbruik en warmte.

Daarnaast is ARM een licentie-model waardoor andere chipmakers makkelijk(er) chips kunnen produceren. Daardoor kan Apple dus "zelf" chips produceren. Wat de implicaties voor business-modellen zijn wordt in deze exponent-podcast uitgelegd (Episode 122 - from Intel to Disney).

Dat is voor pc's dus erg interessant.

[Reactie gewijzigd door vstrien op 22 juli 2024 20:30]

[d3x]

omdat het meerendeel van de keuken/huis/tuin gebruikers die x86 instructie set niet nodig hebben en perfect met ander os en tools uit de voeten kunnen.

Een chromebook zou bv perfect kunnen draaien op een arm systeem, heb je die omslachtige x86 code niet voor nodig. Zo heeft windows in het verleden ook al een poging gedaan om met een OS te komen op andere instructie, alleen het probleem was dat de apps toen nog niet echt portabel waren. groot verschil met huidige opzet en beschikbaarheid.

[FreezeXJ]

Apps zijn soms prima portable, het probleem ligt puur bij Windows. De enige pogingen tot Windows-op-ARM (Windows Phone) zijn na een jaar alweer geditched, omdat de volgende versie er was, die niet backwards compatible was.
Linux op ARM is een heel ander verhaal, dat werkt gewoon, en er zijn ook apps voor. Zodra ARM ook voor desktop-gebruik doorbreekt komen de applicaties ook wel mee, het meeste is een kwestie van wachten tot de frameworks en libraries ook die stap echt durven maken, en daar zit vaker een probleem. Iets met een kip, een ei, en een boer die z'n kippen slacht voor ze kunnen leggen.

[sspiff]

Dat zijn lang niet de enige pogingen om Windows op ARM te laten draaien. Vandaag kan je ook gewoon op ARM gebaseerde laptops met Windows kopen, al zijn het er niet veel. De ThinkPad X13S van Lenovo draait bijvoorbeeld op een ARM chip van Qualcomm.

Het ecosysteem is duidelijk niet zo robuust of volwassen als ARM op Linux, dat uiteraard voordeel put uit het feit dat een groot deel van de desktopsoftware gewoon open-source is en dus voor ARM gecompileerd kan worden in veel gevallen.

Het kernel en drivergebeuren is bij Linux dan wel weer wat minder voorspelbaar. De meeste chips hebben gebrekkige support die niet kan opgenomen worden in de Linux kernel zelf, of in veel gevallen slechts bestaat uit wat binaries voor een specifieke kernel. Laat ons hopen dat dit bij AMD en Nvidia niet het geval wordt.

[willieverhoef]

Wat hebben we aan een super uitgebreide instructie set ?. De meeste software is een webserver, of zijn simple applicatie met wat verplaatsen van wat data. Encryptie is off loaded of kan in een apparte processor worden gedaan. Zeker met talen als .net java en node js is het vaak veel eenvoudige acties. De huidige arm us misschien op energie gebaseerd. Maar de oude sparc van sun was ook een heel snelle risc processor.
Ook intel wilde met 64 bit opnieuw beginnen zonder dat oude software bleef draaien. Nu werkt alle oude software nog steeds op de moderne processor. Dat kost gewoon performance en ruimte.

[_Thanatos_]

Wat precies maakt een instructieset zuinig? Waarom kan x86 niet net zo zuinig gemaakt worden als ARM?

[Mijzelf]

Voor zover ik weet heeft het hoofdzakelijk met pipelining en geheugen access te maken. Bij een x86 heeft een enkele instructie+argumenten een variabele lengte, terwijl dat bij Arm altijd 32 bits is (of 64 bits op een 64 bits machine.)
De variabele lengte betekend dat de boel niet ge-aligned in het geheugen staat. Het laden van een waarde van een niet-aligned adres in een register kost meer energie. Verder maakt dit het lastiger om te pipelinen, omdat je de opcodes moet lezen om te weten hoeveel bytes argumenten er zijn, en waar dus de volgende instructie begint. Dit betekent dat je meer werk moet doen om instructies parallel uit te voeren. Om dat in dezelfde tijd klaar te spelen, moet je dus meer transistors aan het werk zetten.

Bij Arm is alles gealigned. Geen extra shifts nodig om de instructies uit het geheugen te lezen. En je kunt dus probleemloos voorspellen waar de volgende instructie begint, wat pipelining simpeler maakt. Maar er zijn ook nadelen. Op x86 kun je in 1 instructie een constante in een register laden. Op Arm kan dat niet. De typische constante-grootte is immers gelijk aan de grootte van opcode+argumenten. Dus dat laden van die constante bestaat uit minstens 2 instructies, loadhigh en loadlow, of zoiets.

[_Thanatos_]

Aha, dus als x86 ook op manier zou gaan werken, zou het compatibility breken.

[Professor_Botje]

Het grootste verschil is dat de ene een RISC en de andere een CISC processor is.
Daarom zijn ze ook eigenlijk niet te vergelijken. net zoals een Yen of een USD or Euro.
Alleen via een BigMac index is er een gevoel te krijgen van de verschillen.

Klein weetje, arm is uitgevonden door een vrouw en x86 door een man. Klinkt als een leuk huishouden.

https://en.wikipedia.org/wiki/ARM_architecture_family
https://en.wikipedia.org/wiki/X86
https://en.wikipedia.org/wiki/Big_Mac_Index

[Saven]

Het zou eens tijd worden dat Arm daadwerkelijk voeten aan de grond krijgt voor Windows en dat softwareontwikkelaars ook de moeite nemen om voor Arm te compileren. Gelukkig lijkt het erop dat de switch van Apple naar Arm een stroomversnelling heeft gecreëerd.

Het is absurd dat een moderne beestachtig-snelle Mac met een M2 chip slechts een paar Watt in idle gebruikt en vaak niet eens boven de 50 uitkomt. Zit je daar met je "Gaming PC" 700 Watt je huis warm te stoken

[_TP_]

Dit is toch geen goede vergelijking? Welke gaming pc verbruikt 700 watt? Daarnaast kan je op de zogenoemde "beestachtig" snelle Mac toch nooit dezelfde prestaties behalen in games als op de Gaming PC?

[sfranken]

Dat komt vooral door hardware ontwerp. Apple heeft de M chips niet ontworpen om goed te zijn met games, mede door een relatief zwakke GPU vergeleken met bijvoorbeeld een 7800XTX of een 4080

[1Mark]

De m1 max presteert ongeveer tussen een nvidia 1080 en 3060 in (als de game native arm/metal draait en niet met meerdere translation layers). Niet slecht, maar niet vergelijkbaar.

[Saven]

Zoals @1Mark ook aangeeft zijn de gpu prestaties best wel dik in orde. Moet je nagaan wat zo'n Arm chip op Windows kan betekenen als er ondersteuning voor DirectX inzit. Maar dan nog. Dat kleine beetje extra performance wat je nu kunt krijgen t.o.v. zo'n Arm soc kost exponentieel bizar veel extra stroom.

Dat lijkt mij voor 95% van de pc-markt compleet onnodig. Als je met 90% minder stroom slechts inlevert op de uiterste 10% van mogelijk haalbare performance lijkt me dat zelfs voor veel gamers een no-brainer.

[tim085]

Zeer positief dat zowel Nvidia als AMD hieraan simultaan werken.
Dan krijgen we naast technische concurrentie ook prijsconcurrentie, en een beter pad naar een duurzaam bestaan en brede adoptie door softwareontwikkelaars.

[skatebiker]

Ik dacht dat MS geen ARM wilde, maar wel dus.
Want ik had een Windows 11 ARM VM op de Macbook M1, die werkt prima, alleen diverse apps werken niet doordat de x86 emulatie (een soort Rosetta2 voor Windows) lang niet zo goed is als die van Apple.
Dus als ik echt Windows moet gebruiken dan maar een langzame ge-emuleerde Win11 x86.

Maar ik hoop dat MS nu doorzet naat ARM en dan geen blazende energievretende x86 laptops meer.

[rubenvb]

De enige issues die ik merk bij de x86 emulatie op Windows ARM (ook op een M1) betreft het ontbreken van AVX instructie emulatie, voor de rest werkt alles prima. Benchmarks heb ik nog niet gedraaid, dus geen idee of het veel trager is dan Rosetta2.

[Professor_Botje]

Microsoft is denk ik een van de weinige die aan de wieg hebben gestaan voor die architectuur net zoals voor:
IA-32
x86-64
ARM
ARM64
Intel i860
DEC Alpha
Itanium
MIPS
en PowerPC

Om er maar een paar te noemen
Download maar eens een iso van Windows NT4 of CE

[Alxndr]

Hoe groot is de kans dat we vroeger of later onze videokaarten in/met zulke systemen kunnen laten werken (met 100% compatibiliteit)

Als ik er over nadenk is gamen het enige wat me op x86 Windows houdt.

[Pokemoneuro]

Nu moet Microsoft nog een goed werkende versie van Windows for Arm maken om op die chips te draaien .

Even serieus, ik denk dat dit helemaal top is. Meer van dit soort hardware op de markt is goed, zeker nu dat Apple heeft bewezen dat met een beetje moeite je vrij pijnloos kan wisselen van instructieset (dit is trouwens de tweede keer dat ze dat doen, maar goed). ARM processoren gebruiken meestal minder stroom, wat geweldig is voor consumenten in laptops en dergelijke. Linux support zal hopelijk een beetje snel volgen. Misschien dat Arch Linux zelfs bedenkt om ARM toch te ondersteunen in de toekomst lol.

[Hoenens]

Zelf wel heel erg benieuwd wat er over een x aantal jaren uit zo een ARM processor kan worden gewoon wat prestaties betreft. Al helemaal nu AMD en Nvidia mee gaan doen.

[Gamebuster]

Het grootste probleem is software. We moeten ooit migreren van x86 naar arm en dan moet je alle software emuleren (performance impact) of nieuwe versie maken met arm support (potentieel heel veel werk)

[Reactie gewijzigd door Gamebuster op 22 juli 2024 20:30]

[youridv1]

Voor heel erg veel software is het zo simpel als wisselen van compiler / target. Zeer veel moderne applicaties zijn gemaakt in een of ander cross compatible framework.

[_Thanatos_]

Klopt, en het eigenlijke werk is niet het probleem. Het probleem is de ontwikkelaars zover krijgen dat ze dat ook doen. Vooral bij legacysoftware lijkt me dat lastig, maar ook bij huidige software.

En games? Hoe gaan ze dat doen? Ik ben benieuwd hoor.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 20:30]

[youridv1]

En games? Hoe gaan ze dat doen? Ik ben benieuwd hoor.

Want mobile games en console games bestaan niet ofzo? De PC gaming markt was, totdat de PS en Xbox ineens op x86 overgingen, het enige gaming platform op x86.
In de top 10 meest verkochte consoles aller tijden zit er maar 1 op x86, de PS4. De 2e, de originele xbox one, staat op de 14e plaats.

Klopt, en het eigenlijke werk is niet het probleem. Het probleem is de ontwikkelaars zover krijgen dat ze dat ook doen. Vooral bij legacysoftware lijkt me dat lastig, maar ook bij huidige software.

In het geval van pc gebruik is dat aan MS en de markt. Als microsoft massaal aan Windows ARM zou beginnen icm (surface) laptops, dan beginnen software bedrijven ook meteen.

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[_Thanatos_]

Games die ook op andere platforms bestaan, zijn cross-platform ja. Maar ik had het niet over de uitzonderingen die alleen maar ff gehercompileerd hoeven te worden. Ik had het over de rest:

1. Games die niet meer supported worden
2. Games die speciaal voor PC gemaakt zijn
3. Games van kleinere devs die de resources niet hebben
4. Games met een te kleine userbase om de kosten te rechtvaardigen

En dan heb je nog de vaak grotere onwil van gamedevs om iets van support te leveren na release, vergeleken met die van normale applicaties. Daar komt ook bij dat veruit de meeste games closed-source zijn, dus er is geen community die kan helpen bij het compatible maken. En tot slot zijn games high-performance software en hebben het meeste te lijden onder een x86-ARM vertaal-laag.

En voor alles geldt: uitzonderingen daargelaten.

[youridv1]

Games die niet worden geport zul je op een ARM pc moeten emuleren of, mocht die optie komen, zoiets als rosetta voor windows moeten gebruiken. Anders zul je een retro machine achter de hand moeten houden. Dat moet je nu ook al als je games uit het 16 bit windows tijdperk of nog ouder wil kunnen spelen. x86 is niet de eerste dekstop instructieset en we hebben al meerdere keren een sprong als deze gemaakt.

Kleinere devs zullen als hun userbase steeds verder op ARM over gaat toch een keer over moeten. De meeste kleine devs gebruiken iets als Unity of Unreal en dat maakt het makkelijker om van platform te switchen tov het van scratch schrijven van je hele game, zoals Factorio.

Dit alles wil niet zeggen dat ik denk dat we op korte termijn op ARM over gaan in de praktijk. Maar we zullen over gaan. We gaan echt niet voor altijd op x86 blijven

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[_Thanatos_]

De sprong van 16 bits naar 32 bits is veel kleiner en ook veel langer geleden. Dat kun je niet meer vergelijken. De eisen aan performance zijn veranderd.

Ik ben het met je eens dat we niet voor altijd op x86 zullen blijven, maar ik wil maar zeggen dat de overgang niet plotseling kan. Net als met andere technieken (zoals PCI naar PCIe) zal er een opvergangsfase moeten bestaan waar je beide hebt in één pc. Ik dacht dat Apple ook iets dergelijks heeft, dus de fabrikanten van ARM CPU's zouden er goed aan doen om ook x86 soepel te houden, of de moederbordfabrikanten doen er goed aan om zowel een ARM als x86 socket op moederborden te plaatsen.

Ik denk dat een retromachine achter de hand houden een duur geintje is, veel duurder dan met huidige retrogames. Want als je over bent op ARM, zonder mogelijkheid om door zonder performanceverlies x86 op te draaien, is die "retromachine" gewoon een volledige desktop met GPU en alles. Vandaar dat ik niet geloof in een plotselinge overgang - er moet een migratieperiode zijn van een paar jaar, net als bij PCI-PCIe.

[Gamebuster]

Tot je toevallig 1 dependency hebt die er niet voor gemaakt is. Dat zal vast veel voorkomen, zeker in het begin.

[youridv1]

Dan ontwikkel je die zelf en ben je daar mee de rest van de markt met diezelfde dependency een stap voor of kun je het gaan verkopen. Dat is in ieder geval hoe we bij mijn werkgever tegen dat probleem aan kijken.

[Gamebuster]

In veel gevallen niet mogelijk of realistisch, bijv. bij grote, complexe dependencies, als je een hele oude versie gebruikt (en de nieuwe versie is drastisch anders en migreren is niet makkelijk), of als je simpelweg geen broncode hebt, of geen licentie om deze aan te passen.

Moraal van het verhaal is dat het sowieso niet "even compiler instellingen aanpassen" is. Natuurlijk is overal een oplossing voor, maar de realiteit is dat er in veel gevallen geen budget is voor die oplossingen.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 20:30]

[youridv1]

Moraal van het verhaal is dat het sowieso niet "even compiler instellingen aanpassen" is.

Niet mee eens. Dat is niet altijd zo, maar in een heel groot deel van de gevallen wel. Die "complexe, grote dependencies" waar jij het over hebt gelden alleen voor grote complexe applicaties. Dan heb je ook direct de mankracht, of er klopt geen reet van je programmeurs/codebase verhouding.

De meeste bedrijven die maar een klein dev team hebben, leveren ook geen supercomplex software pakket.

Als je niet op de x86 -> ARM verandering kunt reageren, dan is het maar de vraag waar je als software boer uberhaupt wel op kunt reageren.
Hardware fabrikanten hebben voor Vista+ ook al hun drivers moeten omtikken, bijvoorbeeld.

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[Gamebuster]

Die "complexe, grote dependencies" waar jij het over hebt gelden alleen voor grote complexe applicaties.

De grootte van een applicatie en wat voor dependencies eraan hangen zijn wmb 2 losstaande zaken. Je kan prima een grote complexe app hebben met weinig dependencies, of een hele simpele app met veel grote dependencies.

Als je niet op de x86 -> ARM verandering kunt reageren, dan is het maar de vraag waar je als software boer uberhaupt wel op kunt reageren.

Heb je geen projecten die al 10+ jaar oud zijn? Misschien dat je nu rekening mee houdt, maar 10 jaar terug? Verder kan je er prima op reageren; dat is de hele stelling niet. De stelling is dat je met wat triviale compiler-wijzigingen de migratie kan maken. Mijn reactie is dat dat niet waar is. Dat betekent niet dat de ontwikkelaars van die software incompetent zijn o.i.d.; waarom zou je voorbereidingen treffen voor ARM als er 0 gebruikers zijn met ARM systemen? Lijkt me verspilde moeite. We horen al jaren dat ARM de toekomst is, en ondertussen zijn alle windows PCs nog steeds x68 en weten we helemaal niet hoe een toekomstige migratie naar ARM gaat lopen.

Verder gaan we het denk ik gewoon niet eens worden. Dat is prima, niets mis mee. Fijne dag verder, hah.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 20:30]

[youridv1]

Heb je geen projecten die al 10+ jaar oud zijn?

Jawel, 26 jaar oud zelfs. Een 16 bit DOS applicatie in basic die nog steeds bestaat, maar nu in C++ en Windows 10/11

Verder gaan we het denk ik gewoon niet eens worden. Dat is prima, niets mis mee. Fijne dag verder, hah.

Nee, denk ik ook niet. En eens, niets mis mee.

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[_Thanatos_]

Ik ben het wel met Gamebuster eens. Het is niet zo makkelijk als jij schetst. Er zijn 5 situaties:

1. Je hebt alles zelf geschreven en je kunt (dus) alles zelf hercompileren met hier en daar wat aanpassingen.
2. Je hebt externe dependencies waar je wel broncode van hebt, maar die heb je niet zelf in onderhoud. Je mag wel aanpassen, maar je ben dan verplicht die aanpassing eerst door de auteur goed te laten keuren.
3. Je hebt externe dependencies waar je wel broncode van hebt, maar die mag je niet aanpassen. Die heb je dus alleen voor naslag.
4. Je hebt externe dependencies waar je geen broncode van hebt, waardoor je bent overgeleverd aan de makers ervan wanneer ze nieuwe binary blobs uitgeven.
5. Je hebt externe dependencies waar je geen broncode van hebt, en waarvan de makers niet meer bestaan of actief zijn.

En alles ertussenin heb je ook.

En voor de snelheid waarmee softwareboeren reageren op nieuwe instructiesets hoef je maar te kijken hoe lang de transitie van x86 naar x86_64 heeft geduurd. En daarmee bedoel de adoptie in de mainstream-markt (ik weet zelf ook wel dat nog steeds niet alles 64 bits is).

[SuperDre]

Klopt, maar het probleem is niet die nieuwe software, het probleem is reeds bestaande software. Hoop van die software is niet gemaakt in ontwikkelomgevingen die crossplatform zijn. Dus als het nieuwe systeem niet ook die oude software kan draaien, in emulatiemodus, dan zijn er genoeg bedrijven die niet over zullen stappen. Voordeel natuurlijk wel is dat veel van die software al op oudere trage hardware was uitgebracht, dus nieuwe snelle hardware met emulatie zal naar allerwaarschijnlijkheid dan nog steeds sneller aanvoelen dat de software door blijven draaien op de oudere hardware.

[youridv1]

Als Windows overstapt op ARM als hoofdmoot gaan alle bedrijven direct over. Dan gebruikt in 1 klap bijna niemand hun software meer. Dan kunnen ze kiezen tussen native linux om op x86 te blijven, of native Windows Arm ondersteunen. Dat wordt natuurlijk het tweede.

Je hebt immers geen keuze op een gegeven moment als bedrijf. Microsoft zal ooit overstappen naar een nieuwe instructieset voor Windows en dan zal iedereen mee moeten zodra de laatste x86 versie EOL gaat.

[Reactie gewijzigd door youridv1 op 22 juli 2024 20:30]

[SuperDre]

Windows op ARM heeft gelukkig al emulatie waardoor legacy applicaties die onder windows 10 draaien ook draaien op Windows voor ARM. Microsoft is op dat gebied best goed in het ondersteunen van legacy applicaties, maar dat komt natuurlijk omdat hun een veel grotere markt met legacy applicaties te ondersteunen hebben in tegenstelling tot een Apple die op dat gebied echt maar een miniscuul deel van de markt had welke ook nog weinig gespecialiseerde applicaties hadden, meeste werd gebruikt voor multimedia of office applicaties welke sowieso al fatsoenlijke crossplatform had.

[readefries]

Niet perse, als je ziet hoe Apple dat kan...

[Gamebuster]

Apple doet exact wat ik omschrijf.

[ronaldmathies]

Apple bied enorm veel ondersteuning in zowel tooling als documentatie als platform waardoor de overgang vrij soepel ging. Inmiddels is zoveel software native ARM op Apple, dit ging vanaf het begin al enorm snel. Toen ik mijn M1 kocht kon ik praktisch alles al native draaien apple Whatsapp na.

Dit was altijd het heikel punt bij Microsoft, ze hadden wel de hardware maar de ondersteuning, tooling en platform was naar mijn idee niet goed aanwezig waardoor veel ontwikkelaars het lieten afweten. En dan krijg je een kip/ei probleem, als het teveel moeite en geld kost om het om te zetten terwijl er niemand nog op werkt gaat niemand het omzetten, maar als niemand het gaat omzetten krijg je ook geen gebruikers want waarom ARM platform kopen als het niet goed door software wordt ondersteund.

[RetroHead]

Werk al sinds december 2020 op een macbook air m1 op ARM. Ze hebben Rosetta 2 gebruikt om alle software die niet geoptimaliseerd was te kunnen draaien. Performance impact daarvan was echt nihil. ik zou zeggen dat er voor 90% van de gebruikers geen issue is om naar ARM over te stappen. Alle office applicaties draaien er al op op MacOS, enkel nog op windows dient er meer werk te worden verricht qua software.

Zodra dit mainstream wordt zullen developers volgen. Gebruikers krijgen er een forse verbetering voor terug op batterijduur en stroomverbruik (word ook steeds duurder). Qua IPC waarde zitten de M1 en M2 processors ook supergoed, dus ik zie niet in waarom dit een probleem moet zijn.

[Gamebuster]

Dat is toch wat ik zeg? Emuleren (Rosetta) of nieuwe versies uitbrengen. Rosetta is niet "niet geoptimaliseerd". Rosetta is gewoon een emulator. Een goede emulator, maar het is een emulator. Rosetta heeft ongeveer 60-80% van de performance van native code. Dat is best een significante impact. Je merkt het gewoon niet heel erg op macbooks omdat de M1 chips simpelweg veel sneller waren dan de intel voorgangers, dus zelfs met performance verlies voelde je software sneller. Het verschil tussen de intel macbook air en m1 macbook air was al helemaal gigantisch, maar zover ik weet was de M1 zelfs sneller dan de snelste intel chips die je kon krijgen destijds.

Natuurlijk zitten we inmiddels in andere tijden en het verschil tussen de M-chips en AMD/Intel chips is al weer een stuk kleiner.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 20:30]

[Patriot]

Ik denk dat mensen zo reageren omdat je zegt dat software nog steeds een groot probleem is, terwijl Apple heeft aangetoond dat het ondanks de performance impact min of meer net zo snel kan zijn (en de machine ondanks emulatie zuiniger dan x86).

Waar daadwerkelijk problemen zitten is legacy software die nog steeds heel erg belangrijk zijn maar om wat voor reden dan ook niet te emuleren zijn. Tegelijkertijd kun je je afvragen hoe groot dat probleem in de praktijk echt is want blijkbaar kan het nu ook gewoon toe om een computertje uit het jaar kruik met daarop een onveilig en niet langer ondersteund OS te gebruiken voor deze doeleinden.

[Jay-v]

Zo'n groot probleem hoeft dat niet te zijn. Op MacOS en Linux doen gebeurt dit immers al. Emulatie kan ook prima voor een groot deel van de software.

Op de Windows Desktop/Laptop markt wordt er geen/weinig aandacht aan besteed omdat de markt er niet is Kip/Ei verhaal. .NET 6 and .NET 7 al eenvoudig te compileren voor ARM64 (Windows en Linux) .

NVidia wil graag een gehele oplossing bieden. Steam Deck doet het best aardig op Linux (wel x64). In de Cloud worden meer en meer apps naar ARM based servers verplaatst. Zelfs Microsoft maakt zijn software stack meer en meer beschikbaar op Linux en ARM (.NET, SQL server, etc).

Als CEO van Intel zou ik me serieus zorgen maken.

[Reactie gewijzigd door Jay-v op 22 juli 2024 20:30]

[Cergorach]

Zelf wel heel erg benieuwd wat er over een x aantal jaren uit zo een ARM processor kan worden gewoon wat prestaties betreft.

Je hoeft niet jaren te wachten, kijk wat Apple al jaren aan het doen is met hun eigen silicon en uiteindelijk de M1/M2.

[Hoenens]

Ik heb niks met Apple en vind het maar een k*t merk. En ik zeg ja ook: ik ben benieuwd wat over een x aantal jaren eruit komt wat prestaties betreft.

[elmuerte]

nVidia maakt al 15+ jaar ARM processors.

[d3x]

AMD heeft in elke epic server CPU een arm core zitten voor de beveiliging en K12 was een clone van de x86 Epic architectuur waar de IO die identiek was en de chiplets op basis van ARM.

beide zijn dus in staat om iets af te leveren als de vraag er is. Ook heeft AMD een samenwerking met Samsung voor de mobile GPU. Dus op zich heeft ook AMD alles in het schap liggen.

Ik had dit eigenlijk vna dag 1 verwacht van een chromebook, maar ik vermoed dat Intel een goeie deal gemaakt heeft met google, want het was weer zo een fixed platform, typische buy-in.

[Reactie gewijzigd door d3x op 22 juli 2024 20:30]

[sfranken]

Een van de eerste Chromebooks die redelijk populair was was juist een ARM model, de Samsung series 3, ook wel liefkozend de sarmsung genoemd.

[Hoenens]

ik zeg ja ook: ik ben benieuwd wat over een x aantal jaren eruit komt wat prestaties betreft.

[Jan Onderwater]

Ben benieuwd, hoe meer concurrentie,hoe meer innovatie, altijd goed. Gaan we eindelijk afscheid nemen van x86 in de komende jaren?

[jmsaow]

Misschien willen deze fabrikanten zichzelf beschermen tegen de Chinese ontwikkeling van allerlei nieuwe technologie waar geen Amerikaanse sancties meer op kunnen worden toegepast. Die staan echt niet stil.