Intel gaat AVX-512-ondersteuning op Alder Lake-cpu's hardwarematig uitschakelen

Intel gaat AVX-512-ondersteuning hardwarematig uitschakelen in nieuwe revisies van zijn Alder Lake-processors. Dat bevestigt het bedrijf tegenover Tom's Hardware. AVX-512 werd officieel al niet ondersteund op de chips, maar was via een omweg wel bruikbaar op Alder Lake.

Een anonieme bron meldde aan Tom's Hardware dat AVX-512 volledig is uitgeschakeld in nieuwere opleveringen van Intels Alder Lake-non-K-processors. Dit is vervolgens door Intel bevestigd. "Hoewel AVX-512 niet fuse-disabled was op bepaalde vroege Alder Lake-desktopproducten, is Intel van plan om dat voortaan wel te doen op Alder Lake-producten", vertelt een woordvoerder van het bedrijf aan Tom's Hardware.

Daarmee wordt AVX-512 nu hardwarematig uitgeschakeld door Intel, door een interne zekering op Alder Lake-cpu's te laten springen. Eerder was AVX-512 al softwarematig uitgeschakeld. Bij de introductie van Alder Lake zei Intel dat AVX-512 niet werd ondersteund vanwege de hybride architectuur van de cpu's, met twee verschillende soorten cores. Verschillende moederbordfabrikanten introduceerden echter een workaround om AVX-512 in te schakelen, in de vorm van een bios-instelling die Alder Lakes E-cores uitschakelde.

In januari kwam Intel al met een bijgewerkte microcode, die verstrekt werd via bios-updates en deze workaround ongedaan maakte. Daarop kwam MSI met een optie om gemakkelijk te wisselen tussen oude en nieuwe bios-versies, waarmee gebruikers de ondersteuning weer konden inschakelen, schrijft Tom's Hardware. In de toekomst moeten gebruikers dus een oude bios-versie en een oudere Alder Lake-chip hebben om AVX-512 in te zetten.

AVX-512 is een instructiesetuitbreiding van Intel, die voornamelijk is bedoeld voor het versnellen van professionele workloads als 3d-modelleren, wetenschappelijke simulaties, deep learning en audio- en videoverwerking. De extensie werd ondersteund op Intels voorgaande Rocket Lake-processors voor consumenten en ook op Xeon-cpu's voor workstations en high-performance computing.

Door Daan van Monsjou

Nieuwsredacteur

03-03-2022 • 11:18

68

Lees meer

Reacties (68)

68
67
40
10
0
25
Wijzig sortering
ik snap dat dit niet iets wat de meeste consumenten uberhaupt zouden gebruiken, maar om het nou te bricken vind ik een beetje raar.

als het er niet in wil, dan laat je de silicon die nodig is er toch uit? scheelt silicon, scheelt kosten, en scheelt de consument een product waarvan hardware features die er wel inzitten er uitgesloopt zijn.
Het probleem is dat Alder Lake P-cores met AVX-512 mixt met E-cores zonder AVX-512. Er is een goede kans dat dit de enige CPU gaat worden met zo'n specifieke mix. Dan is het maar de vraag of Windows en Linux daar structureel support voor gaan bieden.

Je kunt niet zomaar AVX-512 uit de P-core slopen. Als je alleen de registers verwijdert, dan faalt de CPU core op onvoorspelbare manieren wanneer de instructie-decoder een AVX-512 instructie tegenkomt. Je moet dur een aangepaste instructie-decoder ontwerpen die net zoals de E-cores een invalid instruction exception genereert.
Anoniem: 63072 @MSalters3 maart 2022 14:15
Grappig genoeg zou een low end i5-12400 dus probleemloos avx512 moeten ondersteunen, aangezien deze geen E-cores heeft.
ahh, ok, dus het gaat erom dat de error handling goed verloopt, en dus heeft het nog wel nut om het erin te laten.

dat verklaart
Ja, dat is ook wat Intel mij heeft verteld toen ze me m'n alder lake sdp stuurden.
Anoniem: 138647 @robertlinke3 maart 2022 12:00
"als het er niet in wil, dan laat je de silicon die nodig is er toch uit? scheelt silicon, scheelt kosten"
Het is juist véél goedkoper om geen aangepaste Chip te ontwerpen (waar iets "weggelaten" is) versus een bestaande chip te nemen en iets uit te schakelen.
Intel is in de weer met software om tegen betaling features te unlocken, of features te gebruiken wanneer je het nodig hebt. Dus dit sluit aan op hun "koers" en hiermee willen ze het uitbannen.
Maar de methode met deze CPU is dat ze het permanent uitzetten en niet weer aan kunnen zetten. Dat sluit dan weer niet aan op hun koers.

