Door Luke van Drie en Tomas Hochstenbach

Feedback • 14-11-2026 16:00 74

Explainer: Is Arm echt beter dan x86?

14-11-2026 • 16:00

Koop je straks een nieuwe laptop, dan moet je kiezen tussen twee totaal verschillende processors: x86 of Arm. Kies je de verkeerde? Dan kan het zomaar zijn dat je favoriete programma's of games niet meer goed werken.

In deze video leggen we precies uit wat het verschil is tussen Arm en x86, waar die architecturen vandaan komen, hoe ze werken en wat het voor jou als consument betekent bij het kopen van een laptop.

Lees hier het geschreven artikel.

00:00 Explainer: Is Arm echt beter dan x86?
00:45 X86 legacy en Arm op pc
01:37 Arm-licenties
02:26 Energie en instructies
03:14 Efficiëntie vergeleken
03:59 Wat kies jij?
04:46 Conclusie

Vorige video

Lees meer

Premiumprijs, smartphonesoftware - Acer Googlebook 14

Premiumprijs, smartphonesoftware - Acer Googlebook 14 Video van 11 november 2026

Lokale AI-modellen draaien: Apple vs. Nvidia vs. AMD

Lokale AI-modellen draaien: Apple vs. Nvidia vs. AMD Video van 6 november 2026

Dit is hoe goed het Proled-scherm van de MacBook Pro is

Dit is hoe goed het Proled-scherm van de MacBook Pro is Video van 5 november 2026

Een moderne klassieker - The Legend of Zelda: Ocarina of Time Remake

Een moderne klassieker - The Legend of Zelda: Ocarina of Time Remake Video van 4 november 2026

IJzersterke eerste generatie - Apple iPhone Duo

IJzersterke eerste generatie - Apple iPhone Duo Video van 31 oktober 2026

Een MacBook met touchscreen en oledscherm - Tweakers Update

Een MacBook met touchscreen en oledscherm - Tweakers Update Video van 29 oktober 2026

Vijf dingen die je moet weten voor je een thuisbatterij koopt

Vijf dingen die je moet weten voor je een thuisbatterij koopt Video van 24 oktober 2026

Meer producten en artikelen

Processors Arm Cpu's X86

Reacties (74)

74

73

31

3

0

29

Wijzig sortering

cdwave 14 november 2026 20:18

Er wordt wel heel makkelijk over de architecturen heen geveegd. Ja, een ARM computer kan prima number-crunchen en spelletjes draaien en dat soort dingen doen. Waar hij stukken minder op scoort is het verwerken van "tekst", zoals de taak van het compileren van code. Het verschil is dan gigantisch groot. Geen echt probleem voor kleine programma's, maar als je bijvoorbeeld de Linux kernel gaat compileren dan worden minuten ineens uren...

Ook het platform verschilt nogal. In de x86 architectuur is altijd alles "coherent", dus als je NVME iets opgelepeld heeft en in RAM gezet dan kan de CPU (of GPU) er zonder verdere huishoudelijke taken meteen bij, en de data kan direct in de CPU cache worden geplaatst, gekopieerd of eruit gelezen worden. Op de ARM platform is dat meestal niet zo, want zo'n coherent systeem eist nogal wat van de hardware, met name de interconnect is heel erg complex. De simpelste ARM machines hebben gewoon "niks", wat wil zeggen dat als een device iets in RAM heeft gezet, de CPU zijn cache moet leeggooien en de nieuwe data maar uit de trage DDR chips moet gaan scheppen. De ARM kan wel slimmere interconnects hebben, maar dat komt met een fikse prijs in energieconsumptie.

Veel van het verschil in energiegebruik zit dan ook niet in de CPU, maar in alles wat er omheen zit. Maar daar komt ook een groot deel van de performance vandaan.

Wolfos @cdwave • 14 november 2026 20:30

Waar hij stukken minder op scoort is het verwerken van "tekst", zoals de taak van het compileren van code.

Even getest met een Apple M3 Max en een Ryzen 9 5950X. Beiden met 16 cores, op hetzelfde .NET project na een clean.

