Intel en AMD gaan samenwerken met techbedrijven om x86 te harmoniseren

Intel en AMD hebben de x86 Ecosystem Advisory Group opgericht. De twee chipmakers gaan daarin samenwerken om de x86-instructiesetarchitectuur te harmoniseren. Verschillende grote techbedrijven voegen zich bij de groep.

Intel en AMD kondigden de x86 Ecosystem Advisory Group aan tijdens de OCP Summit in Californië. Naast de twee chipmakers worden onder andere Broadcom, Dell, Google, HP, Lenovo, Meta en Microsoft lid van de adviesgroep, naast Epic Games-ceo Tim Sweeney en Linux-bedenker Linus Torvalds. De groep is van plan om technische input te vragen van klanten, zoals hardwarefabrikanten en softwareontwikkelaars.

Intel-ceo Pat Gelsinger en
AMD-ceo Lisa Su. Bron: Intel

De x86-adviesgroep noemt verschillende doelen die hij hoopt te bereiken. Zo willen Intel en AMD 'de compatibiliteit, voorspelbaarheid en consistentie van het x86-productaanbod verbeteren'. De groep zegt ook dat de architectuurrichtlijnen versimpeld moeten worden en claimt dat de interfaces gestandaardiseerd moeten worden 'voor alle x86-producten van Intel en AMD'. Dat moet het ontwikkelwerk voor softwareontwikkelaars versimpelen en het makkelijker maken om 'nieuwe mogelijkheden' in besturingssystemen te integreren.

Onder de groep zouden toekomstige aanpassingen en toevoegingen aan de x86-isa dan ook gestandaardiseerd worden, om te voorkomen dat grote verschillen tussen de instructiesets in Intels en AMD's chips ontstaan. De twee chipmakers noemen daarvan echter geen concrete voorbeelden in hun aankondiging. Beide bedrijven werken individueel al langer aan nieuwe x86-initiatieven, in het bijzonder het x86s-voorstel van Intel. Dat zou een versimpelde versie van x86 worden met enkel 64bit-ondersteuning en met minder legacyinstructies. Datzelfde bedrijf kwam eerder ook met een nieuwe AVX10-instructieset.

Intel en AMD benadrukken dat ze felle concurrenten van elkaar blijven. Ze noemen de x86-adviesgroep in een interview met Tom's Hardware echter 'één van de belangrijkste verschuivingen in de x86-architectuur in decennia'. "X86 is de facto de standaard. Het is een sterk ecosysteem dat Intel en AMD in zekere zin samen hebben ontwikkeld, maar op een armlengte afstand. Dat heeft in de loop der tijd wat inefficiënties en wat afwijkingen in delen van de isa veroorzaakt", zegt AMD-datacenterhoofd Forrest Norrod.

X86 wordt al decennialang gebruikt in nagenoeg alle pc's en desktops. Tegelijk voelen AMD en Intel de laatste jaren steeds meer concurrentie van Arm, zowel op consumenten- als op datacentergebied, hoewel ze dat niet concreet benoemen in hun aankondiging. Apple stapte eerder met succes over op die instructiesetarchitectuur voor zijn MacBooks. Ook Qualcomms nieuwe Snapdragon X-socs voor Windows-laptops lijken relatief succesvol en worden overwegend goed ontvangen vanwege hun accuduur. De adviesgroep moet ervoor zorgen dat de x86-architectuur 'zich blijft ontwikkelen als het voorkeursplatform voor zowel ontwikkelaars als klanten'.

Reacties (94)

[majic]

Denk dat ze beter gezamenlijk konden beslissen om ARM te omarmen (pun intended). X86 is een nodeloos complex systeem om computerchips functioneel te maken. Iedereen naar ARM zou veel beter zijn voor consumenten (in theorie meer mogelijkheden om diverse OS-en op veel apparaten te draaien). Jammer dus.

[Reactie gewijzigd door majic op 16 oktober 2024 08:18]

[Jeanpaul145]

Vanuit een business perspectief is dat het domste wat ze kunnen doen:
- Intel en AMD bezitten het IP op x86/x86-64
- Daardoor hoeven ze geen royalties af te dragen
- En ze kunnen innoveren hoe, waar en wanneer ze maar willen
- Ze hebben extreem sterke interne support want ze hebben letterlijk de engineers en architecten in-house
- Geen enkele 3rd party kan ze dus de les lezen mbt het ontwikkelen van x86/x86-64 technologie

Geen van die puntrn blijft overeind als ze een ARM licentie afnemen en daarop overstappen.
Het zou dus niet zozeer zichzelf in de voet schieten zijn als wel een tactical nuke op hun eigen (en elkaars) voeten richten, en vervolgens de trekker overhalen.

[CH4OS]

Waarom is ARM beter volgens jou? En waarom is het (wat meer) open source RISC geen alternatief?

[_Pussycat_]

Een daadwerkelijk voordeel van ARM is schijnbaar dat instructies een vaste lengte hebben. x86-instructies kunnen 1...15 byte lang zijn:

• Legacy prefixes (1-4 bytes, optional)
• Opcode with prefixes (1-4 bytes, required)
• ModR/M (1 byte, if required)
• SIB (1 byte, if required)
• Displacement (1, 2, 4 or 8 bytes, if required)
• Immediate (1, 2, 4 or 8 bytes, if required)

Bij ARM zijn de bevelen altijd 32 bit.

Dat verschil zorgt ervoor dat een x86-decoder niet weet waar een bevel begint. Bij het speculatieve decoden moet hij daarom bij elke byte beginnen, wat veel verspilde stroom kost voor het decoderen van dingen die helemaal geen bevelen blijken te zijn. Bij ARM heb je dat probleem niet.

RISC-V is waarschijnlijk ook prima.... maar goed, daar zijn (nog) geen snelle implementeringen van.

[Halfscherp]