Er wordt een aanname gedaan door de 'journalisten' dat het wordt gedaan om hun serverplatform 'exclusieve' features te geven (AVX 512). Het zou ook nog een andere reden kunnen hebben, de feature is wellicht onveilig in zijn huidige implementatie in de CPU en dat ze deze daarom willen uitzetten. Als de 'journalisten' alleen maar aannames posten en geen definitief antwoord uit Intel weten te peuteren, zal het gis werk blijven.
In Xeon sku dat tot 10000$ Schaald is er wat ruimte voor enable features. Ipv 30+ lijn een 9 lijn.
Het disablen lijkt mij meer een big little isue de e-cores hebben geen AVX512 en schedular kan daar ( nog ) niet mee omgaan.
Het wordt ook enabled met voorwaarde dat de ecores disabled zijn.
Als het schedular probleem is verwacht ik dat xeon met AVX512 alleen p-cores zullen hebben. Of de ecores disabled.
AVX512 is meer een workstation instructieset (xeon w-1000, w-2000 en w-3000 series) en voor scalable xeon cpus (rekendozen) dan een server instructieset.

Niet alle xeons zijn server cpus.
Gokje , kost misschien meer om dat er in het ontwerpt terug uit te vissen (gn idee waarom het er dan eigenlijk in zat ... 8)7 )
Intel probeert in principe altijd de beste en duurste chip te maken. Als dat niet lukt/er is geen vraag naar die CPUgaan ze een trapje lager, de i9 b.v. Als dat niet lukt word die "mislukte" i9 een i7, als het ook geen i7 kan zijn word het een i5 ect. Dit doen ze door telkens onderdelen uit te schakelen op de CPU die het wel zouden doen.

Hiermee hoeft Intel geen processors weg te gooien maar houden ze wel voldoende voorraad voor high end CPU's.
Waarschijnlijker is dat ze i9 maken en als de verkoopcijfers van de i5 hoger uitvallen dan verkopen ze die als i5 door wat fuses door te branden. Uiteraard zal ook een deel op basis van testen tot i5 gelabeld worden.
als het er niet in wil, dan laat je de silicon die nodig is er toch uit? scheelt silicon, scheelt kosten, en scheelt de consument een product waarvan hardware features die er wel inzitten er uitgesloopt zijn.
Het ontwerpen van een chip is een zeer lang en duur proces. Als je dat ene blokje eruit laat dan hou je of een stukje "lege ruimte" over, maar dat spaart geen geld, of je moet het hele ontwerp (passen en meten welke onderdelen waar geplaatst kunnen worden) opnieuw doen. Dat nieuwe ontwerp moet daarna opnieuw gevalideerd worden, je hebt nieuwe maskers nodig, ...

Ter vergelijking: stel dat je honderdduizend rijtjeshuizen neerzet, ga je dan aan iedereen vragen of ze één, twee of drie slaapkamers willen hebben? Of bouw je ze allemaal met drie slaapkamers en als mensen die extra kamers niet willen gebruiken, nou ja, dan doen ze dat toch lekker niet? Het is veel goedkoper om maar één ontwerp te maken waarvan je er heel veel produceert, dan een heleboel verschillende ontwerpen te maken zodat elk product alleen de onderdelen heeft die het moet hebben.
ja, maar als je weet dat er daarna nog 100.000 moet bouwen, en alle eerdere hebben gezegd dat ze maar 1 kamer nodig hebben dan ga je niet in de gebouwen daarna het alsnog met 3 kamers bouwen, dat is wat ik bedoel.

tuurlijk is het gene wat nu al manufactured en in de pipeline zit geen doen, maar deze processor heeft een levensduur van jaren. het geen wat nog niet in de pipeline zit kan je daar wel mee aanpassen, zou ik dan denken
ja, maar als je weet dat er daarna nog 100.000 moet bouwen, en alle eerdere hebben gezegd dat ze maar 1 kamer nodig hebben dan ga je niet in de gebouwen daarna het alsnog met 3 kamers bouwen, dat is wat ik bedoel.
Het punt is dat processoren uit kant-en-klare blokken worden opgebouwd. Intel heeft nu een blok "(een of andere codenaam) P-core" liggen dat ze in andere ontwerpen zo erin kunnen schuiven. Als ze dat ding in een Alder Lake consumenten CPU gebruiken, dan zetten ze AVX-512 uit. Maar als ze datzelfde blok in een Xeon server CPU zetten, dan wordt AVX-512 juist wel ingeschakeld.

Als deze core alleen voor consumenten producten gebruikt zou worden, dan zou je helemaal gelijk gehad hebben.
AVX512 instructieset is meer een workstation instructieset (xeon w-1000, w-2000 en w-3000 series) en voor scalable xeon cpus (rekendozen) dan een server instructieset.

