Intel kondigt nieuwe AVX10-instructieset aan voor zowel P- als E-cores

Intel gaat toekomstige processors uitrusten met de nieuwe AVX10-instructiesetarchitectuur. Daarin wordt ondersteuning voor 512bit-berekeningen optioneel, wat het mogelijk maakt om de instructiesetuitbreiding op zowel P- als E-cores te gebruiken.

Op dit moment vereist AVX-512, tot nu toe de nieuwste iteratie van Intels uitbreiding op de x86-architectuur, per definitie ondersteuning voor 512bit-instructies. De zuinige E-cores die Intel tegenwoordig in zijn processors verwerkt, kunnen dergelijke grote instructies echter niet uitvoeren, en het mixen van cores die verschillende instructies wel en niet ondersteunen is niet mogelijk in moderne besturingssystemen. Daarom zag de processorfabrikant zich genoodzaakt om de volledige AVX-512-ondersteuning hardwarematig teniet te doen op zijn twaalfde en dertiende generaties Core-processors, hoewel de P-cores daar dus wel op ontworpen zijn. Andersom kon Intel hierdoor ook geen E-cores inzetten voor zijn Xeon-serverprocessors, waarin wel AVX-512-ondersteuning wordt geboden.

In de nieuwe AVX10-isa wordt het kunnen uitvoeren van 512bit-instructies met zowel integers als floating-pointgetallen optioneel en wordt ondersteuning voor 256bit-embedded rounding toegevoegd. Daardoor kan software die AVX10 ondersteunt, ook draaien op E-cores, zij het minder snel. Dat maakt de weg vrij om deze instructiesetuitbreiding beschikbaar te stellen op alle toekomstige Intel-processors, schrijft Intel in een technische paper over de nieuwe isa.

De eerste processors die AVX10 zullen ondersteunen, worden de Xeon-cpu's die tot nu toe bekendstaan onder de codenaam Granite Rapids. Waarschijnlijk komen die pas eind 2024 of begin 2025 op de markt. Consumentenprocessors met AVX10 hoeven we vermoedelijk niet ver voor die tijd te verwachten. Om achterwaartse compatibiliteit met bestaande chips te behouden, komen er twee versies van AVX10: AVX10.1 en AVX10.2. Versie 10.1 is de legacyversie, versie 10.2 voegt ondersteuning voor E-cores toe. Het idee is dat AVX10-software beide versies ondersteunt en vanzelf de juiste kiest op basis van de gedetecteerde processor.

Tegelijk met AVX10 maakt Intel de komst van Advanced Performance Extensions, afgekort APX, bekend. APX verdubbelt het aantal generieke registers van 16 naar 32, waardoor er minder loads en stores van en naar de L1-caches nodig zijn. Dat zou processors in de toekomst zowel sneller als zuiniger kunnen maken.

Reacties (72)

[PommeFritz]

Dus eigenlijk wat AMD nu al in Zen4 doet?

[marcovtjetje]

Voor zover ik weet is dat dat niet. Zen4 kan 512 bit code uitvoeren zij het met het gebruik van meerdere 256 execution units, van wat ik kan zien in de white paper worden gewoon de 512 bit registers niet gegarandeerd ondersteund op AVX10(whitepaper introductie paragraaf die AVX10/512 reserveert voor heavy duty op P only).

[dmantione]

Dat toont het bizarre aan: AMD kan AVX512 ondersteunen zonder nieuwe instructieset en ook de uitgeklede Bergamo-kernen kunnen "gewoon" AVX512. Intel zou iets dergelijks voor zijn E-kernen kunnen doen en dat zou het opnieuw overhoop halen van de x86-instructieset voorkomen.

[Dennism]

De Zen4C core 'Bergamo' is dan eigenlijk ook niet heel veel 'uitgekleed' aan, alle logic uit de normale Zen 4 kern kijkt er gewoon te zijn, maar hebben ze enkel bezuinigd op de cache en hebben ze schijnbaar de wat compacter kunnen maker qua layout, waardoor ze een 35% kleinere core hebben, met eenzelfde performance als Zen4 bij een gelijke kloksnelheid (behouden mogelijk workloads die heel erg op cache leunen, daarvan is er immers 16MB minder per iedere 8 cores).

Zie ook bijvoorbeeld deze slide van AMD en het TPU artikel erover: https://www.techpowerup.c...-4-but-with-identical-ipc

https://www.techpowerup.com/img/tURCxsYBNANET3BI.jpg

[Sp3ci3s8472]

Aanvullend aan jouw verhaal; een reden dat de Zen4C core 'Bergamo' compacter is is ook omdat ze een lagere frequency target hebben. Zie ook de volgende video van TechTechPotato (Ian Cutress van Anandtech):
https://www.youtube.com/watch?v=lVP6APKGfjY

[PommeFritz]

Ja dit is precies wat ik ook zat te denken

[SG]

Het verschil tussen Zen4 zen4dense is fat vs light core verschil zit hem dan meer in de architectuur kwa grote van de cache en compactheid van de logic met nadruk op zuinigheid ipv hoge kloks.
P vs e core is missen van extentie de AVX512.
het meest gebruikte OS windows kernel kan daar niet goed mee omgaan.
Of dat mogelijk is geen idee maar denk dat AMD niet in de positie wil dat het die logge gigant moet gan pushen en dan pas na 3 gens op gang komt waardoor enige momentum van innovatie al kop ingedrukt is.
iNtel heeft daar ook moeite mee. en volgens die AVX10... ligt meer aan compabiliteit implementatie dat runtie code met cpu detectie en ook cores on runtime kunnen detecteren en de juiste AVX of de fallback kunnen keizen.
en daarmee i iNtel weer sterk afhankelijk wat de compilers en OS firma van werk van maken. Al heeft iNtel ook zijn eigen compiler plugin.
voor AMD niet probleem zij ondersteunen dezefde istructie extentie in hun big en dense cores.

[goarilla]

Dus Zen4 vs Zen4C is zoals Pentium III versus Pentium III celeron destijds.

[Xieoxer]

AMD is gelukkig nog niet overgestapt naar E-cores. Door de komst van de E-cores is er hoop code bijgeschreven in de kernels om de schedulers zo goed mogelijk te laten beslissen welke core nu het handigste is om aan te spreken.