Jim Keller, de man die grondlegger is van een paar van de beste chiplijnen bij Apple, AMD, Tesla en mee heeft geschreven aan de x86 spec zegt dat over ISAs discussiëren onzin is.

Dit artikel geeft goede argumentatie waarom: https://chipsandcheese.com/p/arm-or-x86-isa-doesnt-matter

[_Pussycat_]

Grandioos artikel, dankjewel! De decoder gebruikt dus blijkbaar bij ze allebij een klein maar niet compleet onsignificant deel van het vermogen, maar het is niet al te veel.
En Jim Keller zal er nogal wat meer vanaf weten dan ik...

[lenwar]

Ik ben geen expert, maar ga je met RISC-systemen niet krijgen dat je dan weer heel veel moet offloaden naar andere processoren?

We zien het nu al dat zeer complexe berekeningen door GPU's worden uitgevoerd omdat die daar beter in zijn.
Een PC/standaard server (in de breedste vorm) is per definitie een manusje van alles. Uiteindelijk moet iedere PC 'alles' kunnen. Althans. Dat is de filosofie. Allicht moeten we daar vanaf?

Het 'voordeel' van x86, is dat het alles 'best wel goed' kan. ARM heeft dit (in iets mindere mate) ook. ARM is weer meer gefocust op de meestvoorkomende taken. (tot op het niveau dat het een prima PC/Server-CPU is voor verreweg de meeste taken.)