Niet alle xeons cpus zijn server cpus.
Dat is wel nasty (een andere reden zie ik niet). Past wel een beetje in het straatje van Intel omdat ze nu ook met Intel Software Defined Silicon in de weer zijn; Je krijgt dus een standaard processor waar je doormiddel van licenties extra functionaliteit kan krijgen.

[Reactie gewijzigd door johnny2000 op 23 juli 2024 08:11]

Zo ongeveer elke hardware fabrikant beperkt performance met de software. Kijk naar GPUs, er zijn een hoop meer GPU types, dan dat er daadwerkelijk verschillende dies zijn. En natuurlijk, een gedeelte is een lager type omdat er fabricage fouten in de chip zitten, maar dat zijn ze echt niet allemaal.

Overigens mogelijk een reden dat ze het gewoon uitschakelen is ook productiefouten: Als ze simpelweg niet de moeite nemen om hun tests over het AVX-512 pad te gooien, dan kunnen ze ook niet garanderen dat die correct werkt. Kan je zeggen dat er geen garantie wordt geleverd dat die werkt, maar kan me ook voorstellen dat ze dan gewoon denken: Makkelijker hem gewoon echt uit te schakelen, kan er geen verwarring zijn.
Dat is wel nasty (een andere reden zie ik niet). Past wel een beetje in het straatje van Intel omdat ze nu ook met Intel Software Defined Silicon in de weer zijn; Je krijgt dus een standaard processor waar je doormiddel van licenties extra functionaliteit kan krijgen.
Hoe dan wel? Ze laten een zekering springen dus onomkeerbaar.
Zoek maar eens op SDSI of check https://www.phoronix.com/...&px=Intel-SDSi-Linux-5.18 . Ze zijn bezig om deze functionaliteit nu in de Linux kernel te krijgen.
Software Defined Silicon, interessant artikel _/-\o_
Mag dat wettelijk wel, een product verminken zodat het opzettelijk slechter presteert?
Hele idealistische opmerking. Zo'n beetje alle motoren in auto's worden software matig in twee of drie vermogens varianten uitgeleverd waarbij de hardware vaak volledig hetzelfde is. Er zijn aan het einde van de lifecycle van een serie (waarbij de yields het beste zijn) mogelijk hele batches goede CPU/GPU chips die iets geknepen worden omdat er nu eenmaal meer vraag is naar mainstream chips dan extreme high-end (al is dat op dit moment voor GPU's niet zo'n probleem).

Intel heeft nooit gezegd AVX-512 te ondersteunen op de Alder Lake consumentenlijn. Wellicht omdat er toch een bug of onvolmaaktheid in zit. Wellicht zat AVX-512 simpelweg in het design van de P-cores omdat ze het 1 op 1 over willen nemen voor de Xeon lijn die waarschijnlijk (volgens de berichten) enkel uit 100% P-cores of 100% E-cores zal bestaan.

Zoals met zoveel dingen: dat het werkt zegt niet dat het de bedoeling is/gesupport wordt en dat iets gesupport wordt zegt niet dat het goed werkt. Maar als iets dat gesupport wordt niet goed werkt dan krijg je "hulp" en als iets wat niet gesupport is niet werkt dan krijg je geen hulp. In het laatste geval gaan er mogelijk echter toch nog veel mensen klagen/contact op nemen en misschien heeft Intel daar simpelweg geen trek in.
Zolang duidelijk is wat je koopt, en het matched met wat je koopt is dat geen probleem.

Het is niet dat Intel nu doet wat Sony deed met de PS3. Eerst adverteren met Linux op de PS3 Cell cpu, en dat na een tijdje uitschakelen.
Je wil niet weten hoeveel PC verkopers Windows installeren op perfect werkende PC's ;)