Apple: 5.7s
Ryzen: 13.9s

Nou is de Apple een paar jaar nieuwer, maar dus ruim twee keer zo snel hier.

Prince @Wolfos • 14 november 2026 20:46

De M3 is dan ook niet zomaar een ARM chip. Dit is een SoC.
Je vergelijkt hier een moderne SoC architectuur met een oude chiplet architectuur.

De SoC heeft een veel grotere geheugenbandbreedte. Dit is ook waarom AI modellen op die unified memory zo snel draaien. Dit is bij dual channel DDR4 pakweg 50GB/s en bij de M3 eerder in de richting van 400GB/s.

De M3 is een monolithic chip, de AMD heeft 2 CCD's. De M3 op 3nm is ook veel nieuwer dan de Zen 3 op 7nm en de M3 heeft dus een hogere IPC.

Vroeger was het waar dar ARM trager was, maar Apple heeft dit opgelost met beesten van instruction decoders. Zo hard dat deze rondjes lopen rond die oude Ryzen.

Maar bedenk ook dat de storage controller bij de SoC integrated is, maar bij de Ryzen niet. Ik vermoed bij nvme op de north bridge? geen idee eigenlijk..., maar bij een SoC heb je dus ook lagere I/O latency.

Dit heeft te maken met chip design, niet chip architectuur.

vinkjb 14 november 2026 16:56

Goeie uitleg, maar naast X86 is er toch ook X64, of ben ik helemaal de weg kwijt. Of moet ik het gewoon zien van uitbreiding instructieset en mogelijkheden van je pc.

[Reactie gewijzigd door vinkjb op 14 november 2026 16:58]

voxilla @vinkjb • 14 november 2026 18:17

x86 verwijst naar de 32 bit architectuur
Later werd x64 voor 64 bit toegevoegd (door AMD en in licentie genomen door Intel)

raymondw @vinkjb • 14 november 2026 17:05

Het is x86-64, eerste ontwikkeling door AMD.
Echt x86 word niet echt meer gebruikt.
Leuk artikel uit het verleden:
review: Intel Itanium sneak preview

vinkjb @raymondw • 14 november 2026 17:12

Dank u ik ga er vanavond ff naar kijken, dit ook omdat je bijv met download uiteraard de X64 moet hebben, maar soms staat de X86 er ook nog.

84hannes @vinkjb • 14 november 2026 23:27

Ik snap je verwarring, x64 is echt een heel beroerde afkorting van x86-64. Daarbij waren de eerste x86 systemen (8086 en 80297) 16-bits, dus alles vanaf de 386 t/m 586(?) zouden we met x86-32 ofzo moeten aanduiden.

sworpie @raymondw • 14 november 2026 18:02

..Waarom is dat artikel in het Engels?

Cergorach @sworpie • 14 november 2026 18:47

Tweakers.net probeerde in 2001 een internationaler publiek aan te spreken met dit soort artikelen.

raymondw @Cergorach • 14 november 2026 22:27

Tweakers werd geSlashdot door de review. Het NL artikel is in het Engels vertaald later, ik kon de NL versie niet 1-2-3 vinden.
Het geeft wat meer inzicht in architectuur.

Floris4970 @raymondw • 14 november 2026 17:14

Wij gebruiken dit nog steeds.. niet heel handig maar draait stabiel

ronaldvd_nl @raymondw • 14 november 2026 18:21

Voor de volledigheid: de Itanium heeft hier eigenlijk niets mee te maken: het is een eigen architectuur en instructieset (IA-64), dit is dus geen x86 en ook geen x86-64 (en ook geen x64).

sspiff @raymondw • 14 november 2026 23:28

Dat artikel gaat over Itanium, Intels gefaalde poging om een nieuwe 64-bit instructieset los van x86 te ontwikkelen. Heeft nog een tijd voor grote mainframe stijl server met HP-UX als operating system meegelopen maar is nooit een groot succes geweest.