AVX512 is een hele toffe instructieset, waardoor complexe specifieke taken sneller uitgevoerd kan worden. Als ik nu zo lees stopt Intel er al weer mee en komt er weer met nieuwe instructieset, waardoor software ontwikkelaars weer aan de slag mogen om te proberen om de nieuwe instructieset te ondersteunen. Intel was de gene die AVX512 heeft bedacht en als eerste ondersteuning had gebouwd in hun CPU’s. Een hoop ontwikkelaars hebben toen die tijd ondersteuning gebouwd voor deze instructieset in hun softwarepakket. Rare beslissing van Intel, maar blijkbaar lukt het hun niet om het goed te implementeren in combinatie met E-cores. AMD heeft nog niet aangegeven om te gaan stoppen met AVX512, waardoor hun eigenlijk voorsprong hebben op Intel.

[Reactie gewijzigd door Xieoxer op 23 juli 2024 13:30]

[computerjunky]

Las gister ergens iets over Epyc cpu's met E-cores dus die van AMD komen er ook aan dus zo gek is het idee blijkbaar niet en AMD zal met dezelfde "problemen" te maken gaan krijgen.

[Dennism]

Dat zijn geen 'echte' E-Cores zoals Intel ze ook heeft. AMD pakt het anders aan (mogelijk zelfs beter c.q handiger) door enkel te bezuinigen op cache (de cores zijn verder gelijk aan Zen 4 cores, zie ook dit artikel: https://www.techpowerup.c...-4-but-with-identical-ipc ), waardoor het eigenlijk gewoon compactere P-Cores zijn met bijbehorende prestaties.

Daarbij mixed AMD ook (op dit moment) de cores niet, dus zou AMD sowieso niet tegen dit specifieke issue aanlopen dat Intel hiermee wil oplossen. Intel is trouwens ook bezig met ongeveer zoiets als waar AMD mee bezig is (alleen kleinere cores in een Sku). Onder de naam Sierra Forest, dit zal echter initieel met E-Cores zijn zoals we deze nu kennen, dus zonder AVX-512 support, terwijl latere generaties deze support wel zullen krijgen, waarschijnlijk zoals nu blijkt met AVX10

[Reactie gewijzigd door Dennism op 23 juli 2024 13:30]

[Hans1990]

En wat AMD ook doet is flink besparen op logic. Dat kan nu eindelijk omdat ze er een speciale CCD voor bouwen.

Als je een hardware beschrijving maakt, vertel je de synthesizer (=de compiler voor hardware) hoe snel je wilt dat het ontwerp moet draaien. De synthesizer gaat dan aan de slag met verwachte vertragingen van de verschillende gates die worden gebruikt. Een fabrikant zoals TSMC levert een PDK aan, en dat is een bibliotheek van gates op een bepaalde technologie waarbij vele type gates zijn beschreven (denk, AND, OR, XOR, maar ook varianten met inverters) en verschillende varianten met verschillende "fanouts".

Als een signaal naar meerdere ontvangers moet dan heeft die een sterkere driver nodig om niet te traag te worden. Een synthesizer probeert daarin dus een goed resultaat te vinden wat aan de gestelde eisen voldoet. In de praktijk betekent het hoe sneller iets moet werken, hoe meer gates je nodig hebt & hoe sterker de signalen moeten worden aangestuurd, en dus meer transistors(=area) & meer power.

AMD heeft met Zen 4c, naast de kleinere cache, ook die frequentie knop iets terug gedraaid. Dat bespaard direct al implementatie grootte zonder -in theorie- 1 regel code aan te passen. Een core bedoeld voor 5GHz draait al efficienter op 3GHz, omdat moderne BIOS'en ook de core spanning terug laat brengen. Maar het kan nog efficienter zijn door de core vanaf de start al te laten synthesizen voor 3GHz. Alle overhead om op 5GHz te kunnen werken kan je laten vallen. En je kan er meer cores op dezelfde area kwijt.

De reden dat dit nieuws is voor AMD, omdat ze al hun CPUs traditioneel bouwden met dezelfde CCD ontwerp. Dezelfde CCD voor een server chip waarbij de cores misschien maar 2.5-3GHz draaien, en een desktop Ryzen waarbij ze 5GHz moeten aantikken.

In feite durf ik te spreken dat Zen4c eigenlijk hun E-core variant is. Ze noemen het misschien niet zo, maar ik wel. Architectureel is het dezelfde core, met iets minder cache, maar ik verwacht ook met mindere clocks. Eigenlijk beetje zoals Intel's E-cores die niet verder komen dan mid 3GHz tot lage 4GHz. Je kan er namelijk van uit gaan dat Intel voor hun E-cores ook de clock constraint heeft verlicht om de core kleiner/zuiniger te laten zijn. Het grote verschil met Intel is dat zij daadwerkelijk een andere microarchitectuur gebruiken met andere instructieset support. Ik denk dat AMD er goed aan doet om alles gelijk te houden.

Maar.. het concept van "snelle" P-cores en "trage" E-cores zal naar mijn verwachting voor Zen4 en Zen4c gelden, maar dan in mindere mate; zeg 20-40%. Maar als dat betekent dat je 2x zoveel cores op dezelfde chip area/power budget kwijt kan, dan heeft een multi-thread applicatie nog steeds flinke winst. Voor single thread (=desktop) kan er altijd nog een tweede CCD naast, mogelijk met de extra V-cache, die piek single-thread prestaties levert.

[Reactie gewijzigd door Hans1990 op 23 juli 2024 13:30]

[CriticalHit_NL]

Gebruik AVX512 zelf dan wel niet maar vind persoonlijk de E-cores wel een fijne toevoeging, zeker voor multi-threaded taken zoals het renderen van een video kan het behoorlijk helpen, terwijl de E-cores zelf niet zoveel energie verstoken als de snellere P-cores en dus de CPU tijdens die zware taken ook maar deels belast is en dus ook koeler/stiller kan blijven doordraaien en je kan er zelfs prima tegelijkertijd een spel naast spelen en het leent zich ook goed voor x264 gamestreaming op de CPU (op de i9 13900K dan).

Het enige minpunt? Nou ja als je de E-cores stevig op 100% laat lopen ga je wel merken dat de CPU soms even wat hikken vertoont met het laden van zaken, waarschijnlijk omdat de E-cores dus een gedeelte delen met de P-cores.

Voor games kunnen ze zelfs positief uitpakken, soms negatief, maar verschillen zijn niet enorm. Grotere impact is als een ouder spel niet draait omdat er simpelweg teveel threads zijn en je kunstgrepen moet uithalen om het werkend te krijgen, maar daar zal een 7950X net zo goed last van hebben met 16+ threads.

[goarilla]

Het enige minpunt? Nou ja als je de E-cores stevig op 100% laat lopen ga je wel merken dat de CPU soms even wat hikken vertoont met het laden van zaken, waarschijnlijk omdat de E-cores dus een gedeelte delen met de P-cores.

Of de scheduler verhuist taken waardoor ze een slot cpu tijd op een (andere) core krijgen.

[Dennism]

Ze gaan niet echt stoppen met AVX-512, Dit is simpelweg na AVX1/AVX2 en AVX512 de volgende doorontwikkeling qua AVX standaard, waarbij ze er nu voor zorgen dat ze straks support voor AVX-512 niet meer hoeven uit te zetten op de P-Cores omdat de E-Cores er helemaal geen support voor hebben.

Ze gaan hiermee juist AVX512 + verdere doorontwikkelingen in nieuwe instructies naar de E-Cores brengen.

Zie ook bijvoorbeeld dit artikel van Phoronix dat wat meer duiding lijkt te geven: https://www.phoronix.com/news/Intel-AVX10

Along with detailing Advanced Performance Extensions (APX), Intel as effectively a footnote to that also disclosed another exciting addition to find with future Intel CPUs: AVX10. Most notably for consumer use is that AVX10 will enable AVX-512 capabilities across both Performance and Efficient core designs with hybrid processors.

Intel Advanced Vector Extensions 10 (AVX10) is a new ISA that includes "all the richness" of AVX-512 and additional features/capabilities while being able to work for both P and E cores. Intel says AVX10 will be "the vector ISA of choice" moving into the future.

[Louw Post]

AMD heeft hun eigen gedrocht met de 7900X3D/7950X3D.

[os-tweaker]

Het toevoegen van cache is van een totaal andere orde dan het wijzigen van een isa. Dat laatste heeft zware consequenties voor softwarecompatibiliteit, terwijl een andere cache arcitectuur doorgaans geen of nauwelijks invloed heeft op compatibiliteit.

[dmantione]

Klopt, maar Intel heeft het wel beter aangepakt door een hardwarescheduler op de chip te bouwen, terwijl bij AMD de beslissingen geheel softwarematig genomen moeten worden. Ik heb het idee dat de prestatieperikelen die je regelmatig op de 79x0X3D ziet daaruit voortkomen.

[White Feather]

Ja, Intel heeft het zeker beter aangepakt….

- Systemen met een combinatie van P- en E-cores draaien op Windows 10 ruk ten opzichte van Windows 11.

In Excel zie je gewoon dat het systeem er niet van snapt, et cpu-usage is op de E-cores een zaagtandpatroon.

Dus nee, een hardware-scheduler is niet het walhalla zonder ondersteunende software.

- Intel heeft AVX512 moeten uitzetten op de 12e en 13e generatie Core-i omdat ze het niet werkend kregen.

Maar inderdaad heeft Intel het veel beter aangepakt 😂

[dmantione]

Je antwoord zegt dus feitelijk dat de hardwarescheduler zijn werkt doet. En inderdaad alleen op Windows 11 omdat Windows 10 die scheduler niet ondersteunt. Maar dat is een argument tegen assymmetrische kernen en niet tegen een hardwarematige scheduler.

En in de basis ben ik het helemaal eens dat vanuit softwareoogpunt een uniforme architectuur met zo min mogelijk grillen en grollen gewenst is. Optimaliseren is goed, voorkomen dat optimalisaties nodig zijn is beter. Dus ik ben helemaal niet zo blij met die E-kernen, een uniforme processor geeft veel consistenter zijn maximale prestaties.

Op het moment dat je asymmetrische kernen gaat toepassen, dan denk ik dat vooralsnog de oplossing van Intel zijn meerwaarde lijkt te geven en AMD niet bewezen heeft dat het ook zonder kan.

[White Feather]

Je antwoord zegt dus feitelijk dat de hardwarescheduler zijn werkt doet. En inderdaad alleen op Windows 11 omdat Windows 10 die scheduler niet ondersteunt. Maar dat is een argument tegen assymmetrische kernen en niet tegen een hardwarematige scheduler.

Nee, dat zegt mijn antwoord helemaal niet.

Ik ben benieuwd wat jij de conclusie uit trekt dat de hardwarematige scheduler werkt.

Voor hetzelfde geld doet hij geen hol en aangezien hij al software nodig heeft om te goed te werken (Windows 11 vs Windows 10), is volstrekt niet uit te sluiten dat het puur door de software goed werkt.

[dmantione]

Ik denk dat het wel een redelijke aanname is dat omdat we weten dat Windows 11 de hardwaregeassisteerde scheduler gebruikt het ook de scheduler is die voor de winst zorgt. Plus dat het bij AMD niet zo vanzelfsprekend is, als het software was, zou AMD er net goed goed van moeten profiteren.

[goarilla]

En in de basis ben ik het helemaal eens dat vanuit softwareoogpunt een uniforme architectuur met zo min mogelijk grillen en grollen gewenst is. Optimaliseren is goed, voorkomen dat optimalisaties nodig zijn is beter. Dus ik ben helemaal niet zo blij met die E-kernen, een uniforme processor geeft veel consistenter zijn maximale prestaties.

Intel mag wel eens leren van AMD door te stoppen met iedere feature bijna willekeurig aan of uit te zettenn en schijnbaar zoveel mogelijk SKUs creeert waardoor m'n door het bos de bomen niet meer ziet. AVX-10 moet gewoon in alle CPUs zitten vanaf nu aan, ook in de servers, embedded, ...

[Dennism]

Ja, Intel heeft het zeker beter aangepakt….

- Systemen met een combinatie van P- en E-cores draaien op Windows 10 ruk ten opzichte van Windows 11.

In Excel zie je gewoon dat het systeem er niet van snapt, et cpu-usage is op de E-cores een zaagtandpatroon.

Dus nee, een hardware-scheduler is niet het walhalla zonder ondersteunende software.

Het was dan ook algemeen bekend dat MS de optimalisaties voor de thread director niet allemaal zou doorvoeren naar Windows 10. Over het algemeen draait het trouwens prima en in vermoed ik 90%+ van de zakelijke workloads die ik bekeken heb voor / bij onze klanten zit er geen negatief verschil in performance tussen Windows 10 en Windows 11, bij gebruik van 12/13th gen Sku's. Er zijn echter een paar uitzonderingen, maar goed, dat het kan voorkomen weet je van te voren, en daar pas je dan ook of wel je aanschaf op aan, of je OS versie.

Ik kan trouwens je excel probleem niet reproduceren met een zwaar sheet.

- Intel heeft AVX512 moeten uitzetten op de 12e en 13e generatie Core-i omdat ze het niet werkend kregen.

Het staat uit omdat de E-Cores het niet supporten en omdat de supported instructie sets gelijk moeten zijn over alle cores in de CPU. Het is niet zo dat het echter niet werkt in de P-Cores, in het begin (12th gen) kon je het zelfs via de bios aanzetten wanneer je de E-Cores uitschakelde. Vanaf latere productie batches 12th gen en de 13th gen zet Intel het echter af-fabriek uit, maar de hardware beschikt in principe gewoon over werkende AVX-512 units.

[Reactie gewijzigd door Dennism op 23 juli 2024 13:30]

[SG]

Het gaat hier om samenwerking tussen iNTel en Microsoft.
Die windows kernel is niet Big/little voorbereid. kan zoiets als cpu met afwijkende insructie extenties ook niet aan. is ook voor home en pro versie ook niet numa aware.
High-performance prog language C++ is de standard libary en parallel upport ook niet door ontwikkeld als i met elke inarnatie van de next c++ deze op veel vlakken verder uitgebreid. maar numa aware thread beheer zul diep moeten uitvogelen van third party libaries en hoe Windows je thread laat beheren. wat ook lastig is.
Dan is dus de vraag zij game zo lastig numa big little MT aware of goed te laten schalen. of is de OS winapi c++ beperkt en vergt het heel veel werk . Of zijn game ivm hun compexiteit en data variatie moeilijk te schalen of is mix.
Pro software verslik zig zelden in big little en ccd en cache verschil tussen chiplets.

[hikashuri]

Ik heb mijn 13900K op windows 10 gebruikt voor een tijdje en er was letterlijk geen verschil met windows 11. Vele mensen die dit trouwens professioneel getest hebben, zeggen hetzelfde op dit vlak, enkel in heel erg specifieke gevallen draaiden ze net iets minder.

[marcovtjetje]

Voor zover ik weet is Thread Director een fijn verdeeld informatie acquisitie mechanisme dat de (software ) scheduler van informatie voorziet. Niet een hardware scheduler op zichzelf?

[dmantione]

Dat is juist, maar AMD heeft een dergelijke voorziening niet en ik denk dat wat we in benchmarks zien hiermee te maken heeft.

[marcovtjetje]

Misschien, maar voor AMD is dat (asymmetrische opbouw) momenteel nog een side show die alleen de paar multi core-chiplets processoren met 3D cache raakt.

Aan de andere kant kan je misschien met een thread director aan de AMD kant ook de cross-die latency wat (makkelijker) optimaliseren.

Intel moest wel omdat ze deze richting zijn opgegaan, omdat ze simpelweg niet zoveel P cores kosteneffectief konden toevoegen als AMD.

[Louw Post]

Het ging me meer om het eerste stukje over de scheduler, die bij de 7900X3D/7950X3D ook moet kijken welke cores er nou gebruikt moeten worden (met of zonder extra cache). Dat lijkt me enigszins vergelijkbaar als bij Intel, waarbij er gekeken moet worden of de P of E cores gebruikt moeten worden.

[SG]

verschil is van numa CCD of 3vcache is je verliest wat performance door latency .
een ecore laat system crachen als er een of meer AVX512 voorgeschoteld krijgt.

[Prince]

Ik begrijp dat de E-cores een technische uitdaging bieden en een hoop werk met zich meebrengen, maar ik kan niet ontkennen dat ik de komst hiervan uiterst interessant vind.

Ik kan nu een high availability cluster maken voor mijn thuis-lab dat minder stroom verbruikt dan 1 "normale" processor en vaak in mijn geval nog sneller is ook. Sneller omdat ik vele kleine taakjes heb (denk aan bvb Home Assistant die scriptjes doorloopt elke paar seconden) en nodejs REST API's e.d., maar niet doe aan bvb video encoding of rendering.

[ctrl-tab]

Eens. de N100 is een heel interessante opvolger van de oude celerons.
Ik ga binnenkort mijn hele homelab upgraden van j4105 j5040 naar n100.

Edit: Terwijl ik dit type vraag ik me af of het niet interessant kan zijn voor normale desktop cpu te gaan, en simpelweg de P cores uit te schakelen. Zou dit vergelijkbaar stroomverbruik als gevolg hebben?
Dat zou de keuze met name op gebied van moederborden , connectiviteit en geheugen enorm verhogen!

Antwoord op mezelf: ja dat zou wel eens interessant kunnen zijn, als je de e cores ook nog eens wat downclocked: https://www.youtube.com/watch?v=YBLZtuJbISg

[Reactie gewijzigd door ctrl-tab op 23 juli 2024 13:30]

[Prince]

Ik vond als je kijkt naar prijs kwaliteit dat de N200 interessanter was; de N305 vond ik dan weer te duur voor wat die deed. Wel spijtig van de limiet van 16GB geheugen.

Iets met een "Intel Core i5-10210U" leek me ook wel wat, verbruikt wel meer, maar geeft meer mogelijkheden.

[ctrl-tab]

Nadeel van n200 is dat ik er geen moederbordjes voor vind. Alleen Aliexpress mini pcs.
De n100 is in een aantal configuraties beschikbaar in mini itx of mAtx formaat.

Die i5 is ook wel interessant, maar daar geldt hetzelfde voor.

[Prince]

Ik had over de N100 en N200 geleerd via ServeTheHome (https://www.youtube.com/watch?v=58nVTNYrJ3E) en die van AliExpress waren eigenlijk helemaal niet slecht, zeker niet voor de prijs.
Zelfs het geheugen dat erin zit als je het via daar koopt is van Crucial. Je krijgt gewoon een A-merk als je koopt in China...

[marcovtjetje]

Maar heb je daar echt E-cores voor nodig, of kan je ook gewoon een standaard CPU onderklokken?

AMD 7xxx CPUs kan je geloof ik in de bios op een andere TDP zetten. En dan nog zijn het volle cores die de 4GHz halen, dus zeker niet lam. (hoeveel je met onderclocken van Intel kan bereiken weet ik zo gauw niet)

[Reactie gewijzigd door marcovtjetje op 23 juli 2024 13:30]

[Prince]

Voor de prijs van de goedkoopste AMD 7xxx barebone die ik kon vinden (~600€) kan ik 2 barebones kopen van de goedkoopste i3-1220P processoren. (~300€). Deze laatste zijn dan 2x 10 cores die ik ter beschikking heb 2x (2 P + 8 E).

[marcovtjetje]

Een i3-1220P is 12e generatie. dus waarom je een oudere Intel met de nieuwste AMD generatie vergelijkt snap ik niet.

Ja, 7x00 zijn duur. Maar ik heb een compleet HP systeem met 5600g voor Eur 350 gekocht. (512GB SSD, 8GB geheugen)

[Prince]

Ik vergelijk met wat jij aanhaalt. Ik weet dat in mijn use case ik meer baat heb met meerdere cores en niet speciaal met meer kloksnelheid. Als die dan nog eens zuinig zijn ook, dan heeft dat zeker mijn voorkeur.

Als jij een betere vervanging weet voor de lage kostprijs, laag wattage en vele cores; dan hoor ik het graag.

De 5600G heeft een 65W TDP; de N200 heeft 6W TDP; daar kan je er haast 11 van draaien voor hetzelfde TDP "budget".

[SG]

een CPU met 2 Pcores en 8 ecores met matige kloks zou ook zeer zuinig kunnen zijn en ook meer alround. uitgezonderd de grote games en prosoftware.

[SuperDre]

Er zijn maar weinig software ontwikkelaars die 'weer aan de slag mogen' om te proberen de nieuwe instructieset te ondersteunen. Meeste ontwikkelaars werken niet op dat niveau en maken puur gebruik van libraries die op een veel hoger niveau werken. het is dus maar een handjevol developers die werkelijk aan de slag moeten, maar die hebben dat waarschijnlijk al lang gedaan.

[dmantione]

De kwestie met SIMD is, is dat de compiler de vectorisatie maar tot op beperkte hoogte voor je kan doen. Code moet vectoriseerbaar voor de compiler gemaakt worden. Inderdaad zijn er hele volksstammen programmeurs die zich er niet mee bezig houden, maar dat is dan ook een belangrijke reden waarom er zoveel code is die geen prestatieverbetering bij AVX512 laat zien.

Een verdere reden is, dat zelfs als de compiler de code kan vectoriseren, de executable dan wel aparte codepaden voor SSE2, AVX256 en AVX512 moet bevatten (d.w.z. met een voldoende moderne compiler gecompileerd en de betreffende codepaden runtime ingeschakeld).

Soms spendeert een programma inderdaad dusdanig veel tijd in een bibliotheek dat installatie van een nieuwe bibliotheek voldoende is, maar dat is maar een beperkt deel van de software.

[marcovtjetje]

Tis niet alleen vectorisatie, maar ook heel vaak dat het gewoon geen zin heeft omdat geheugen de bottleneck is, en niet de snelheid van de loop.

Mijn image routines zijn voor simpele operaties even snel voor SSE als AVX256

Sterker nog, we gebruiken AVX niet eens in productie (al hebben we wel wat tenders ermee gedaan).

Daarnaast is het gebrek aan universele uitrol ook een probleem. Het is niet zo lang geleden dat er nog AVX2 loze CPUs verkocht werden. In tegenstelling tot HPC gebruiken wij doorgaans sub $100 processoren voor standaard (vision) projecten..Dat standaard model was nog niet zo heel lang geleden een Athlon 200GE (nu geloof ik vn Intel 12 generatie celerons)

[Reactie gewijzigd door marcovtjetje op 23 juli 2024 13:30]

[SG]

Toen ik nog met DX9 code aan klooien was had ik een dx sdk depricated math libary vervangen voor dx9 courantere. En mooie is dat je niet zelf matrix math en SIMD moet doen. Maar dat je functies gebruikt van die math libary. Het zullen dus vooral de developers van die libaries die te maken krijgen met AVX10... als gebruiker merk je er niet veel van. Als als dev zelf eigen SIMD code blokken ontwikkeld dan krijg je sowie zo net alleen met AMD vs intel detectie maar ook generaties van architecturen en extenties.

[bantoo]

Niet alleen dat maar de mensen die patches voor bijvoorbeeld AVX-512 support toevoegen aan compilers en populaire libraries hebben zeer vaak een @intel of een @arm email adres. Storm in een glas water.

[laurxp]

Dit voelt als een grote nutteloze hack, alleen maar om arbitraire beperkingen in E cores to omzeilen. Het is een downgrade ten opzichte van AVX512.

Het "duurste" gedeelte van AVX512 is dat je de instructies moet kunnen decoden, en dat is nu alsnog nodig voor de E cores omdat je in essentie alsnog alle features van AVX512 gaat ondersteunen. Het enige dat je wint, is dat de executie-eenheden beperkt kunnen blijven tot 256 bits in plaats van de volle 512 bits.

De grap is dat de Zen 4 AVX512 support "double pumped" is, wat inhoud dat de CPU zelf de 512-bit instructie opsplitst in twee 256-bit instructies die na elkaar worden uitgevoerd! Waarom zou Intel deze oplossing niet kunnen gebruiken voor E cores?

Ik krijg héél sterk het idee dat Intel dit alleen doet om "echt" AVX512 beperkt te houden tot dure workstation en server CPUs. Aan de andere kant, de performance benefits van nieuwe AVX512 features zoals masking zijn onmogelijk te missen - dus proberen ze nu consumenten op te schepen met een halfbakken tussenoplossing.

[Novermars_]

>Het "duurste" gedeelte van AVX512 is dat je de instructies moet kunnen decoden

Nee, het duurste gedeelte is de hoeveelheid die-space die je aan een E-core moet toevoegen om AVX512 te ondersteunen, wat nog altijd een niche technologie is en zal blijven. Nu zijn 4 E-cores net iets groter dan 1 P-core, maar geven multi-threaded ongeveer 1,6-1,8x performance. Als je door AVX512 ondersteuning nog maar 3 E-cores kan gebruiken op dezelfde ruimte, dan kan je net zo goed stoppen en weer terug gaan naar enkel P-cores met een enorm verlies aan MT performance.

E-cores zijn die-space efficiënt voor MT taken, dat is hun hele punt.

>Ik krijg héél sterk het idee dat Intel dit alleen doet om "echt" AVX512 beperkt te houden tot dure workstation en server CPUs.

Aangezien de support voor AVX512 alleen fused-off is in de golden/raptor cove cores, lijkt me dit onwaarschijnlijk. Het is gewoon collateral damage geweest van de keuze voor een hybrid CPU.

[laurxp]

Kijk eens naar het ruimtegebruik van een CPU core. De daadwerkelijke rekeneenheden nemen heel weinig ruimte in, en er is veel meer nodig voor decode, branch prediction, en cache. Dát is waar de kosten zitten, en de eerste twee worden een stuk complexer door deze nieuwe instructieset.

Als je AVX512 implementeert in microcode (zoals AMD doet), heb je er maar een minieme hoeveelheid extra ruimte voor nodig - helemaal als je tóch al de hardware nodig hebt voor AVX512-achtige executie zoals deze nieuwe AVX10 instructieset vereist. De core zal hier eerder 1% groter van worden dan de door jou gesuggereerde 33%.

AVX512 is alléén niche omdat Intel het jarenlang kunstmatig beperkt heeft tot enterprice CPUs, en juist door zulke grappen uit te halen zorgt je er voor dat het niet populair wordt.

[Novermars_]

Volgens mijn bronnen 1) https://mastodon.gamedev.place/@rygorous/110572829749524388 en 2) de CPU architecten bij Intel waarmee ik elke dag werk, zijn hoge kosten aan die-space de reden dat de E-cores geen AVX512 hebben.

The main reason you don't see AVX-512 in smaller cores is basically that. They literally don't have the area budget for a register file so huge you can see it from space

>AVX512 is alléén niche omdat Intel het jarenlang kunstmatig beperkt heeft tot enterprice CPUs, en juist door zulke grappen uit te halen zorgt je er voor dat het niet populair wordt.

Oh, gelukkig was er AMD die het natuurlijk wel geïmplementeerd had... Voor 99% van de consumenten maakt het niet uit of er AVX512 is of niet. Voor Intel/AMD betekent grotere cores = meer defects op een wafer en meer kosten, dus het is niet heel gek dat beide partijen het liever niet in hun client CPUs hebben. De enige reden dat AMD AVX512 heeft in hun client CPUs is omdat ze dezelfde cores gebruiken in server/hpc.

[laurxp]

https://mastodon.gamedev.place/@rygorous/110572829749524388

Die post mist het meest belangrijke deel: masking! Dat maakt AVX512 in één klap een héél stuk zinvoller voor consumententoepassingen.

The main reason you don't see AVX-512 in smaller cores is basically that. They literally don't have the area budget for a register file so huge you can see it from space

Dat klopt zeker - maar ondertussen stopt Intel met Advanced Performance Extensions wel een hoop extra registers in de cores. Blijkbaar is het ruimtebudget toch niet zo héél krap. En de Gracemont E-cores hebben een 207-entry 128-bit vector RF. Dat is méér dan genoeg voor een basic fallback AVX512 implementatie.

Oh, gelukkig was er AMD die het natuurlijk wel geïmplementeerd had

Intel had in 2018 met Cannon Lake al een consumer CPU met AVX512. Sindsdien zijn alle architecturen in staat geweest om AVX512 uit te voeren - tot het hele debacle met Alder Lake waarbij de P-cores fysiek in staat zijn om AVX512 uit te voeren, maar het kunstmatig met fuses is uit gezet. AMD loopt inderdaad achter met AVX512 ondersteuning, maar ze kiezen er tenminste niet voor om hun CPUs vleugellam te maken.

Voor Intel/AMD betekent grotere cores = meer defects op een wafer en meer kosten

Absoluut. Zie daarom ook: Chiplets. En dit maakt het gelijk ook zo bizar dat ze dus een flink deel van de Golden Cove E-cores uitzetten. Het plan was altijd om Alder Lake gewoon AVX512 te geven.

Voor 99% van de consumenten maakt het niet uit of er AVX512 is of niet

99% van de consumenten weet niet eens welke CPU er in hun computer zit. Op de achtergrond maakt een hoop code stiekem toch gewoon gebruik van AVX512 als het de kans krijgt - en de consumenten vinden het wél leuk als hun computer daardoor sneller is.

Het recente Zenbleed-probleem maakt héél duidelijk dat AVX toch flink in gebruik is, en niet alleen maar voor high-performance data-analyse. Je kan er bijvoorbeeld ook een bizar snelle JSON parser van maken, en iets zegt me dat de meeste consumenten een snellere webbrowser wel kunnen waarderen.

De enige reden dat AMD AVX512 heeft in hun client CPUs is omdat ze dezelfde cores gebruiken in server/hpc.

Uiteraard. Waarom zou je twee compleet aparte cores ontwikkelen voor toch redelijk vergelijkbare toepassingen? Vergis je niet, Intel gebruikt ook gewoon praktisch dezelfde cores voor servers als voor desktops! Golden Cove zit niet alleen met Alder Lake in consumentenproducten, maar bijvoorbeeld met Sapphire Rapids ook in een hoop Xeons.

[Novermars_]

Die post mist het meest belangrijke deel: masking! Dat maakt AVX512 in één klap een héél stuk zinvoller voor consumententoepassingen.

Maar dit krijg je nu dus met AVX10? Alle nieuwe instructies, maar zonder de extra brede registers. Dat is het hele idee van AVX10: Wel alle goodies qua nuttige instructies uit AVX512, zonder de enorme area penalty.

Dat klopt zeker - maar ondertussen stopt Intel met Advanced Performance Extensions wel een hoop extra registers in de cores. Blijkbaar is het ruimtebudget toch niet zo héél krap.

Alle code (die gecompileerd is voor APX, of wier runtime gecompileerd is voor APX) heeft baat bij deze extra registers en andere functionaliteit. Daarnaast vermoed ik dat het wel meevalt met hoeveel extra die-space je hiervoor moet gebruiken, maar heb hiervoor helaas geen publieke bronnen.

En de Gracemont E-cores hebben een 207-entry 128-bit vector RF. Dat is méér dan genoeg voor een basic fallback AVX512 implementatie.

Maar dan zit je weer met een heterogene situatie met alle scheduling (en validatie) problemen die daarbij horen. Klinkt niet als een upgrade vanuit het perspectief van Intel.

Intel had in 2018 met Cannon Lake al een consumer CPU met AVX512. Sindsdien zijn alle architecturen in staat geweest om AVX512 uit te voeren

Met enorme penalties vanwege oververhitting/downclocken/... en ook slechts gedeeltelijk geïmplementeerd. En toch wordt AVX512 zelden gebruikt, ondanks de voordelen.

Absoluut. Zie daarom ook: Chiplets. En dit maakt het gelijk ook zo bizar dat ze dus een flink deel van de Golden Cove E-cores uitzetten. Het plan was altijd om Alder Lake gewoon AVX512 te geven.

Je bekijkt het vanaf de verkeerde kant. Het was blijkbaar goedkoper/realistischer (SW matig) om het uit te schakelen in glc dan het te implementeren in gmt of het via software te regelen. Je kan er vanuit gaan dat hier door Intel naar gekeken is. En als je de Zen4 reviews op Tweakers leest waar ook een paar AVX512 tests worden gebruikt, dan kan je je misschien voorstellen dat Intel niet blij is met het gebrek aan AVX512. Als Intel de hele stack had (zoals Apple), dan was het misschien anders geweest. Gezien de problemen die Intel heeft (gehad) de laatste jaren, is de conservatieve keuze om het uit te schakelen geen onlogische.

Het recente Zenbleed-probleem maakt héél duidelijk dat AVX toch flink in gebruik is, en niet alleen maar voor high-performance data-analyse. Je kan er bijvoorbeeld ook een bizar snelle JSON parser van maken, en iets zegt me dat de meeste consumenten een snellere webbrowser wel kunnen waarderen.

AVX(2) wordt enorm veel gebruikt, maar daar is ook al jaren uniforme HW support voor. AVX512 komt vanuit de Xeon Phi tijd, kwam toen naar Intel's Core architecture en is nu pas met Zen4 uit 2022 beschikbaar op AMDs hardware. Dus buiten gespecialiseerde domeinen (data analyse, rendering, CAD,...) hadden veel ontwikkelaars geen zin om het te implementeren, zeker omdat de performance uplift klein is tov AVX2 en in het algemeen klein is op applicatie niveau.

Uiteraard. Waarom zou je twee compleet aparte cores ontwikkelen voor toch redelijk vergelijkbare toepassingen?

Omdat Client een marge business is en je dus je dies zo klein mogelijk wilt houden maar server/workstation een performance business is waar het logisch kan zijn om wat extra die-space te investeren in een betere performance. Zie ook alle accelerators in SPR die niet in client zitten.

En kijk naar Zen4 en Zen4c, Intel had het geluk/pech dat ze ook de Atom IP hebben die ze konden gebruiken.

[computerjunky]

Precies buiten servers om hebben de meeste er helemaal niets aan. Die die space zou al beter benut zijn aan een veel betere geheugen controller die quad channel memory aan kan op 10.000 mt/s. Daar hebben veel meen mensen wat aan ten opzichte van AVX512.

Iedereen ging ook steigeren toen het uit cpu's gehaald werd bedoeld voor een markt die er eigenlijk totaal niets aan heeft. Mij boeit het helemaal niets omdat ik het toch nooit zal gebruiken met wat gamen en foto/video editen.

[marcovtjetje]

en erger nog, op Zen4 is AVX512 in veel omstandigheden sneller dan AVX256, simpelweg omdat je de 16byte/cycle decoder bottleneck vermijdt. Als je uiteindelijk niet geheugen gelimiteerd bent (zoals b.v. met image transformaties).

[- peter -]

Ja, snap het niet hoor. Moet weer allerlei code toegevoegd worden om specifiek AVX10 te supporten. Schiet niet echt op zo.

[SRI]

Waarschijnlijk doet de compiler al dat werk gewoon voor jou. Ik zie het probleem niet.

[- peter -]

Om echt optimaal gebruik te maken van dat soort instructiesets heb je meestal intrinsics nodig, oftewel vrij handmatig alle AVX512 commands aanroepen. Dus dat zal hier ook het geval zijn. Nu versplinterd dit dus weer tussen AVX512 en AVX10, in plaats van dat alle software libraries gewoon goede support voor 1 standaard hebben.

[laurxp]

Dat zal hier wel meevallen. De overlap tussen AVX512 en AVX10 is enorm groot, dus het is vrij triviaal om een variant van de intrinsics te maken die op beide werkt. Het enige probleem is dan dat je eigenlijk beide versies in je binary wil hebben om tijdens runtime te kunnen switchen....

[hooibergje]

Dat is niet het werk van de compiler, maar van de microcode van het CPU. Die gaat uiteindelijk rekenwerk aan cores toewijzen. De compiler gaat tot 'ik wil graag deze instructies doorgerekend hebben'.

[laurxp]

Nee, dat is niet hoe microcode werkt, en het OS kent rekenwerk toe aan de cores.

Om gebruik te maken van deze nieuwe instructies is er absoluut compiler support nodig, of je zal zelf met intrinsics in feite handmatig de assembly moeten schrijven. Als je compiler geen assembly uitpoept die deze instructies gebruikt, zal de CPU niet magisch besluiten om er tóch iets mee te doen.

[uiltje]

Yep, dat gaat weer #ifdef'jes stapelen worden in veel libs.

[Hyronymus]

Oops, was een reactie op peter

[Reactie gewijzigd door Hyronymus op 23 juli 2024 13:30]

[Prince]

Intel ligt onder vuur omdat AMD veel energiezuiniger is; Intel heeft daar wel een oplossing voor (de E-cores), maar dit stond in de weg.
Ze hebben daar nu een oplossing voor gemaakt en kunnen opnieuw concurrentieel zijn met AMD.
Los van waar jouw voorkeur ligt (AMD vs Intel) hebben we beiden nodig; zijn zijn hét voorbeeld van wat concurrentie kan doen aan de prijs en de snelheid van innovatie. Indien de servermarkt bij Intel wegvalt, dan zou het wel eens erg snel een negatieve richting kunnen uit gaan met Intel...

[CriticalHit_NL]

Ligt er maar net aan hoe je de CPU instelt, out-of-the-box is het wel een stroomvreter met de hogere workloads.

Voor games is het niet eens zo erg als het lijkt, de CPU (i9 13900K) wordt maar voor een fractie gebruikt vaak en dus zit deze veelal tussen de 60-120W liggend aan hoe zwaar het spel is, en dan heb ik er een -0.06v undervolt op zitten, maximale workloads zoals Cinebench zo'n 290W is dan de piek.

Als ik alle cores forceer op 3Ghz dan speelt hij games af met maximaal zo'n 45W terwijl zoiets als GTA V gewoon nog 100fps kan halen op Max. Idle op default eerder zo'n 45W maar anders zelfs 15-20W.

[YoMarK]

Dit is vooral relevant voor de servermarkt (vele tientallen cores per socket) waar het gewoon een feit is dat intel met minder performance cores gewoon veel sneller tegen TDP limieten aanloopt dan AMD.
Denk daarnaast aan stroomvoorziening en koeling van een 19inch rack vol met servers. Je hebt bij intel gewoon merkbaar meer ruimte, racks, koeling, etc.. nodig voor dezelfde performance.

Ze zijn in de serverwereld in tegenstelling tot de desktop(waar het de meeste mensen geen reet uitmaakt als een processor als een 13900k met 8 performance cores effe, of wat langer, piekt op 300 watt)/laptop markten echt de aansluiting met AMD en ook sommige ARM implementaties kwijt voor 95% van de worksloads.
Hun e-cores zouden hier kunnen helpen, maar "missen" b.v. AVX512 waardoor die bij bepaalde taken dus weer veel minder goed werken.

Edit: Typo, aanvulling.

[Reactie gewijzigd door YoMarK op 23 juli 2024 13:30]

[Hyronymus]

Hoe wil je vernieuwde technieken dan aansturen? Met drivers van Windows 3.11?

[Jan Onderwater]

Volgens mij hangt dit samen met het nieuws dat Intel Arrow Lake geen Hypertreading meer hebben.
Volgens mij zit het zo, wordt graag gecorrigeerd als ik het mis heb
Processoren hebben meerdere cores tegenwoordig, daarom Single Core Performance vs Multi Core performance.
Hoe meer cores, hoe meer warmte er geproduceerd wordt bij dezelfde kloksnelheid, daarom kan je Processoren met bv 4 of 8 cores hoger tackten dan eentje met 32 of 64 Cores.

Meer cores maken de boel sneller? Nou, ja en nee, als de SW die je er op draait gebruik maakt cq gebruik kan maken van vele cores dan ja. Denk aan een server, waar veel mensen inloggen, meer cores kunnen dan meer requests afhandelen. Multithreading, meerdere threads worden paralel uitgevoerd

Maar andere software is van ontwerp of wat het doet gelimiteerd in hoeveel cores er optimaal gebruikt kunnen worden, soms is dat er maar 1. Dan verslaat Kloksnelheid multicore,

Maar nu hebben we het dan over Hyper Threading.
Bij een complex X86 processor wordt bij een opdracht X maar een deel van de core gebruikt, dat deel dat het commando uitvoert. Dat betekend dat een ander deel staat te nietsen. Daarvoor bedacht intel haar Hyper Threading (c) om delen die niet gebruikt worden toch te gebruiken. Dit gaf performance winst overall, 30% ongeveer.

Echter, dit werkt alleen bij complexe cores, bij de ARM ontwerpen van Apple bijvoorbeeld is dat niet van toepassing, er staan geen delen te nietsen, hij is optimaal ontworpen, mede doordat er minder instructies zijn, die minder complex zijn.

Op een X86 kunnen Instructies die naar de Core gaan een lengte hebben tussen 1 en 15 Bytes, die moeten dus eerst worden bekeken waar het begin en eind is van de instructie, door een decoder.
Iedere ARM Instructie is altijd 4 Bytes. De chip hoeft de Instructie dus niet te decoderen en te analyseren om te kijken waar deze begint en eindigt zoals bij een X86. Deze decoders moeten dus ook kijken of de instructie in de hyper Treading past, kan die worden uitgevoerd tegelijk met de vorige of volgende instructie.
Dit betekent dat meer dan 4 Decoders op een x86 veel te complex wordt, maar op een ARM kan de hoeveelheid decoders zo groot worden gemaakt als de Processoren kunnen verwerken, er is daar niet echt sprake van een limiet door complexiteit.
Decoders zijn dus een bottleneck, als die sneller en meer paralel zouden werken, kan je meer instructies naar de Cores sturen

Het zou goed kunnen zijn dat als je hyper Threading laat vallen, je het ontwerp van de decoders minder complex maakt en meer decoders in de chip kan zetten en je de instructiebuffer groter maakt, waardoor je de bottleneck van de instructiebuffer kleiner maakt en de cores meer instructies krijgen om te verwerken, na elkaar ipv binnen 1 clockcycle paralel in Hyperthreading.

Dit past met een nieuwe instuctieset

[ari3]

Wat is nu echt het voordeel van enumeratie t.o.v. CPU flags (CPUID instructie) uitlezen? Een besturingssysteem wil achterhalen welke instructieset(s) een CPU core ondersteund. Nu komt er een tweede manier om hetzelfde te achterhalen, met welke doel eigenlijk? Nu moet de Linux kernel twee manieren ondersteunen...

Intel kennende komt er een CPUID vlag die aangeeft dat je een enumeratie instructie kan gebruiken...

[Reactie gewijzigd door ari3 op 23 juli 2024 13:30]

[Mijzelf]

Ik zie niet hoe dit het probleem oplost. Als mijn software heeft gedetecteerd dat hij op een P core draait, en dus 512 bits instructies kan gebruiken, wat houd de thread scheduler dan tegen om hem op een E core te reschedulen?
Als ik mijn thread kan 'locken' op een P core, was deze constructie helemaal niet nodig, dan hoefde je alleen een andere CPUID terug te krijgen op een E core dan op een P core.

[dmantione]

Ik vermoed dat dit een x86-versie is van wat ARM met zijn SVE-instructieset doet: Met SVE kun je code schrijven zonder dat je weet hoe breed het register is. Stel je moet een array 32-bit getallen opstellen dan laadt je net zoveel 32-bit getallen uit het geheugen als er in je register passen. Vervolgens verhoog je je pointer met de breedte van het register.

In conventionele code tel je een constant getal op bij je pointer. ARM SVE heeft instructies dat de processor de breedte van het register invult en je op die manier de array van getallen kunt optellen, zonder enige aanname over de breedte van het register.

Vervolgens kan dezelfde code op een processor met een 128-, 256-, 512- of 1024-bit FPU uitgevoerd worden die er van kunnen profiteren zonder dat ze eerst moeten detecteren op welke processor het draait. Op x86 moet je tot nog toe aparte code bouwen voor elk van de FPU-typen, CPUID gebruiken en aan de hand daarvan de juiste code aanroepen.

[marcovtjetje]

Nee, hoewel dat er vanwege de "128-bit lanes" in AVX256+ al een beetje ingeslopen (tevens de reden dat AMD's doublepumped werkt), zit dat nog niet op instructie niveau.

En Intel lijkt aan te geven dat 512 vector gebruik NIET op AVX10/256 werkt.

Ik had eerder gehoord dat Intel wel met iets SVE achtigs bezig was, en dacht dat ook direct. Maar het lijkt meer alsof AVX10 gewoon AVX512 splitsen in een 256 en 256+512 subset met wat addities om de 256 subset ook rounding te geven, en tevens depreciatie van het gebalkaniseerde merk "AVX512"

[Reactie gewijzigd door marcovtjetje op 23 juli 2024 13:30]

[Dennism]

Ik haal hier uit dat de E-Cores een afgeslankte versie krijgen die inderdaad maximaal met 256 bits vectoren werkt, terwijl de P-Cores wel 512 bits vectoren kunnen verwerken, zij het optioneel. Misschien dat je straks op de E-cores hetzelfde gaat zien als met eerdere Zen generaties, waar de AVX performance ook lager was omdat ze zaken opsplitsten? Terwijl dan, wanneer zo ingesteld de P-Cores wel op 'volle kracht' AVX512 (en nieuwer) kunnen doen.

Voordeel blijft dan echter verwacht ik wel dat dit altijd beter zal zijn dan het hardware matig uitzetten van de AVX-512 units op consumenten Sku's zoals nu gebeurt, iets dat gewoon zonder is van de die space die gebruikt moet worden.

Part of making AVX10 suitable for both P and E cores is that the converged version has a maximum vector length of 256-bits and found with the E cores while P cores will have optional 512-bit vector use.

https://www.phoronix.com/news/Intel-AVX10