Serieus: ja. Deze chips zijn nog eigendom van Intel. Het is niet alsof de zekering wordt opgeblazen ná de verkoop.
Je wil niet weten hoeveel PC verkopers Windows installeren op perfect werkende PC's ;)
_/-\o_ _/-\o_ _/-\o_
Het is al van in het begin aangekondigd dat Alder Lake geen AVX-512 zou ondersteunen en dat het zou uitgeschakeld worden (omdat de E-cores die functionaliteit niet hebben, alleen de P-cores, en een OS is niet slim genoeg om te weten aan welke core het zo'n instructie kan geven). Je kreeg het wel aan de praat door de E-cores uit te schakelen, wat bij de release wel een verrassing was. Maar dan zet je functionaliteit uit die Intel wél adverteert voor functionaliteit die het expliciet niet had toegevoegd aan die CPU.

Wie écht AVX-512 wil, moet een server CPU hebben en dat is over het algemeen ook wel de doelgroep hiervoor.

Artikel hier is dubbelzinnig over de reden waarom Intel AVX-512 uitschakelt terwijl dat al lang gecommuniceerd is.
De AVX512 is meer een workstation instructieset (xeon w-1000, w-2000 en w-3000 series) en voor scalable xeon cpus (rekendozen) dan een server instructieset.

Niet alle xeons zijn server cpus.
Anoniem: 63072 3 maart 2022 11:40
Het zou wel heel interessant (en pijnlijk voor Intel) worden als de geruchten kloppen dat de volgende generatie Ryzen wel AVX 512 ondersteuning heeft.
Hoe pijnlijk zal het zijn op consumenten CPUs? Heb jij een lijstje van consumenten software dit gebruikt? En hoeveel gebruikers hebben er daadwerkelijk last van.

Het enige wat ik me 1-2-3 kan bedenken is dat je een specifieke emulator gebruikt die dat ondersteund, dat is een niche in een niche. Dan lijkt het me dat je voordat je een nieuwe CPU kocht, checkte dat dit wel/niet ondersteund werd door Intel.

Als je echter een CPU hebt waarbij niet officieel wordt ondersteund, maar het wel werkt en Intel vervolgens zonder jou expliciete toestemming een stukje hardware onomkeerbaar stuk maakt, je wel eens terug kan gaan naar de verkoper en claimen dat de hardware gedeeltelijk is stuk gemaakt door de leverancier...
Anoniem: 63072 @Cergorach3 maart 2022 12:20
Video encoding en decoding kan een stuk efficienter met AVX-512.

AVX-512 lost een hoop rare inconsistenties in de AVX2 instructieset op, waardoor het makkelijker te gebruiken is.

AVX-512 biedt een mooie performance boost voor neural network inference.

De reden dat het tot nu toe weinig gebruikt is in consumenten software is vooral omdat het zeer beperkt beschikbaar was. Als het standaard wordt op nieuwe consumenten CPUs bijvoorbeeld AMD, dan wordt het ook interessanter om het voor performance kritische zaken te gebruiken.

Verder wordt AVX voor wetenschappelijke berekeningen veel gebruikt. Dat is veelal double precision floating point werk en niet iedereen kan zich Tesla en Instinct GPUs veroorloven van EUR 10k of meer per stuk. AVX-512 biedt hier grote voordelen.

Jij kijkt helaas alleen maar terug naar waar het tot nu toe gebruikt wordt en dan ook nog met een beperkte blik wat betreft gebruik. Als je een aantal jaren geleden datzelfde voor AVX2 had gedaan had je geconcludeerd dat die instructie set totaal overbodig was. Die is inmiddels onmisbaar voor moderne software.

[Reactie gewijzigd door Anoniem: 63072 op 23 juli 2024 08:11]

AVX-512 lost een hoop rare inconsistenties in de AVX2 instructieset op, waardoor het makkelijker te gebruiken is.
Dat klopt, maar dat staat op zich los van de 512 bits registers. Dezelfde makkelijke instructies werken ook op de 256 bits AVX2 registers.
Anoniem: 63072 @MSalters3 maart 2022 12:52
Helaas wel alleen op CPUs die ook AVX-512 ondersteunen.

Het zou wel al een hele verbetering zijn als er een breed ondersteunde AVX2.1 revisie zou komen met alle AVX-512F instructies op 256 bit registers. Ik snap sowieso niet waarom die stap nooit gemaakt is.
En hoever % van de markt die Intel met desktop CPU’s bedient gebruikt die functies ook?

Ik denk dat Intel niet gek is en goed gekeken heeft wat de kosten-baten zijn van zo’n beslissing.
Waarschijnlijk zal de mindere verkoop opwegen tegen de eventuele kosten besparing en zal een deel van de gebruikers wel overstappen op non-consumenten HW wat sowieso win-win is.
Anoniem: 63072 @sapphire3 maart 2022 14:01
Zoals ik al aangaf, het is nog niet gangbaar in consumenten cpus. Lage installed base.

Als je dezelfde vraag had gesteld toen avx2 dezelfde lage installed base had, had je dan ook gezegd dat avx2 op basis van een kosten bate analyse gedumpt had moeten worden? Dat zou namelijk behoorlijk kortzichtig zijn.

Als straks inderdaad alle nieuwe Amd systemen het wel hebben dan is er ook meer incentive om het te gebruiken. Er zijn namelijk meer dan genoeg zaken waar avx 512 en dan vooral de light instructies een voordeel kunnen bieden. (Praktisch: alles wat men nu met avx2 doet kan beter en/of makkelijker met avx512 worden geimplementeerd)
Van mij hoeft het niet gedumpt te worden en ik begrijp je beredenering helemaal :)