AMD had destijds dan met de Athlon64 een uitbereiding voor de x86 gemaakt voor 64-bit instructies en registers onder de noemer amd64. Dat vond wel een markt bij de grote massa, en werd door Intel overgenomen als x86-64. Dat is de instructieset die we nu nog steeds gebruiken en de nieuwste Intel en AMD processors.

raymondw @sspiff • 15 november 2026 00:25

Klopt helemaal, IA-64 kwam niet van de grond door de langzame x86 code werking.
Wij hadden destijds zakelijk beide staan en privé had ik een Athlon x86-64, het was voor mij snel duidelijk welke kant het op zou gaan. Heb nog steeds ergens een XP CD met 64-bit ondersteuning liggen.
Alleen al de "BIOS" van een IA-64 server had een LS120 drive nodig.
Het was zijn tijd misschien (te) ver vooruit.

Misschien voor velen een brug te ver, maar de Windows installatie folder heet nog altijd AMD64

Voor mijn eigen projecten gebruik ik al sinds 2015 ARM, dat het nu mainstream word voor normale desktop taken vind ik prima.
Op naar de volgende stap!

oef! @vinkjb • 14 november 2026 17:03

Beiden beschrijven een instructieset en alle x64 cpu's zijn compatible met x86. De termen zijn over het algemeen uitwisselbaar.

vinkjb @oef! • 14 november 2026 17:11

dank u

@vinkjb • 14 november 2026 20:13

Er zijn 2 smaken voor 64 bits instructies, de IA-64 die in de itanium lijn van Intel zat, en de AMD64 (of x86-64) van AMD.

Intel gebruikt voor eigenlijk alle 64 bits chips de AMD versie, en dit is dan ook onderdeel van de patentenuitwisseling.

Hierbij is x86 de familie, en x86-64 de instructieset. (Naast de x86-32 en de x86-16 welke de instructie sets waren voor de 32 bits en 16 bits versies uit de x86 lijn, deze zijn onderdeel van de grotere set via legacy support)

voor de 16-bit versie moet je wel in de 16 bit modus zijn volgens mij.

rjmno1 @vinkjb • 14 november 2026 19:16

Nee x 86 is de instructieset en ja hij is nu sinds een paar jaar x64 geworden oftewel 64 bits breedt.

Dan rijs de vraag waar je voor zou moeten kiezen wel daar zijn de meningen nog niet over verdeelt wil je echt solide aan de bak gaan en is compatibiliteit de hoofdmoot dan zou je voor x 86 moeten kiezen.Ga je meer voor puur rekenkracht en compatlebaliteit van de telefoon dan zou je voor arm kiezen , maar arm is nog niet zolang op de markt en is eigenlijk een new kid on the block, En heeft hardwarematig nog niet zoveel ervaringen in het programmeren en uitvoeren van sommige stukjes hardware Het is aan jouw de keuze waar je voor kiest kijk maar naar apple wat het uiteindelijk geworden is!

[Reactie gewijzigd door rjmno1 op 14 november 2026 19:17]

Rocca 14 november 2026 16:23

In de praktijk merk je toch wel de voordelen van Arm. De laptop blijft veel koeler en heeft vaak geen fan nodig. Geen geloei meer.

_Dune_ Moderator OeB

@Rocca • 14 november 2026 18:30

De laatste 4 X86 laptops heb ik geen problemen met te veel geluid van ventilatoren gehad, dat is een tijdspanne van een jaar of 10-12, misschien beter uitkijken met wat je koopt of zorg ervoor dat er geen stof in komt.

Type laptop Max 14” en mid-high performance.

[Reactie gewijzigd door _Dune_ op 14 november 2026 18:31]

Cergorach @_Dune_ • 14 november 2026 19:05

Als we momenteel Apple ARM hardware zetten tegenover x86 hardware van Intel OF AMD dan merk je dat de Apple ARM hardware veel efficiënter is voor de performance die het levert.