Als we historisch kijken naar servers zie je dit ook terug. De IBM RS-series waren/zijn zeer geschikt voor bepaalde type zaken. Als we naar (voormalig Sun's) SPARC kijken. Die had weer een ander focus-punt waar ze sterker in waren/zijn.

Nou moest je wel heel erg specifieke dingen doen, wilde je er echt wat van merken in de praktijk natuurlijk. Een mooi voorbeeld was de Sun SPARC T5 processor. Dit was een 8-core CPU met 128 threads. Hiermee was die chip bijzonder geschikt om containers (of kleine VMs) op te draaien of heel drukke webservers op te hosten. Maar dan weer bijzonder ongeschikt om grote query's op grote databases te verwerken. (De grootste server in deze serie kon 8 van die CPUs dragen, waardoor je dus een server met 16384 threads (en maximaal 4 TB RAM ter beschikking had )

[latka]

We zien het nu al dat zeer complexe berekeningen door GPU's worden uitgevoerd omdat die daar beter in zijn.

Het is iets eenvoudiger dan dat. Zowel een GPU als een CPU kunnen even complexe berekeningen uitvoeren. Alleen een CPU doet dit achter elkaar (sequentieel). Dus als er 100 keer een getal opgeteld moet worden doe je dat met een lusje die 100 keer dezelfde operatie doet.
Een GPU is eigenlijk een eenvoudige CPU, maar dan wel een paar duizend naast elkaar. Dus 100 getallen optellen kan dan door iedere CPU een eigen optelling te laten doen (parallel). De GPU doet het dan (vereenvoudigd) 100x sneller.

Een 2e factor die heel erg meespeelt is de geheugenbandbreedte: een CPU kan beschikken over 128Gb geheugen (of meer), maar kan daar met ongeveer 50Gb/s uit lezen. Als je veel getallen op moet tellen is je CPU niet de bottleneck, maar hoe snel je de getallen uit het geheugen kan trekken.
Zet daar een snelle videokaart naast die GDDR6 of HBM geheugen heeft en je kunt met 1000Gb/s (of meer) lezen. Dus de GPU hoeft minder lang te wachten. Dat is ook de reden dat de Apple M1/2 CPUs zo verdomd snel zijn: het geheugen zit OP de CPU (net zoals de nieuwste Intel mobile chips): die leest met 200Gb/s (tussen GPU en CPU oplossing in dus).

En dan over je offloading: dat is van alle tijden: neem video encoding: ook op een dikke videokaart wordt dat ge-offload naar een andere CPU (quicksync voor Intel of NVENC voor NVidia).

[Creesch]

Ik ben geen expert, maar ga je met RISC-systemen niet krijgen dat je dan weer heel veel moet offloaden naar andere processoren?

In hoeverre het echt noodzakelijk is weet ik niet, maar dit zie je o.a. terug bij de Apple M series waar er voor diverse taken dedicated sillicon aanwezig is op de SoC. Zo is er bijvoorbeeld de "Media Engine" chip verantwoordelijk voor allemaal zaken rondom video en audio en/decoding.

Dit is overigens niet uniek voor ARM of RISC architectuur. Ook x86 processoren hebben dedicated hardware voor zeer specifieke taken. Een recent voorbeeld is het toevoegen van een neural processing unit (NPU) voor AI gerelateerde zaken.

[lenwar]

Dit bedoel ik dus:

Zo is er bijvoorbeeld de "Media Engine" chip verantwoordelijk voor allemaal zaken rondom video en audio en/decoding.

Dit is iets basaals. Multimediataken (denk aan een Youtube filmpje kijken) is dus blijkbaar iets dat die M-chip niet goed (genoeg) kan. Ik zeg dus niet dat dat slecht ik voor het geval, maar hoe specifieker je de chips maakt, hoe meer chips je nodig hebt om iets op een bepaald niveau te kunnen doen.

De x86-processoren, kunnen alles 'best wel oké'. Daarom hebben die chips wat mij betreft nog best wel bestaansrecht.

[TheekAzzaBreek]

Het idee van RISC is niet dat complexe acties worden opgelost door een andere processor, maar door software. In de praktijk is dat de compiler, of je zou zelfs kunnen zeggen de x86 microcode, want veel complexe x86 instructies worden niet direct door de rekenkernen uitgevoerd, maar eerst vertaald naar veel simpeler instructies.

[i7x]

Ik ben geen expert oid, maar als ik gewoon kijk naar wat ik zie qua warmte, batterij, en prestaties, dan denk ik waarom zou het niet beter zijn? Behalve dan misschien voor legacy spul. Maar ook dat kun je doorgaans toch wel emuleren? Heb een x86 (64) laptop van werk, maar altijd weer blij als ik thuis met de M2 Pro aan de slag kan. En stel je voor, een telefoon op x86, dat zou toch ook dramatisch zijn? Dus ja, mij ontgaat het een beetje wat de meerwaarde van x86 nog zou zijn. En RISC-V, daar weet ik zelf gewoon te weinig vanaf. Wellicht een mooi initiatief, maar het is duidelijk dat de adoptie niet ook maar in de buurt komt bij Arm of x86.

[CH4OS]

Elke instructieset heeft zijn eigen voor- en nadelen. Het ligt ook enorm aan het gebruik wat je het beste kunt gebruiken. Voor algemeen gebruik is x86 decennialang de defacto standaard geweest en ook dat heeft zijn redenen. Zomaar gaan roepen dat ARM (voor de consument) beter is voelt dan een beetje als uit de lucht gegrepen, tenminste, als er geen verdere onderbouwing bij zit. Dat ARM nu ook in laptops zit, is ook pas sinds dit jaar en in laptops ook nog, het is dus afwachten of ARM echt een succes gaat worden.

Volgens mij is x86 voor telefoons al geprobeerd en was dat niet echt een succes, mede omdat het stroomverbruik een stuk hoger was, wil je dat aanpakken/oplossen, zul je waarschijnlijk oude instructies uit de x86 instructieset moeten halen en mogelijk dat dit gedaan gaat worden door inzichten die deze adviesgroep dus gaat verkrijgen/hebben/adviseren.

Ook het emuleren (hetzij x86(-64) naar ARM, hetzij ARM naar x86(-64)) betekend inefficiëntie, dus dat wil je eigenlijk ook zoveel als mogelijk voorkomen.

[svenk91]

ARM zit al wel langer in laptops. Apple heeft er flink succes mee sinds 2020 en waren ook zeker niet de eerste. Chromebooks kan je ook in ARM versie krijgen. Windows heeft al sinds 2012 ARM versies van zijn desktop/laptop OS, daar is het misschien nog wachten op de echt grote doorbraak maar het bestaat zeker langer dan een jaar.

[CH4OS]

Eens, alleen is het recentelijk wel breder beschikbaar geworden voor het grote publiek. Apple en Chromebooks zijn toch aparte en niche markten/doelgroepen. Apple zit daarbij ook nog eens in een hoger prijssegment bijvoorbeeld.

[Reactie gewijzigd door CH4OS op 16 oktober 2024 12:10]

[jdevrie]

wil je dat aanpakken/oplossen, zul je waarschijnlijk oude instructies uit de x86 instructieset moeten halen en mogelijk dat dit gedaan gaat worden door inzichten die deze adviesgroep dus gaat verkrijgen/hebben/adviseren.

Dat klopt want dan wordt de decision tree om te bepalen welke instructie er uitgevoerd moet worden kleiner en daar schijnt de X86 architectuur relatief vrij lang in bezig te zijn om een instructie uit te kunnen voeren.
Daarom zijn pure RISC processors zoveel sneller omdat die een veel kleinere instructieset hebben.

[MSalters]

Nope - het is hierboven al aangehaald, maar instruction decoding is in elke moderne CPU onderdeel van de pipeline. Dat kost netto geen tijd; dat gaat in parallel met de uitvoering.

En de instruction decoder is ook geen "decision tree".

[jdevrie]

Nope - het is hierboven al aangehaald, maar instruction decoding is in elke moderne CPU onderdeel van de pipeline. Dat kost netto geen tijd; dat gaat in parallel met de uitvoering.

En de instruction decoder is ook geen "decision tree".

Het kan wel parallel gaan maar als het het langzaamste process is dan houdt het toch de hele processor op.

Als het geen "decision tree" is dan zou het nog langzamer zijn. Via een tree kom je het snelste bij een zoek resultaat. Zoals bijvoorbeeld bij indexen in een database.

[MSalters]

Ik zou een cursus algoritmes adviseren. Een hashtable is significant sneller dan een tree, O(1) amortized tegen O(log N). Lookup is botweg O(1) in alle gevallen.

[Reactie gewijzigd door MSalters op 17 oktober 2024 14:19]

[jdevrie]

We hebben het hier over een processor. Die heeft echt geen hashtables om de te decoderen instructie te vinden. Het is gewoon een binary tree waar de instructie doorheen loopt om bij het juiste decodeer deel van de processor te komen. Dus je opmerking is out of scope.

[Reactie gewijzigd door jdevrie op 17 oktober 2024 17:28]

[MSalters]

Haha. Je kunt een perfect hash gewoon naar transistoren compileren, tegenwoordig. Bied bits X aan, krijg X eruit. Bied B aan, krijg Z eruit. Hoe zou jij dat herkennen? En omdat het simpele NAND gates zijn, is dat dus 1 klokcyclus. Denk je serieus dat Intel of AMD beiden zo'n triviale off-the-shelf oplossing zouden negeren?

Sterker nog, dit is zo triviaal dat je het waarschijnlijk niet eens kunt patenteren.

[Scribe]

Een van de belangrijke dingen hier is 100% zeker stabiliteit. Emuleren kan altijd, maar bijvoorbeeld Windows is zo gebouwd dat het altijd perfecte backwards compatability heeft. Weet niet of dat perfect te emuleren zou zijn.

Het oude riedeltje dat ik ken is
ARM voor power efficiency
x86 voor zware taken

Ben benieuwd of dat tegenwoordig nog steeds zo is

[Exirion]

Kijk naar de moderne Macs en je hebt je antwoord.

[chaoscontrol]

Tot je echt computer werk wil doen en allerhande instructies als AVX mist.

[Exirion]

Dat is alleen een probleem als je rigide wil vasthouden aan proprietary instructiesets. Getuige de performance van bekende geporte software die typisch leunt op SIMD, zit het met de equivalenten van ARM wel goed. Zie ook: https://developer.arm.com...t-with-SSE2Neon-and-SIMDe

[chaoscontrol]

NEON is nog lang niet waar AVX is. Ik zeg niet dat dat nooit gaat zijn, maar op dit moment is x86 nog heer en meester.

[Exirion]

Het is maar hoe je het bekijkt. Afgezien van hoe mooi of uitgebreid een architectuur is, telt uiteindelijk de performance, en de cijfers spreken voor zich. De wildgroei bij x86 sinds MMX heeft het platform niet alleen maar goeds gebracht en dat is precies waar dit nieuwsitem over gaat.

[necessaryevil]

Er zijn telefoons geweest met x86 processors van Intel. Die waren niet rampzalig, prestaties en verbruik waren gewoon goed. Intel heeft die markt eigenlijk zomaar netaan gemist,ARM domineerde al. Destijds werd verteld dat x86 cpu's een interne decoder hadden die voor wat overhead zorgen, maar er werd ook gezegd dat die overhead steeds kleiner werd doordat er voor snellere processors de decoder niet of nauwelijks mee groter wordt. ttps://www.extremetech.com/computing/187513-why-apple-wont-dump-intel-x86-for-its-own-arm-chips-in-macbooks-and-the-mac-pro"]dit[/url] artikel wordt uitgelegd dat ARM zich toegelegd heeft op low power en Intel op high performance. Maar dat artikel is al tien jaar oud. Het schijnt dat de nieuwe processors van Apple (M4) het winnen van Intel. Ik ben nog wel benieuwd naar een serieus artukel met benchmarks en single core performance.

Tot slot: AMD heeft zijjn ARM plannen een tijd geleden gecanceld.

[Anoniem: 201953]

De eerste ARMs zaten volgens mij in desktops van de uitvinders van de ARM. Ik heb er hier nog twee staan. Die zijn bijna 40 jaar oud. Even oud als de 32-bits versie van de x86.

[Reactie gewijzigd door Anoniem: 201953 op 16 oktober 2024 16:28]

[i7x]

Ok geinig verhaal maar ik mis je punt denk ik.

[Anoniem: 201953]

Dat is niet geinig maar interessant omdat die uiteindelijk uiterst succesvolle processorarchitectuur uit 1985 nu mogelijk toch succesvol wordt in laptops en desktops zoals oorspronkelijk de bedoeling was en ook nog om dezelfde reden, de zuinigheid.

[Reactie gewijzigd door Anoniem: 201953 op 17 oktober 2024 11:08]

[i7x]

Zeker interessante interessante historie inderdaad

[SG]

X86 heeft oorsprong in server en desktop dus Client 250 wat en servers tot 4 sockets per node.
ARM is embeded IOT industrial embeded. Dus oorsprong waar lichte compute maar zuinig.
ARM heeft ook niet die Game kroon race met insane klokken en directe harde concurentie op desktop.
Dat heeft zeer grote invloedgehad op Architectuur beleid dat doodspoor endigede eerder met PRescot P4 later Raptor lake.
Apple heeft hardcore gamen links laten liggen. Heeft sterk op mobiliteit ingezet. Daar voldeed iNtel slecht aan. Dus Apple Silicon. ARM is niet vervuild met idiote arms race voor ultieme game performance door extreem klokbare transistor tech implementatie richting de halve kilowatt.
in plaats daarvan zijn hun Bigcores soort van kan maar tot 4ghz gaan. Transistor dens wat ipc gigantisch ten goede komt. denk aan Ecore Zen5 dense maakt daar big core van. Met fat ecore of fat zen dens zou x86 ook IPC kunnen vedubbelen.

ARM oer Cpu zijn ook van simple oer zuinige 1 stage naar 2 stage naar 6 stage.
X86 Buldoze is 20 stage. Dus dat kan minder

En dat maakt dat er nog veel potentie is voor X86. vraag me af waar sweet stop zit. Ergens tussen de 10 a 14 stages.

[dmantione]

ARM levert veel rekenkracht per instructie, RISC-V weinig. De geschiedenis heeft geleerd dat de hoge kloksnelheden om dat te compenseren niet waargemaakt kunnen worden, wat ARM een betere instructieset maakt. Dat neemt niet weg dat er niches voor RISC-V kunnen zijn: De uitbreidbaarheid van de instructieset maakt deze ideaal voor toepassingsspecifieke processoren.

[Blokker_1999]

Waarom zou arm beter zijn voor consumenten? Je hebt decennia aan software die op x86 is gemaakt die in 1 klap niet meer zal werken. Natuurlijk kunnen we proberen te virtualiseren, maar ben je dan niet echt foutief bezig?

En heel vaak krijg je dan de discussie tussen RISC en CISC waarbij vele mensen zich niet realiseren dat een moderne Intel of AMD CPU ook een RISC processor is waarbij de complexe instructies in eenvoudige blokjes worden opgedeeld.

En dan krijg je het argument dat arm een jonge, moderne architectuur is, maar dan ga je opzoeken hoe oud die is, en dan zie je dat arm op zich niet veel jonger is dan de x86 instructieset. Natuurlijk is de huidige basis een stuk jonger, maar x86-64 kan je ook niet meer vergelijken met de 8086 CPU.

Vervolgens gaat men het hebben over stroomverbruik. Heb je de review van de nieuwste Intel gezien? In vergelijking met de Snapdragon X moet die niet onderdoen op hoe lang deze op een batterijlading kan meegaan. En ooit al eens het verbruik bekeken van een macbook die op vol vermogen de CPU staat te belasten? Dan houdt zo een macbook het ook geen halve dag uit op een batterijlading.

Dus vertel me, wat is het voordeel van massaal over te stappen op arm?

* Blokker_1999 typt dit bericht op een Surface Laptop 7 met Snapdragon X CPU

[Remzi1993]

Ipv emulatie kan er ook een vertaallaag geïmplementeerd worden in de hardware. Vertaling is altijd sneller dan emulatie zie WINE en Proton die het goed doen.

[EraYaN]

Maar dat is exact hoe x86 al werkt, de decoder is in essentie een vertaalslag naar microops.

[Remzi1993]

Ik had het over x86 instructies naar ARM instructies en andersom.

[MSalters]

Waarom zou je in godesnaam x86 naar ARM naar uops willen vertalen, als je direct van x86 naar uops kunt? Twee instructie-decoders gebruiken twee keer zoveel energie als één.

[DropjesLover]

Is het niet zo dat software die nog op zeer oude x86 instructies draait net makkelijk te virtualiseren is omdat de applicaties niet dermate zwaar zijn, vergeleken met hedendaagse? Het verschil in performance zal minimaal zijn.

[Janspook]

X86 is zo ruk omdat er zoveel oude insturcties inzitten. ARM heeft daar (nog) geen last van.
Als ze X86 nou eens helemaal op de schopgooien en die oude meuk eruit gooien dan heb je een goeie instructieset.

[Klaus_1250]

Volgens mij heeft Intel zelf dat al 4 keer eerder geprobeerd, maar het is nooit gelukt.

[EraYaN]

ARM heeft ook zat oude meuk hoor, gaat al weer mee sinds de jaren 80. ARM gooit er wel stelsel matig wat meer uit, maar dat is dan ook 1 van de selling points van x86, dat dat een stuk meer backwards compatibele is.

[Sinester]

X86 is zo ruk omdat er zoveel oude insturcties inzitten. ARM heeft daar (nog) geen last van.

Zo ruk is het toch niet als je ziet dat x86 nog steeds prima kan me komen met ARM en qua ultieme prestaties nog steeds voor loopt? (wel met meer power)

x86 heeft al bezen in laptops net zo snel en zuinig te kunnen zijn als ARM

Ik zie het voordeel dus niet echt, wel een heleboel nadelen die je zeker in de eerste jaren gaat krijgen als er masaal overstapt gaat worden

[jdevrie]

X86 is zo ruk omdat er zoveel oude insturcties inzitten. ARM heeft daar (nog) geen last van.
Als ze X86 nou eens helemaal op de schopgooien en die oude meuk eruit gooien dan heb je een goeie instructieset.

Dat klopt want dan wordt de decision tree om te bepalen welke instructie er uitgevoerd moet worden kleiner en daar schijnt de X86 architectuur relatief vrij lang in bezig te zijn om een instructie uit te kunnen voeren.
Daarom zijn pure RISC processors zoveel sneller omdat die een veel kleinere instructieset hebben.

[MSalters]

De Execution Units (EU) voeren geen x86 ops uit, maar vertaalde uops. Sowieso zijn dat geen decision trees (veel te langzaam); uop decoding kan prima bit-parallel. En de snelheid hiervan wordt grotendeels gemaskeerd door de pipeline.

[jdevrie]

Dat weet ik maar de instructies moeten toch eerst door dat langzame vertaal proces heen voordat ze als Risc instructies uitgevoerd kunnen worden en dat houdt de totale pipeline op. Een ketting is zo sterk als de zwakste schakel.

[MSalters]

Nope. De pipeline is momenteel beperkt in doorvooersnelheid door memory bandwidth in retirement. (afronden van instructies). Dat is de "achterkant".

[SG]

Dat is niet ruk, probleem is dat zeer grote spelers in software gebruikers afhankelijk zijn van die legacy. Het is voor de een crusiaal. Maar houd vooruitgang ook tegen.
Als je er iets uit sloopt dan werkt hoop software niet meer. je breid het juist uit.
ARM is zijn oorsprong in embedded. probleem daar is dat voor een Embedded toepassing shopt bij ARM daar licentie pakt. is het puur voor specifieke taak. waar je producten voor maakt. dan implementeer je uitsluitend wat je nodig hebt voor die taak. en lever je dus een SOC voor product op, die wat extenties of FPU kan missen. ARM heeft het dus maatje erger naast legacy daar kunnen extenties en zelfs de FPU optioneel zijn. Dus kan grote kans zijn dat Xelite en M4 niet compatible zijn en elk een aparte Linux kern nodig hebben.
Linux moet altijd voor bepaalde exotische Soc een apparte kernel distro voor ontwikkelen die rekening houd met missende extenties. Naast toegevoegde extenties.

[Anoniem: 201953]

ARM heeft zijn oorsprong (1985) niet in de embedded wereld maar is bedacht door een producent van wat toen thuiscomputers werden genoemd. Het moest een soort opvolger van de 6502 zijn.
De daarna gelicenseerde ontwerpen waren wel voor embedded toepassingen bedoeld.

[MSalters]

ARM heeft ook al oude instructies (FDADD) die tientallen uops vereisen. Het boeit gewoon geen zak: compilers gebruiken die instructies niet, dus de snelheid van die instructies is alleen relevant voor 20 jaar oude binaries. En die binaries zijn alsnog een stuk sneller op moderne chips door hogere clocks en betere caches.

[Frame164]

ARM en X86 hebben beide hun sterke en zwakker punten. Zo wordt er in de serverwereld wel naar ARM gekeken maar is het vooralsnog allemaal X86. Logisch want een migratie naar ARM heeft bijna oneindig veel meer impact dan een ARM in een PC te stoppen.

[MSalters]

Aan de andere kant, een Postgres server draait Postgres. De interface is SQL, en dus is Postgres 14 vs 15 een groter verschil dan Postgres op x86 vs ARM. Python is iets meer een issue want binaire modules, maar die zijn ook al vaak in ARM beschikbaar.

[psychicist]

Ik zou ook x86 harmoniseren als zijnde uitfaseren. Maar dat is iets waar andere bedrijven dan maar voor moeten gaan zorgen. Als Qualcomm Intel zou overnemen, zou dat proces evenwel in een stroomversnelling kunnen komen.

[Blokker_1999]

Jarenlang concureren met elkaar door eigen instructies toe te voegen die de andere niet zomaar kan en mag overnemen en nu Intel het moeilijk heeft en een andere architectuur de kop begint op te steken willen ze ineens samenwerken. Klinkt al bijna als een poging tot kartelvorming om arm zo buiten de deur te houden.

[bwerg]

Samenwerking is niet hetzelfde als kartelvorming. Dat wordt het pas zodra de consument nadeel van ondervindt door bijvoorbeeld prijsafspraken. Ik zie niet in hoe dat hier het geval is.

[lenwar]

Nou nee.
Bedrijven mogen prima samenwerken op bepaalde vlakken, zolang ze ook maar blijven concurreren. Samen een standaard onderhouden is prima.

In een notendop is kartelvorming een formele afspraak dat twee bedrijven niet met elkaar gaan concurreren. Dit is de facto ongunstig voor concurrentie, en daarmee dus per definitie ongunstig voor de consument, en om die reden ook verboden.

Je ziet kartelvorming bij glazenwassers. Die hebben een 'afspraak' dat ze niet in elkaars wijk gaan glazenwassen.

[bwerg]

Volgens mij is dat zo ongeveer wat ik ook zeg.

[lenwar]

Niet helemaal.
Kartelvorming is verboden. Ook als het publiek er geen last van heeft. Dat staat er in de basis los van. (Alleen zien we in de praktijk dat het publiek er altijd last van heeft). Onze redenaties zijn dus omgekeerd.

Stel dat die glazenwassers allemaal tegen het absolute minimumbedrag die glazen komen wassen (dus dat het echt redelijkerwijs niet voor minder kan, en dat die glazenwassers zelf om welke reden dan ook, echt per se niet hun diensten willen aanbieden in andere wijken), dan hebben we als consument er dus geen last van. En toch is het dan kartelvorming als zij onderling die afspraken maken.

[SG]

Kartel vorming als alle hoofd spelers samen prijs afspraken maken naar de consument.
daar kan je van spreken als Apple Qualcom intel AMD samen prijs afspraken maken om prijzen hoog te maken. Zoiets als Extreem edition maar dan MSRP forceren van 1000 euro voor 6 core van apple qualcom intel AMD. Dat is kartel. Er is dan geen concurrentie.

[lenwar]

Dat is inderdaad ‘ook’ kartelvorming.

Maar het is niet alleen prijsafspraken maken. Het is in de breedste vorm afspreken niet met elkaar te concurreren.

https://www.rijksoverheid.nl/onderwerpen/mededinging/kartel

[Hardfreak]

Ik denk niet dat Intel en AMD dit op zo'n korte tijd in elkaar hebben geflanst, dus om het zomaar te steken op de recente problemen van Intel is misschien een klein beetje te kort door de bocht.

Hoe leuk consumentjes ook zijn, er zit veel meer geld in de servermarkt en Intel en AMD zien waarschijnlijk hoe ze aandeel verliezen tegen de veel zuinigere ARM chips (zoals bv AWS Gravitons). Daarnaast is het toevoegen van extra instructies heel leuk, maar als je je code niet optimaliseert voor de nieuwe instructies (bv met march=x86_64_v4), dan kan je evengoed op je oude hardware blijven draaien.

En wat maakt het nu uit of het kartelvorming is of niet, volgens mij kunnen wij er alleen maar voordelen uit halen. X86 en AMD64 zijn al een paar decennia exclusief bij Intel en AMD, die er zelf maar een gooi naar doen. Het enige goede dat daar ooit uit is voortgekomen is AMD64, verder heeft niemand iets aan instructies die alleen maar werken op Intel of AMD...

[jdevrie]

En wat maakt het nu uit of het kartelvorming is of niet, volgens mij kunnen wij er alleen maar voordelen uit halen. X86 en AMD64 zijn al een paar decennia exclusief bij Intel en AMD, die er zelf maar een gooi naar doen. Het enige goede dat daar ooit uit is voortgekomen is AMD64, verder heeft niemand iets aan instructies die alleen maar werken op Intel of AMD...

Dit is echt geen kartelvorming. Ze maken geen afspraken over prijzen of productie beperkingen of verdeling van de markt. Dit is gewoon een kwestie van standaardisatie waardoor ze beter op de markt kunnen inspelen omdat de ontwikkelaars dan maar met één instructieset te maken hebben in plaats van verschillende extensies per chip leverancier zoals nu het geval is.

[Reactie gewijzigd door jdevrie op 16 oktober 2024 11:30]

[SG]

Tussen CPU boeren en consumenten zitten software branche. Dit heeft ook groten deels met software dev te maken. om wild groei in extensies of onnodig varianten te creëren.
X86 laat ook met nextgen zien dat heel stuk zuiniger kan. Lunar lake en AI 300 series.
de volgende stap is flink in te zetten op IPC en dense transistoren die niet idioot klok schalen minder stages zodat je monster IPC bij magere 4Ghz maar single threade performance krijgt die geen 300+++ Wat voeding nodig heeft. en op die manier nextgen performance leverd.

[[Roland]]

Niet bijna, dit is om sterk te staan tegen ARM. Concurentie die werkt, x86 wordt beter.
Kartelvorming minder mee eens, Volgens mij niet meer dan logisch dat er een overkopelende architectuur standaardisatie is. Is dit bij ARM ook niet zo? (weet ik eigenlijk niet).

Beter wel om x86 onafhankelijjk te maken en meer licenties uit te gaan geven aan andere fabrikanten. Het is te lang geleden dat je een via of cyrix proccesor in je pc kon stoppen,

[The Zep Man]

Kartelvorming minder mee eens, Volgens mij niet meer dan logisch dat er een overkopelende architectuur standaardisatie is. Is dit bij ARM ook niet zo? (weet ik eigenlijk niet).

Er zijn twee (relevante) partijen die hun eigen x86 CPU's maken: AMD en Intel. Dat zijn de partijen die bepalen wat in hun CPU's komt. Als afnemer gebruik je die CPU's zoals ze geleverd worden.

ARM maakt zelf niet/nauwelijks eigen CPU's/SoC's. Je koopt als AllWinner, Broadcom, Qualcomm, Rockchip, Apple, etc. een referentieontwerp van ARM, en voegt daar eventueel je eigen extensies aan toe. Vervolgens maakt die tussenpartij eigen SoC's met ARM cores (eventueel met eigen extensies) en andere zaken. Die SoC's worden verkocht aan andere afnemers die daarmee apparaten maken of worden door de "tussenpartij" zelf gebruikt.

Je kan dus zeggen dat ARM beter aansluit op niche en gespecialiseerde scenario's. Met dit bericht lijkt het erop dat AMD en Intel zich wat flexibeler willen opstellen door wensen van grote techbedrijven zelf te implementeren in x86 om zo concurrerend te blijven met ARM.

[Reactie gewijzigd door The Zep Man op 16 oktober 2024 08:56]

[Shal-Ziar]

Tsja, liever de 'vijanden die je kent' maar als wij als consumenten daardoor een concurrerender aanbod aan producten krijgen vind ik het wel prettig. Sowieso is het natuurlijk vreemd dat er binnen de standaard instructieset ook 'niet standaard' zaken worden opgenomen door een enkele fabrikant.

[Ro-Maniak2]

Vandaar ook de talloze door hun juristen erin gesprinkelde anti cartel dog whistles: “at arm’s length”… “felle concurrenten blijven”…

[lodew]

Het gaat om de isa. Maw welke instructies ze gaan implementeren. Dat is op zich een goed ding. Iedereen kent nog wel de gevalletjes waar je met specifieke patchen 3dnow optimalisaties kon toevoegen in bvb de quake serie en zo toch behoorlijke performance boosts kreeg op k6 cpu’s van amd. Als ze dat harmoniseren en dezelfde instructies ondersteunen in het nog altijd een ding hoe ze het onderliggend in hardware implementeren om zo elkaar de beconcurreren op performance dan wel performance per watt. Beiden spreken nu ook het gros van de standaard x86 set maar toch met onderliggende prestatieverschillen. Alleen kunnen ze dan de complete instructieset gelijk trekken. Dat is voor ontwikkelaars ook handig. Dan moeten ze niet meer optimaliseren voor specifieke instructies.

[raro007]

maar ARM is zelf ook een kartelvorm want wie onderhoud ARM buiten ARM?
laatst bleek ook dat apple minder dan de rest aan licenties betaalt en niet zo'n beetje ook.
dus die hebben zelf ook een lievelingetje in de klas..

[NoUser]

Heb de definitie van Kartel niet opgezocht, maar zou naar mijn idee uit meerdere partijen moeten bestaan. ARM doet het alleen, en valt niet onder de definitie. Je zou ze dan eerder monopolist kunnen noemen met hun eigen niche.

[raro007]

Weet ik wat nog erger is. Daarbij is dit niet alleen intel en AMD maar ook google, microsoft en veel meer.

[MSalters]

Een kartel en een monopolist vereisen een markt. De vraag is, wat is die markt? Dat is een belangrijke vraag voor de waakhonden van de wereld, een vraag die in elke rechtzaak beantwoord moet worden. In elk geval is de jurisprudentie duidelijk: je mag als waakhond de markt niet definieren als de klanten van een bedrijf. Daardoor alleen al is ARM per definitie geen monopolist in hun eigen niche. En sowieso, ARM verkoopt vooral veel patent-licenties. Die zijn wettelijk per definitie exclusief. Daar is de vraag dus vooral of je vergelijkbare klanten vergelijkbare prijzen rekent.

[DohnJoe]

Het is de gehele installed base die daarvoor moet overstappen naar arm, niet AMD en Intel. En dat gaat nou eenmaal moeizaam, heeft dit initiatief weinig impact op.

[CH4OS]

En waarom precies moet er worden overgestapt worden op ARM volgens jou? Vanuit welke optiek is dat, gezien elke instructieset zijn eigen voor- en nadelen hebben. De bekende XKCD comic (/927 voor degenen die niet veel nodig hebben ) ligt dan ook wel op de loer hier.

[MehHuntah]

Het is meer een probleem voor software makers. Sommige software die niet naar intermediate code compileert maar direct naar machine code (C, C++ enz) moet opnieuw gecompileerd worden. Dat is op zich niet zo'n groot probleem (ik heb dat zelf jaren geleden ook gedaan voor Itanium op windows en daarna voor x64)

Maar het echte probleem begint dan pas, je moet beide testen, dus je hele productie en test straat moet je verdubbelen.

Dat maakt het een grote investering om 2 verschillende binaries uit te moeten leveren. Als ARM meer gebruikt gaat worden op windows, gaan software houses dat vanzelf wel doen. Maar het is een kip ei probleem..

Tegenwoordig wordt veel bussiness software in java of C# of python geschreven, dan speelt het probleem niet.. Dus ik verwacht dat de stap nu makkelijker is als 20 jaar geleden met Itanium. Dat werd daardoor ook een grote faal.. niet omdat het slechter was (het was zeker sneller en beter) Maar gewoon omdat er te weinig klanten waren.

[SG]

IA64 is complete overhaul en heeft niks gemeen met IA32.
AMD64 neemt de legacy van IA32 mee. en dat heeft IA64 de nek om gedraaid.
itanium IA64 heeft dan weer al die andere heavy tin server platformen de nek omgedraaid. Zoals Alpha. etc.

[MSalters]

Als jij je hele CI/CD straat moet verdubbelen voor ARM, dan doe je toch iets echt fout. Voor professionals is het een kwestie van "assign ARM runner".

De echte ellende zijn de subtiele details: x86 heeft een strong memory model (geen read/write reorderinmg zichtbaar voor andere cores). Sommige C++ thread fouten (missende acquire/release) zijn daardoor onzichtbaar op x86. Dat geeft slecht reproduceerbare fouten op ARM.

[CH4OS]

Sterker nog, als het doel is om over te stappen op ARM, heeft deze hele adviesgroep natuurlijk geen nut, dat immers adviezen uit gaat brengen voor het x86(-64) platform, niet voor ARM.

[watercoolertje]

Hoezo moet? Ik heb precies 0 problemen met X86, leg dan eens uit waarom ik over moet stappen? Ik gebruik x86 voor gaming, succes met een beter ARM alternatief vinden!

Ik heb ook geen issues met ARM overigens, het blinkt uit op bepaalde vlakken, net als X86 op bepaalde vlakken weer beter is. Hangt het dan niet vooral van je doel af wat nuttig(er) is om te gebruiken?

[Reactie gewijzigd door watercoolertje op 16 oktober 2024 10:38]

[SG]

ARM heeft hetzelfde als toen met nvidia infinitFX engine. werd mythisch , komt van de goden. toen werd weg geblazen door ATI gen 9700pro.
ARM wordt als zuinigheid wonder gezien. Maar dat komt niet doordat ARM is. dat komt omdat in begin jaren deze tech door firma voor enkele wat toepassinge werdmgebruik.
Terwijl x86 er Pentium III 1133 van markt werd gehaald omdat klok op randje was AMD 1200 en later 1400 haalde. en toen kwam P4 met 1,5ghz. De klok race prescot ergens met deze gen voorbij de 100watt gingen.

we hebben hier te maken met de game kroon race.
vs bedrijf dat een IOT CPU opleverd. dat zou een Soc kunnen zijn van 5$ voor IOT ding van 50$
iets wat x86 merken niet interessant vinden om zich die markt begeven.
Waar ze wel P4 hebben los gelaten zijn laptops. laptops met desktop CPU met bat duur van iets meer dan uur. was 1ste ARM laptop Surface ding van MS en was dat pre M1. En juist niet zoon succes geworden.

[DohnJoe]

Hoeft van mij niet maar ik snap de verwarring, mijn post had een reactie moeten zijn op dit bericht : https://tweakers.net/nieu...ction=20407818#r_20407818

[Mightymike112]

Ik zie liever dat ze zich gaan focussen op ARM. Krijg je ook nog eens een lekker lange batterijduur van. Nieuwe hp met snapdragon bijvoorbeeld.. Bizar wat een batterijduur.

[Gazuhl]

Ik liever niet. Als ARM de enige instructieset is, verdwijnt de grootste driver voor innovatie. We hebben dit 20 jaar geleden ook gezien. AMD kwam niet meer mee, andere chipmakers vielen om, intel was alleenheerser. Jarenlang viel de innovatie bijna stil. Alleen maar mondjesmaat wat refreshes en kleine verbeteringen. Als je vooruit wilt, heb je iemand nodig die je bij elke stap uitdaagt om het beter te doen.

[field33P]

Wel gek dat Sweeney op persoonlijke titel in de adviesgroep zit. En is Unreal Engine dan blijkbaar dermate van belang voor x86 dat Epic medezeggenschap krijgt over de ISA?

[CH4OS]

Als iemand op persoonlijke titel in een adviesgroep zit, hoe kan een bedrijf dan opeens zeggenschap krijgen? Dan moeten ze als bedrijf instappen en niet als persoon. Natuurlijk kan Sweeney eea vanuit Epic meenemen, maar als Epic een groter belang had, hadden zij echt wel zelf ingestapt mag ik hopen.

[field33P]

Epic heeft als bedrijf groter belang bij het sturen van x86 dan Sweeney zelf, schat ik zomaar in. In het geval van Linus Torvalds valt het nog te verklaren door het feit dat er strikt genomen geen bedrijf eigenaar is van de Linux-kernel en hij wel het project runt.

[CH4OS]

Dat schat ik ook zo in, maar dat zeg ik, dan zou ik verwachten dat Epic zelf instapt als lid, en niet Sweeney laat instappen op persoonlijke titel.

[Sp3ci3s8472]

Hij zag dat Linus er met zijn naam op kwam te staan en dacht, dat moet ik ook.

[ronaldvr]

Ben benieuwd of ze nVidia ook nog aan boord willen

EDIT: Excuus Had de verkeerde, een wat langere die meer duidelijk maakt: YouTube: Linus Torvalds' opinion on Nvidia

[Reactie gewijzigd door ronaldvr op 16 oktober 2024 14:43]

[CH4OS]

Met een video van 7 jaar oud, dat slechts een gedeelte van het antwoord van Linus laat zien? Nadat er uitgezoomd wordt, hoor je Linus duidelijk zeggen "Don't get me wrong...", maar de video stopt dan helaas.

[MPIU8686]

Als je aartsvijand die al halverwege de afgrond ligt .. dreigt dieper te vallen en er opeens een nieuwe dreiging tevoorschijnt komt.

Dan toch maar even een touw uitwerpen naar die goeie ouwe aartsvijand ..

Samen staan ze allezins sterker tegen de nieuwe dreiging, eender in welk jasje ze dit aankleden.


~ Intel - AMD ARM ..

[ronaldvr]

Zie de edit

[mutley69]

Dit initiatief komt 10 jaar te laat. X64 is RIP binnen 10 jaar.