Ik probeer alleen de andere kant te belichten. Ik ben redelijk in de materie thuis en ik zou niet eens weten wat ik met AVX512 of AVX2 zou moeten en of ik het überhaupt gebruik. Laat staan de gemiddelde zakelijke gebruiker of een consument (want in de doorsnee laptop/desktop en zakelijke devices zit de massa) het iets kan schelen.
Dus Intel schrapt een feature wat waarschijnlijk 99% van hun gebruikers niet interesseert en wat waarschijnlijk amper impact gaat hebben op de verkopen.
Diegene die het persé willen gaan naar de Profi-spullen (pluspunt voor Intel) en de niche die overblijft is wellicht verwaarloosbaar.
Aangezien het hardwarematige wel in Alder-Lake zit en waarschijnlijk ook in de opvolger kan Intel het altijd nog aanzetten als het opeens een must-have selling point word omdat AMD het gaat ondersteunen.

Nee ik juich zulke grappen niet toe maar ik kan het me we voorstellen :(
Anoniem: 63072 @sapphire3 maart 2022 16:08
Ik denk dat jouw conclusie dat het 99% van de gebruikers niet interesseert op zich wel waar is, maar vooral omdat die gebruikers niet beseffen waarvoor het gebruikt wordt.

Ik denk dat de afgelopen twee jaar de meeste van ons wel eens teams gebruikt zullen hebben. De achtergrond blur in teams gebruikt avx2 voor voldoende perfoormance.

Minder zichtbaar is dat avx2 instructies pattern matching aanzienlijk kan versnellen. Wat o.a. gebruikt kan worden voor betere performance bij het parsen van json of xml en voice recognition. Dit soort software zit veelal nog op avx om compatible te zijn met zoveel mogelijk hardware. Daar zou met avx2 al winst te halen zijn en uiteindelijk als avx 512 beter beschikbaar is daarmee nog meer.

Compressie (niet alleen video, maar alle compressie) en encryptie profiteert ook flink van avx2 en kan ook sneller met avx512.

De grootste zichtbare winst voor veel 'gewone' gebruikers zal bij audio en video bewerking te halen zijn. Filters op grote raw foto's die ineens realtime kunnen ipv dat je een zandloper ziet etc...

Stiekem zijn er zo een heleboel zaken die mensen dagelijks gebruiken die baat zouden hebben bij universeel beschikbare avx-512. Juist nu het langzaam richting standaard leek te gaan voor consumenten cpu's is deze stap dus eigenlijk doodzonde.

N.B. De laatste generatie consumenten cpu van intel die officieel avx512 ondersteunde (rocket lake serie) had geen power states meer en throttlet net als AMD op temperatuur/power draw! Dus in goed gekoelde systemen is throttling in een mixed instruction scenario geen issue meer!
Volgens mij is het gewoon een kosten plaatje omdat het bij de non k processors uit te schakelen.
Om zodoende het productie proces te versnellen.3d ondersteuning is best goed als je een onboard videokaart hebt.Deze instructieset heeft idd veel voordelen.
Het is nu wel zo dat wanneer je in 1 thread avx2 512 gebruikt dat de cpu vaak terug gaat naar een lage power state wat weer nadeel geeft in alle andere threads, vaak is het gewoon niet nuttig genoeg om het te ondersteunen als je er niet mega voordeel uit kunt halen in die ene taak dat vertragingen op andere vlakken teniet doet.

edit: Mijn gok is dat dat ook een overweging van intel is om het voorlopig weg te halen van consumenten cpu;s

[Reactie gewijzigd door RobLemmens op 23 juli 2024 08:11]

Anoniem: 63072 @RobLemmens3 maart 2022 14:11
Clock throttling obv instructie gebruik is een design keuze van intel. Waarbij je moet bedenken dat de throttle reuze meevalt bij alleen gebruik van de 512bit light instructies of als je de nieuwe instructies gebruikt op 256bit registers.

Amd throttled niet op basis van gebruikte instructies, maar op basis van temperatuur. Met betere cooling zal Amd dus minder of zelfs niet throttlen bij avx2 instructies. Er is geen enkele reden voor Amd om dat andersvte doen voor avx512. (Mijn watergekoelde ryzen 5600 throttled totaal niet bij zware avx2 loads)

Overigens clocken recente intel chips fziw alleen de core waarop je zware avx2/512 instructies draait terug en niet alle cores.

Hoe dan ook, voor avx2 heeft Amd op dit moment een efficientere/flexibelere implementatie, nadat men jaren lang achter intel aan hobbelde. Ik ben echt heel benieuwd naar wat zen 4 brengt op dit gebied.
Slechte keuze van Intel, bovendien zie ik het probleem helemaal niet dat AVX-512 alleen op de P-cores zou draaien. Het had beter geweest als Intel de keuze gewoon aan de gebruiker had overgelaten met een bios optie.
bovendien zie ik het probleem helemaal niet dat AVX-512 alleen op de P-cores zou draaien.
Stel je code voor als het volgende:
  • Test of de CPU AVX-512 ondersteunt (op dit moment draait de thread op een P-core en is het antwoord dus "ja")
  • Kies de versie van je code die gebruikmaakt van AVX-512 instructies
  • Dat gaat een tijdje goed
  • De gebruiker start een ander programma op waardoor jouw code wordt gemigreerd naar een E-core (hiervan krijg je geen enkele waarschuwing)
  • Crash bij de eerstvolgende AVX-512 instructie die je probeert uit te voeren
Intel wist bij het ontwerpen van Alder Lake natuurlijk al dat er een verschil in ondersteunde instructies was tussen de P-cores en E-cores, dus dit 'probleem' komt niet zomaar uit de lucht vallen. Het is vreemd waarom Alder Lake bij de introductie dan nog gewoon AVX-512 ondersteuning had, de reden tot het schrappen van AVX-512 ondersteuning is ook een raadsel en mijn hier onder gelinkte artikel schrijft ook dat de reden onduidelijk is.

Intel zou het probleem in de hardware kunnen oplossen, wat extra logica en dus transistors kost. Zie:
https://www.anandtech.com...rings-hybrid-complexity/2
Part of the issue of AVX-512 support on Alder Lake was that only the P-cores have the feature in the design, and the E-cores do not. One of the downsides of most operating system design is that when a new program starts, there’s no way to accurately determine which core it will be placed on, or if the code will take a path that includes AVX-512. So if, naively, AVX-512 code was run on a processor that did not understand it, like an E-core, it would cause a critical error, which could cause the system to crash. Experts in the area have pointed out that technically the chip could be designed to catch the error and hand off the thread to the right core, but Intel hasn’t done this here as it adds complexity. By disabling AVX-512 in Alder Lake, it means that both the P-cores and the E-cores have a unified common instruction set, and they can both run all software supported on either.
Andere oplossingen waren om AVX-512 programma's alleen op P-cores te laten draaien met behulp van de schedular, die toch al aangepast moest worden voor Alder Lake. En als laatste had Intel de E-cores gewoon AVX-512 ondersteuning mee kunnen geven.
Het is vreemd waarom Alder Lake bij de introductie dan nog gewoon AVX-512 ondersteuning had, de reden tot het schrappen van AVX-512 ondersteuning is ook een raadsel
Nee, Alder Lake heeft nooit AVX-512 ondersteuning gehad (volgens de spec sheet). Het onderliggende silicon kan de instructies wel uitvoeren, maar het is officieel gezien nooit ondersteund geweest (en dus ook nooit geschrapt).
mijn hier onder gelinkte artikel schrijft ook dat de reden onduidelijk is.
Ehm nee, daar wordt juist keurig beschreven dat de reden heel duidelijk is: het is veel handiger als de P-cores en E-cores exact dezelfde instructieset ondersteunen.
Andere oplossingen waren om AVX-512 programma's alleen op P-cores te laten draaien met behulp van de schedular
Zoals het artikel wat je net aanhaalt zegt: "there’s no way to accurately determine [..] if the code will take a path that includes AVX-512".
En als laatste had Intel de E-cores gewoon AVX-512 ondersteuning mee kunnen geven.
Ehm ja... en ze hadden hun CPU ook een terabyte cache mee kunnen geven... Het hele doel van die E-cores is nou juist om zo klein en energie-zuinig mogelijk te zijn. Dan moet je geen grote en complexe blokken silicon toevoegen die slechts zelden gebruikt zullen worden.
Het is vele malen logischer om te zeggen "dan had Intel de P-cores gewoon geen AVX-512 ondersteuning mee kunnen geven"... Je weet wel, precies zoals ze (binnen de beperkingen van hoe je in de praktijk nou eenmaal CPUs ontwerpt) gedaan hebben.

TL;DR:
Er was in principe geen probleem: Intel had een chip ontworpen die alles deed wat ze beloofd hadden. Het ging pas mis toen iemand het "geniale" idee had om die chip kunstjes te laten doen waarvan Intel specifiek gezegd had dat die niet ondersteund worden... maar tot op zekere hoogte wel werkten. Als iedereen zich gewoon netjes aan de specs had gehouden, dan was dit hele gezeur nooit gebeurd.
Nee, Alder Lake heeft nooit AVX-512 ondersteuning gehad (volgens de spec sheet). Het onderliggende silicon kan de instructies wel uitvoeren, maar het is officieel gezien nooit ondersteund geweest (en dus ook nooit geschrapt).
Dat heb je fout, je heb duidelijk niet het artikel gelezen van mijn link.
https://www.anandtech.com...rings-hybrid-complexity/2
Why?

So the question then refocuses back on Intel. Why was AVX-512 support for Alder Lake dropped, and why were we told that it is fused off, when clearly it isn’t?

Based on a variety of conversations with individuals I won’t name, it appears that the plan to have AVX-512 in Alder Lake was there from the beginning. It was working on early silicon, even as far as ES1/ES2 silicon, and was enabled in the firmware. Then for whatever reason, someone decided to remove that support from Intel’s Plan of Record (POR, the features list of the product).

By removing it from the POR, this means that the feature did not have to be validated for retail, which partly speeds up the binning and testing/validation process. As far as I understand it, the engineers working on the feature were livid. While all their hard work would be put to use on Sapphire Rapids, it still meant that Alder Lake would drop the feature and those that wanted to prepare for Alder Lake would have to remain on simulated support. Not only that, as we’ve seen since Architecture Day, it’s been a bit of a marketing headache. Whoever initiated that dropped support clearly didn’t think of how that messaging was going to down, or how they were going to spin it into a positive. For the record, removing support isn’t a positive, especially given how much hullaballoo it seems to have caused.
Zoals ik al zei, je heb blijkbaar mijn linkje niet gelezen, want hier staat duidelijk dat Alder Lake AVX-512 zou ondersteunen, maar dat het door iemand, ten tijde van dit artikel nog onbekend, is geschrapt. De engineers waren in ieder geval razend.
As I’ve mentioned, apparently this decision didn’t go down to well. I’m still trying to find the name of the person/people who made this decision, and get their side of the story as to technically why this decision was made. We were told that ‘No Transistor Left Behind’, except these ones in that person’s mind, clearly.
Enige wat ik niet uit het artikel kan halen is welke oplossing de engineers dan in gedachten hadden om het AVX-512 probleem tussen de P-cores en E-cores op te lossen.
Dat heb je fout, je heb duidelijk niet het artikel gelezen van mijn link.
Ik had de paragraaf gelezen die je had geciteerd, als je liever had gehad dat ik een andere paragraaf had gelezen, dan had je die moeten citeren...

Overigens staat ook hier alleen dat ze ooit intern plannen hadden om AVX-512 te ondersteunen op de P-cores; voor zover ik heb begrepen is bij de externe, openbare aankondiging vanaf het allereerste moment duidelijk geweest dat er geen AVX-512 ondersteuning zou zijn.
Enige wat ik niet uit het artikel kan halen is welke oplossing de engineers dan in gedachten hadden om het AVX-512 probleem tussen de P-cores en E-cores op te lossen.
Ik heb indertijd een mogelijkheid voorgesteld. Zie de reactie eronder waarom dat geen optimale oplossing is, maar er is genoeg houvast dat ik me prima voor kan stellen dat Intel dacht dat dit oplosbaar zou moeten zijn.
Ik had de paragraaf gelezen die je had geciteerd, als je liever had gehad dat ik een andere paragraaf had gelezen, dan had je die moeten citeren...
In mijn specifieke reactie refereerde ik naar het artikel, niet de quote die ik later zette:
Mijn opmerking:
Het is vreemd waarom Alder Lake bij de introductie dan nog gewoon AVX-512 ondersteuning had, de reden tot het schrappen van AVX-512 ondersteuning is ook een raadsel en mijn hier onder gelinkte artikel schrijft ook dat de reden onduidelijk is.
En toen zei jij:
Ehm nee, daar wordt juist keurig beschreven dat de reden heel duidelijk is: het is veel handiger als de P-cores en E-cores exact dezelfde instructieset ondersteunen.
Uit deze reactie dacht ik weer dat je het artikel gelezen had. Maar dat is gewoon wat onduidelijkheid tussen ons. :)
Ik heb indertijd een mogelijkheid voorgesteld. Zie de reactie eronder waarom dat geen optimale oplossing is, maar er is genoeg houvast dat ik me prima voor kan stellen dat Intel dacht dat dit oplosbaar zou moeten zijn.
Gezien de engineers van Intel gewoon AVX-512 wilde ondersteunen en boos waren toen het geschrapt werd kan ik niets anders concluderen dat men een oplossing had voor het AVX-512 probleem tussen de P-cores en E-cores.
En zoals mij eerste quote uit het gelinkte artikel al vertelde had men dit in hardware op kunnen lossen volgens experts. Misschien had de hardware thread director hier een rol in kunnen spelen(vraag ik mij zomaar af hoor).
Zijn er batchnummers oid waarmee de consument kan bepalen of de chip wel of niet een gesprongen interne zekering heeft? Ik kan me goed voorstellen dat consumenten op basis hiervan deze specifieke CPU's willen kopen.
Dan nog ga je met microcode updates via OS en/of BIOS updates die functionaliteit verliezen helaas.
Een BIOS hoeft niet geactualiseerd te worden. Een OS (zeker Linux) hoeft geen microcode aan te bieden.