Ik ben in 2020 gaan kijken naar efficiënte x86 hardware (een overstap naar MacOS was op dat moment nog niet realistisch voor mij). Ik kwam toen uit op de 4800U van AMD, bijzonder efficiënt! Het had een heel laag idle verbruik. Echter als ik daarna ging kijken naar elke daarop volgende generatie van AMD (en Intel) zag ik twee dingen gebeuren: Ze werden sneller, maar verbruikte meer stroom, Als je het extra stroom verbruik compenseerde was de verbetering van elke generatie miniem! En een hoop mensen zouden zeggen, maar het wordt efficiënter! Ja, in theorie, maar de 'sweetspot' verplaatste zich ook. Idle verbruik werd dus ook constant meer en regelmatig niet insignificant.

Ik gebruik een 2 jaar oude M4 Pro (Mac Mini) welke minder dan 10W verbruikt terwijl ik dit type (dus iets meer dan idle) en dat is inclusief een verlicht toetsenbord en muis. Dat haalt zelfs m'n 4800u niet! Voor iets dat 100+ uur per week aanstaat is dat significant over een periode van 5 jaar. Nog maar niet te spreken over de hoeveelheid warmte het produceert tov. het equivalent in de x86 ruimte.

Natuurlijk is niet alle ARM hardware even goed. Die van Apple steekt er met kop en schouders bovenuit. Een Raspberry Pi 4/5 is een heel stuk minder goed, maar omdat die in den beginnen al veel minder krachtig is dan een moderne x86 CPU verbruikt deze gewoon enorm weinig, als we dan gaan kijken naar een Raspberry Zero 2 is dat nog minder verbruik, maar nog minder krachtig (maar krachtig genoeg om er een hoop mee te kunnen doen!).

Wellicht dat x86 meer efficient zou kunnen zijn, alleen zijn AMD en Intel daar al heel lang niet mee bezig. Hun jaarlijkse refresh was zo miniem sneller dat ze er voor kozen om er gewoon meer stroom tegenaan te gooien. Vandaar dat we nu met zulke achterlijke space heaters van x86 machines zitten. AMD en Nvidia deden hetzelfde met de GPUs en zelfs de SSD producenten deden hetzelfde met elke snellere generatie SSDs (nu zelfs zo erg dat in sommige gevallen een grote heatsink niet meer genoeg is)...

@Cergorach • 14 november 2026 20:10

Maar zoals je al zegt... Dat is Apple. Het is een fout die veel mensen maken, ze wijzen naar Apple en zeggen dan 'kijk hoe goed arm is!'

Maar je kunt geen Windows laptop met Apple silicon krijgen... Dus hoe goed Apple is doet niet meer ter zake als je geen Apple os wil draaien. Van de hardware die wel beschikbaar is voor Windows is het volgens mij zo dat de arm versies vooral erg efficiënt zijn in niks doen. In idle gaat de accu lekker lang mee. Maar zet je ze aan het werk dan scheelt het weinig meer.

Voor gaming hoor je vaak de roep online om arm te gebruiken, maar dat is nou net een toepassing waarbij het systeem erg weinig in idle staat en je dus weinig overhoudt van die efficiëntie. Voor desktop gebruik kan het wel meer impact hebben want dan staat het systeem vaak gewoon uit zijn neus te eten.

@Cergorach • 14 november 2026 21:53

In 2020 had je misschien gelijk. 2 jaar geleden had Intel ondertussen een behoorlijke inhaalslag gemaakt met de 12e en 13e generatie cores. Mijn core i7 13e generatie desktop systeem komt niet veel verder dan 15W idle.

Apple heeft ook daar de race ondertussen alweer verloren. Intel heeft ze aardig ingehaald op zowel performance per watt als idle verbruik. Ze zitten tegenwoordig heel dicht bij elkaar. En AMD heeft ze bijgehaald als het gaat over locale AI performance waar Intel in de volgende generatie ook weer een slag maakt.

Al met al ontlopen ze elkaar ondertussen weer heel weinig.

gj_dejong @Rocca • 14 november 2026 18:32

Dit is te generaliserend; zware belasting zorgt ook bij ARM voor hitte.

juanita 14 november 2026 16:30

Toch werd in het verleden wanneer energieverbruik en warmteafgifte belangrijke criteria waren structureel voor ARM gekozen. Zagen ontwerpers dat toen verkeerd?