Dit is overigens af te raden, maar je kan gerust die functionaliteit behouden als je ervan afhankelijk bent.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:11]

Met DDR4 support en huidige mobo mogelijk ook nextgen biglittle kunnen upgraden , zal daar bios upgrade nodig zijn.
Als er mobo problemen zijn zoals bugfix bios flash nodig. Dan hang je ook.
Ze gaan de boel helemaal dichtsmijten vrees ik
https://www.tomshardware....w-fuses-it-off-in-silicon

maar
Meanwhile, AMD is rumored to bring support for AVX-512 to its Zen 4 chips, which is an odd twist if Intel continues to not support the instructions on its consumer hardware.

[Reactie gewijzigd door OxWax op 23 juli 2024 08:11]

Ik denk dat wel mee valt, de hobby power user die software gebruikt die goed schaald met AVX512 heeft pech. In de pro markt is het Dual of quad socket Xeons model zonder enige e-cores dus P-core only als die er komen. Of de vorige gen Xeon met AVX512 Voor de hobby pro user is of performance kwa prijs performance met single socket instap Xeon nog te overwegen is.
En anders blijft een workstation Threadripper of Epyc met heel veel AVX256 kwa prijs performance.
Alderlake heeft max 8 pcores dus alles met alleen maar AVX256 heb 16cores nodig om dat te compenseren, tegen die 8x AVX512
Tja AVX512 Zen4 , hangt er vanaf hoe dat daar tdp gaat beïnvloeden en of consumenten ook gewoon 16 cores met AVX512 krijgen.
Een Threadripper met AVX512 en degelijke klok zal misschien ook TDP verleggen.
En kwa prijs zal het ook duurder zijn dan consumenten AL.