Kaler @juanita • 14 november 2026 17:31

Het is in het verleden wel vaker voorgekomen dat er vergelijkbare technieken zijn en dan omdat een bepaalde (grote) partij afspraken maakt en voor de ene gaat, omdat dat technisch de ander beter blijkt te zijn.

Windows 'koos' x86 omdat Intel (en AMD) de PC markt domineerde. Windows support voor ARM op de PC/notebook, kwam pas toen Windows al circa 20 jaar bestond. Hierdoor is alles en iedereen het x86 platform als primair gaan beschouwen voor software ontwikkeling.

de PS3 is is ook een mooi voorbeeld, er werd voor het eerst van x86 afgeweken de gebruikte architectuur resulteerde in moeilijkere software ontwikkeling en slechtere verkoopcijfers.

Kortom, marktaandeel speelt een belangrijke rol in zaken als deze.

Andere voorbeelden: Betamax vs VHS, Blu-ray vs HD DVD

[Reactie gewijzigd door Kaler op 14 november 2026 17:51]

Nieuwevolger @Kaler • 14 november 2026 17:38

Het gedeelte over de ps3 klopt niet helemaal. Nintendo en Sony maakte altijd cpu’s met een PowerPC of Risc architectuur. De psp ondanks dat het een portable was had ook geen arm architectuur maar ook Risc.

Kaler @Nieuwevolger • 14 november 2026 17:50

Je hebt gelijk!

De reden klopt wel waarom er gekozen is voor x86 bij de PS4 en PS5.

RoestVrijStaal @Nieuwevolger • 14 november 2026 18:11

De psp ondanks dat het een portable was had ook geen arm architectuur maar ook Risc.

Dat was dus de MIPS architectuur.

CPU's met die architectuur zat trouwens ook in de Nintendo 64, PlayStation 1 en 2, en voor backwards compability ook in de eerste generatie PlayStation 3.

Een aantal decennia heeft MIPS op het gebied van embedded devices (routers e.d.) door dezelfde manier van architectuur licenceren flink geconcurreerd met ARM. ARM heeft gewonnen.

Daardoor heeft het moederbedrijf MIPS Technologies de archtectuur de nek omgedraaid en is verder gegaan met RISC-V.

Nieuwevolger @RoestVrijStaal • 14 november 2026 18:29

Voorheen speelde cpu’s in verhouding op de gpu ook een veel grotere rol in de console. Meestal was de size van cpu en gpu ongeveer ever groot. Tegenwoordig zijn de gpu’s gigantisch geworden en is de aandacht in een console ook veel meer op de gpu gelegd.

Zo werd er ook gezegd dat cpu van de ps3 eigenlijk niet onderdeed van de cpu van de ps4 op bepaalde manieren.

voxilla @Nieuwevolger • 14 november 2026 18:20

De switch 1 en 2 gebruiken trouwens ARM

bzzzt @Kaler • 14 november 2026 19:33

Windows 'koos' x86 omdat Intel (en AMD) de PC markt domineerde.

De PC markt was al x86 omdat MS-DOS daarop draaide. Hardware abstractie was in die tijd matig en emulatie kostte teveel performance dus er was niet zoveel keus behalve doorgaan met x86.

Windows support voor ARM op de PC/notebook, kwam pas toen Windows al circa 20 jaar bestond. Hierdoor is alles en iedereen het x86 platform als primair gaan beschouwen voor software ontwikkeling.

Windows NT 4 kwam 11 jaar na Windows 1.0 uit voor Intel, PowerPC, MIPS en Alpha architectuur. Het enige probleem was dat machines met die alternatieve architecturen relatief duur waren en alleen voor specifieke niche workloads sneller. Er waren dus wel alternatieven, en een aantal jaar later ging iedereen wel mee met de transitie naar x64.

Voor veruit de meeste software ontwikkelaars, zeker degenen die met high level talen werken is een architectuurverschil eigenlijk helemaal niet zo spannend.

tedades @bzzzt • 14 november 2026 21:55

Dit is waarom ik denk waarom x86 op het moment nog redelijk dominant is:

Het idee van Wintel was dat een systeem met Windows en een Intel CPU veel goedkoper was dan een Sun systeem met een Sparc CPU. Voor veel kleinere bedrijven was die veel lagere prijs, en de combinatie van goedkopere admins (MCSE), een reden om over te stappen. En met Active Directory werd die positie nog steviger. Door die extra verkopen had Intel veel geld om hun CPU's sneller te maken, want de competitie was sneller dan bijvoorbeeld hun 486. IBM kwam 10 jaar daarvoor al op de desktop markt met hun 8088 (een goedkopere 8bit bus variant van de 8086 -> de eerste x86). Omdat de meeste zakelijke software voor de pc werd geschreven is die combinatie volgens mij waarom x86 toen dominant is gebleven voor Windows (veel applicaties draaide al op x86 en niet op MIPS/PowerPC/etc). Compaq heeft toen een clean-room (of zelfs verbeterde) variant gemaakt van hun BIOS waardoor ze hun eigen IBM-compatible desktop PC konden leveren met MS-DOS erop. Die competitie zorgde voor veel lagere prijzen waardoor die markt ontplofte.

specs2021 @bzzzt • 14 november 2026 23:12

Ze waren duur omdat de aantallen kleiner waren. En de pc markt zat op slot want de oude software moest ook werken. Ik heb het nooit geprobeerd, maar volgens mij moet een i7 nog gewoon MsDos kunnen starten met Windows 3.1.

De pentium pro was echt een jack of all trades. Zo kon je er een ei op bakken.

Daarbij moet je nog opmerken dat wat we nu x86_64 noemen geen zuivere CISC meer is. De instructieset is CISC, maar die wordt intern omgezet naar micro-ops, simpelgezegd lijkt het intern op RISC. CISC is al vanaf de P6 (de Pentium Pro) op de retour, dus ruim voor de Itanium. En de Itanium werd slachtoffer van de bovengenoemde valkuil: het kon geen x86-32 software draaien, dus werken we nu allemaal met de x86-64 instructieset van AMD.

m_snel @Kaler • 14 november 2026 18:56

Je had ook Windows voor de powerpc en Dec alpha , mips en o.a.-64.

Alleen waren die niet zo populair .

voxilla @juanita • 14 november 2026 18:19

Nee ze zagen het niet verkeerd. Daarom zit er in geen enkele smartphone (meer) x86 en enkel ARM

Wolfos 14 november 2026 16:39

Die emulatielaag op Windows lijkt me niks. Niet omdat het niet goed werkt, maar omdat er veel minder ARM ondersteuning is dan op Macs en ik vermoed dat dat hier langer gaat duren.

Zo ondersteunt Steam jaren na introductie nog altijd geen ARM builds op Windows. Ontwikkelaars krijgen geen optie om hun game zo aan te leveren. Je zit dus altijd met de emulator die in sommige situaties erg traag kan zijn.

PureTryOut @Wolfos • 14 november 2026 17:01

Steam op Linux heeft tegenwoordig wel een native ARM build trouwens, en het bevat ook wat software om x86_64 games te kunnen draaien. Over de tijd zullen er steeds meer native ARM games bij komen, en al helemaal voor VR.

14 november 2026 16:50

Hoewel de meeste programmeurs in hogere programmeertaal met compilers zullen programmeren, vraag ik mij af hoe ARM in assembler zich verhoudt tot x86 in assembler. Zijn er echte bare-metal programmeurs hier, die hier iets over hebben te melden?

fastedje @JSBach • 14 november 2026 19:07

Ik heb jaren geleden wel 32 bits assembly voor ARM geschreven. Wat toen opviel is dat de instructieset zeer gestructureerd is en heel fijn is om mee te werken. Bij de meeste instrucites kan je b.v. twee input registers opgeven en een output register voor het resultaat..Verder hebben bijna alle instructies conditionele uitvoering: afhankelijk van de vorige instructie kan je een instructie wel of niet laten uitvoeren. Het voordeel daarvan is dat je niet altijd twee extra instructies voor het controleren van de status èn een srpomginstructie nodig hebt. Dit is zeker niet bij alle RISC instructiesets zo. Een ander opvallend iets is het concept dat je relocateble code kan schrijven door adressen relatief uit te rekeken door b.v. een spronginstrucite het huidige adres + of - een aantal 32 bits adres te laten verspringen. Je kan dan code pp verschillende geheugen adressen laten draaien.