Dit is zo een niche in consumenten markt dat dat betrekking heeft op zo klein deel.
Dat intel dat uitsluitend wil hebben voor pro sku.
Dat intel dat uitsluitend wil hebben voor pro sku.
Dat is het inderdaad : you want pro , you gotta buy Xeon
Jammer voor de RPCS3 emulator liefhebbers aangezien AVX-512 toch een behoorlijke performance boost opleverde: https://twitter.com/rpcs3/status/1461935681941426181?lang=en
Gewoon niet je bios updaten of niet een nieuwere generatie chip kopen?
Igh, ipv uit te schakelen, gewoon actief laten voor de gebeuikers die het willen gebruiken. Het zit er immers toch al in, dus gaan ze nu extra moeite doen/kosten om het uit te schakelen.
Eigenlijk bedriegt Intel de softwarebedrijven die zo dom geweest zijn zich op zuivere intel-instructies te richten. Hopelijk stappen er daarvan naar de rechter om loodzware schadevergoedingen te eissen. Intel moet leren dat je bij het uitvinden van instructies ook heel lange ondersteuning moet bieden. Dat hoort nu eenmaal bij de verantwoordelijkheden van een "leader"!
Ik moet opeens denken aan een rant van Linus Torvalds over dat x86/x64 processoren sowieso teveel instructies hebben. Hij vertelde ook dat hij sowieso geen fan van de AVX-512 extensies is.
Anoniem: 63072 @damouze3 maart 2022 17:22
Linus heeft niet altijd gelijk.