Ondertussen zijn er veel instructies bij gekomen voor 64 bits en vector operaties, daar lan ik noet zoveel over zeggen.

gj_dejong @JSBach • 14 november 2026 18:33

Bare metal programmeurs werken al 30 jaar niet meer in assembler.

m_snel @gj_dejong • 14 november 2026 18:47

Dat begrijp ik wel, in de jaren negentig wel eens mee begonnen maar als je dan een uitkomst had en die op het scherm wilde zetten kon je weer uren aan de slag.

BvdW1978 @JSBach • 14 november 2026 19:31

Er zit nogal wat verschil tussen die architecturen. De assembler zelf kan daar tot op zekere hoogte nog een beetje overheen proberen te abstraheren, maar je komt het in de programmeertechniek toch weer tegen. Een 'mov' instructie in Assembler kan er op x86-64 en ARM hetzelfde uitzien, maar zal uiteindelijk op de CPU naar een andere reeks bytes worden vertaald. Je ontkomt er ook niet aan dat de registers anders heten, dus in de praktijk zie je het verschil meteen.

Een instructie op 64-bit ARM vertaalt zich altijd tot een reeks van 4 bytes richting de CPU, niet langer en niet korter. Op x86-64 is dat dynamisch en kan tussen de 1 en 15 bytes liggen. ARM is bovendien heel strikt load/store dus er wordt alleen gerekend op de registers, terwijl x86-64 direct met waardes uit het RAM kan rekenen (ze worden wel nog steeds gewoon opgehaald en teruggeschreven). ARM maakt dat dan weer goed met een veel groter aantal registers, waardoor het minder vaak waardes van/naar RAM hoeft te schuiven.

Ik heb overigens niet veel ervaring met het schrijven voor deze CPU's. Mijn Assembler-dagen begonnen met de MOS 6510 en eindigden met de Motorola 68000. Conceptueel gebeurt er nog steeds hetzelfde. Allemaal Von Neumann architectuur in de kern: fetch, decode, execute.

Wil je eens echt heel wild iets anders zien, dan zijn er in de oude mainframe-wereld leuke architecturen zoals die van Burroughs B5500 uit de jaren '60. Helemaal geen registers voor de programmeur, geen assembler, hardware-gebaseerde geheugenbescherming (geen buffer overflows). Je komt dit kunstje vandaag nog tegen in JVM en WASM, maar ik dwaal af.

PWM 14 november 2026 16:59

Ik gebruik nu sinds kort een Surface met de nieuwse Snapdragon chip. Ik kan niet anders dan vol lof zijn.

De batterij is tijdens een werkdag niet leeg te krijgen al doe je je best. Hij is stil, wordt niet warm en is razendsnel.

Voor de meeste gebruikers is het gewoon echt super. Enkel als je net dat ene pakket nodig hebt wat geen ARM versie heeft (ik heb ze niet), geloof ik wel dat het irritant kan zijn.

CharlesND 14 november 2026 18:56

Wat ik ervan begrepen heb is dat ARM de wind in de rug kreeg toen chipfabrikanten voor snellere chips geen hogere klokfrequenties meer konden toepassen en snelheidswinst vooral uit het gebruik van meerdere rekenkernen en voorspellende decodering van de instructies moest komen.

Door de wisselende lengte van de instructies kostte het X64 chips die meer dan 3 tot 4 'brokken' code tegelijk moesten bewerken te veel tijd en overhead om vast te stellen wat de instructies waren en wat de data was en hoe dat in het geheel te passen. ARM chips konden veel efficiënter code in veel meer 'brokken' knippen omdat ze bij elk brok precies wisten wat instructie en wat data was.