Hij geeft zelf al aan geen zier om FP performance te geven en dat hij liever zag dat de die space die avx 512 gebruikt voor extra cores gebruikt wordt.

Vervolgens komt hij met een rant dat intel ooit de slechtste FPU had en niemand daarom gaf. Dan heeft hij het over het pre 80486 tijdperk dat je een FPU nog los moest kopen en daarom alle massa software werd gemaakt zonder FPU vereisten.

Toen de FPU standaard werd vanaf 80486 ging men het gebruiken en was het wel degelijk van belang. De bagger FPU performance is wat Cyrix de das om heeft gedaan. Linus heeft dus een heel erg selectief geheugen!

Dan gaat hij ook nog eens volledig voorbij aan het feit dat de AVX2 integer instructies minstens net zo nuttig en misschien voor daily use software zelf nuttigerzijn dan de FP instructies.

Dan zegt hij vervolgens dat avx2 genoeg is. Als hij had gezegd dat 256bit registers voldoende was had ik hem nog het voordeel van de twijfel kunnen geven, maar zoals ik al eerder heb aangekaart is de avx512 instructie set een stuk doordachter en bruikbaarder. Blijkbaar vindt hij het dus geen probleem om allerlei noodgrepen uit te moeten halen ivm ontbrekende instructies.

Kort samengevat: Hij verwijt intel instructies voor niche gebruik te maken, maar hij zit zelf juist in een niche waarin zijn opmerkingen wellicht relevant zijn en heeft blijkbaar niet de behoefte of capaciteit om daarbuiten te kijken wat anderen doen. Laat hem lekker bij zijn kernel blijven en zich niet bemoeien met wat andere gebruikers wel of niet nodig hebben, want daar heeft hij duidelijk geen kas van gegeten.

Op dit item kan niet meer gereageerd worden.