Slimme x64 compilers hebben dat misschien wel al voor een deel weten te compenseren maar slimme ARM compilers hebben vast ook niet stil gezeten en het structurele voordeel van die vaste instructie-data structuur blijft ARM natuurlijk houden.

i7x 14 november 2026 19:04

Ik blijf net zoals in het filmpje van de claim horen dat het in theorie niet veel uit zou hoeven maken; dat x86 ook zo snel en zuinig zou kunnen zijn als arm en, andersom, arm net zo traag en energieverslindend als x86. Geen idee of dat werkelijk, theoretisch, zo is. Maar hoe dan ook, wat heb je in de praktijk aan dergelijke theoretische situaties? Helemaal niets natuurlijk. Apple heeft z’n silicon arm gemaakt, niet x86. Qualcomm hetzelfde, Nvidia hetzelfde. En de partijen die nog wel x86 ontwikkelen zijn duidelijk niet van vergelijkbare prestaties wbt energie en rekenkracht. Dus de keuze is simpel voor mij, en ik denk dat het een kwestie van tijd zal zijn voor x86 nauwelijks nog in consumentenproducten te vinden zal zijn, op het budget segment na wellicht.

voxilla 14 november 2026 17:12

Inderdaad ARM is en blijft superieur eenvoudigweg door de zeer complexe x86 variabele lengte instructieset decoder (in parallel per klok veel instructies decoderen) die overbodig is bij ARM . Met ARM 10 instructies per klok decoderen geen probleem, want alle instructies zijn 4 bytes. Transcoderen van x86 naar interne instructie set (met cache) is ook overbodig bij ARM. Dus minder overhead en transistors nodig bij ARM, wat resulteert in minder warmte en meer rekencapaciteit per transistor.

Robbaman @voxilla • 14 november 2026 17:33

Zegt het artikel niet juist dat je dit dus niet zo stellig kunt zeggen? Ik heb de video niet gekeken, maar het geschreven artikel gelezen, maar ik kreeg daaruit juist de indruk dat het dus niet zo klip en klaar is.

voxilla @Robbaman • 14 november 2026 17:40

Ik denk dat er een historische bias is in dit artikel

willieverhoef @voxilla • 14 november 2026 18:51

Dat is zo voor eenvoudige instructies. X64 maakte echte ook uitbreiding voor encryptie, kopiëren hele geheugen blokken etc. Maar een compiler zal deze dan wel allemaal moeten gebruiken en dat eist ook kennis van de processor er de compiler.

Daardoor denk ik dat in de praktijk een arm beter gebruikt wordt dan een 'ingewikkelde' x64.

BvdW1978 @willieverhoef • 14 november 2026 19:40

Het 'probleem' voor x86-64 en producten zoals Windows die binary-only geleverd worden is dat ze in hun fundament de kleinste gemene deler moeten ondersteunen. Je kunt een hele spannende nieuwe CPU maken, maar Microsoft zal niet heel vlug instructies gaan gebruiken die niet op het hele x86-64 landschap aanwezig zijn. Doen ze dat wel, omdat het echt fors waarde oplevert, dan moeten ze onderscheid maken en daar verschillende codepaden voor aanleggen naargelang de CPU van de gebruiker. Iets wat in het verleden bij bijvoorbeeld de Commodore Amiga ook al speelde: het OS start op elke kale Motorola 68000, en daar legde Commodore destijds al speciale libraries bovenop om de nieuwe kuntjes van bijvoorbeeld de 68040 te ondersteunen.

Met software die je zelf compileert, kan tijdens het compileren op jouw machine direct de optimale keuze gemaakt worden. Iets waar Gentoo Linux een sport van heeft gemaakt, en wat in elk geval in het verleden ook wel merkbaar was in het resultaat. Of dat nog zo is, weet ik eerlijk gezegd niet. Ben al een tijdje geleden van Gentoo afgestapt.

Om te kunnen reageren moet je ingelogd zijn

Nvidia-thrillers, wasmachineliedjes en GTA-framerates - Tweakers Podcast #452