'AMD schakelt 'loop buffer' in Ryzen 7000-cpu’s uit via biosupdate'

AMD lijkt een microcodepatch te hebben uitgebracht waarmee de loopbufferfunctie op Zen4-processors wordt uitgeschakeld. Er zouden na de implementatie van de patch geen noemenswaardige prestatieverschillen zijn vastgesteld. AMD heeft het nieuws nog niet bevestigd.

De wijziging werd ontdekt door Chips and Cheese. De techwebsite was een AMD Ryzen 9 7950X3D-cpu aan het testen via een ASRock B650 PG Lightning-moederbord en installeerde tijdens het testproces een nieuwe biosupdate met een nieuwe microcodepatch. Het zou gaan om AGESA-updateversie 1.2.0.2a. De redactie zag dat de loopbufferfunctie plots was uitgeschakeld en voerde daarna nog meer tests uit. Uit die metingen blijkt dat er weinig tot geen prestatieverschillen zijn met een uitgeschakelde loopbuffer op de Zen4-processor.

Chips and Cheese concludeert dat het cachegeheugen op de AMD Ryzen 9 7950X3D voldoende zou moeten zijn voor een vlotte werking. De website meent dat een loopbuffer geen belangrijke functie is die de prestaties van de Zen4-processors beïnvloedt. Een loopbuffer is een instructiecache in de frontend van de processor, waarin kleine, terugkerende instructies kunnen worden opgeslagen. Die kunnen dan efficiënter opnieuw worden uitgevoerd. De wijziging zou voorlopig enkel van toepassing zijn op Ryzen 7000-processors en Epyc-cpu's. Tweakers heeft AMD om een reactie gevraagd. Het artikel wordt aangevuld zodra het bedrijf meer informatie meedeelt.

Reacties (35)

[skdevil]

De vraag is; waarom?

[pixeled]

Goede vraag, ik zocht hier ook naar. In het gelinkte Chips and Cheese artikel word in de conclusie genoemd dat het niet bekend is waarom AMD dit doet. Ze speculeren hier wel over:

Zen 4 is AMD's first attempt at putting a loop buffer into a high performance CPU. Validation is always difficult, especially when implementing a feature for the first time. It's not crazy to imagine that AMD internally discovered a bug that no one else hit, and decided to turn off the loop buffer out of an abundance of caution. I can't think of any other reason AMD would mess with Zen 4's frontend this far into the core's lifecycle.

Wellicht dus een ontdekte bug, of simpelweg vanwege veiligheid.

[SunnieNL]

Ik gok op een undisclosed CVE.
daar gokken ze ook op in Hacker News https://news.ycombinator.com/item?id=42283933

Overigens heeft de Zen5 dit Loop Buffer helemaal niet meer door nieuw design.

[MrFax]

Lijkt me ook logisch waarom niet. De prestatieverschillen zijn gewoon niet te meten. Ik snap dan ook niet waarom AMD hier ooit mee is gekomen... misschien om nog wat lege die area met iets te vullen. Ik weet het niet. Want ze zullen zelf ook wel getest hebben dat die loopbuffer praktisch niks doet.

[Reactie gewijzigd door MrFax op 3 december 2024 01:45]

[HugoBoss1985]

Goede vraag, dat had duidelijker gemogen in het artikel.
Wellicht om beveiligingsredenen?

[Reactie gewijzigd door HugoBoss1985 op 2 december 2024 13:03]

[wow7]

Loop Buffering beïnvloed wel degelijk de prestatie , vooral in compiling methodes en van de assembly en/of binary output , tot wel 6.5% verlies kan worden toegeschreven aan het verwijderen van deze optie , voor workloads die deze methode gebruiken is dit aanzienlijk te noemen en voor de huidige maatstaven niet acceptabel , ik vermoed dat AMD deze optie verwijderd omdat deze foutief werk ? , of dat de 7800X3D het beter doet dan de EPYC ? , ik kan zo 1,2,3 geen andere grond bedenken.

Voor dagelijkse taken zal dit geen invloed hebben vermoed ik , maar helemaal beweren dat het geen invloed heeft en dat de X3D het overneemt en voldoende is betwijfel ik dan ook sterk in bepaalde workload omstandigheden.

Bron: PDF Document

[Squee]

Bron: PDF Document

Pas op, je haalt een studenten verslag van 21 jaar geleden (2003 [1]) aan van het vak "Advanced Microprocessor Architecture" aan de Rice unviversiteit, het is geen wetenschappelijke peer-reviewed paper. De prestatie invloeden die zij gemeten hebben op de SimpleScalar simulator van toen zijn niet representatief van wat de invloed zou zijn op een hedendaagse micro-architectuur. Moderne processoren hebben een veel geavanceerder 'front-end' dan waar ze toen van uit zullen zijn gegaan.

[1]: http://www.owlnet.rice.edu/~elec525/project.html

[wow7]

Het is nu nog steeds relevant , de workload van 21 jaar geleden is niet heel erg veel veranderd complexer maar dat is dan dat en de Loop Buffer is ook in de huidige architectuur relevant en verschild niet of nauwelijks van wat er beschreven word , herhaal code en/of compiling = output = prestatie en dat beïnvloed zekers.

En het hoeft ook niet wetenschappelijk peer reviewed te zijn het is een observatie en die is naar mijn mening nog steeds relevant.

[Darksequence]

Ik denk dat een hertest wel op zijn plaats is voordat je obv een 21 jaar oud artikel gaat beweren dat compileren 6.5% minder snel gaat zijn. Op 1 uur compileren komt dit neer op ongv 4 minuten. Vraag me af voor hoeveel mensen met een ryzen 7000 dit echt relevant is.

[wow7]

Nogmaals de workload op zich en de complexiteit zijn net zo relevant ook 21 jaar later , ik heb ook duidelijk aangegeven dat dit voor de dagelijks gebruiker niet of nauwelijks een probleem zal zijn maar de toekomst zal dit waarschijnlijk wel uitwijzen als er idd nieuwe tests zijn die het bevestigen of niet.

[dasiro]

er zijn wel compile-benchmarks en die zullen ze bij C&C ook wel opnieuw hebben lante lopen vooraleer ze de uitspraak deden dat dit weinig tot geen verlies in performance tot gevolg heeft (al ken ik de site niet, op het eerste zich lijken ze wel goed te weten waar ze mee bezig zijn):

544.nab has nearly a quarter of its micro-ops delivered from the loop buffer, yet its score actually increased by 1.7% with the loop buffer off (11.7 on the new BIOS, 11.5 before). That could be run to run variance, but overall it's clear turning off the loop buffer didn't cause performance loss.

In sommige suboptimale gevallen zeggen ze dat het inderdaad een verlies heeft van +/- 5%

Disabling the loop buffer basically doesn't affect performance with the game pinned to the VCache die. Strangely, the game sees a 5% performance loss with the loop buffer disabled when pinned to the non-VCache die. I have no explanation for this, and I've re-run the benchmark half a dozen times.

maar wie gaat z'n spellen nu met opzet op de non X3D cores laten draaien

[Squee]

er zijn wel compile-benchmarks en die zullen ze bij C&C ook wel opnieuw hebben lante lopen vooraleer ze de uitspraak deden dat dit weinig tot geen verlies in performance tot gevolg heeft (al ken ik de site niet, op het eerste zich lijken ze wel goed te weten waar ze mee bezig zijn):

De 502.gcc subtest van SPECcpu2017 is een compile-benchmark die de open source GCC C-compiler gebruikt. Je ziet dat dit slechts 3.7% van zijn micro-ops uit de loop buffer haalt. Helaas heeft hij niet de subtest scores gepubliceerd, maar het is veilig om aan te nemen dat het binnen de ruis marge zal liggen.

Ik kan trouwens als professional wel be-amen dat Chester van Chips and Cheese hoog aangeschreven staat en altijd hele grondige en goeie micro-architectuur analyses maakt.

[Squee]

Ik kan je aanraden om het Chips and Cheese artikel te lezen, wat hier eigenlijk al uitgebreid op ingaat. De loop buffer is vooral een energie optimalisatie omdat je bij het uitvoeren van loops dan een groot gedeelte van je front-end kan uitschakelen wat anders veel energie verbruikt (Branch prediction, Fetch, op cache). Hij laat ook duidelijk zien dat op de SPECcpu2017 benchmark er eigenlijk geen verschil in performance is.
Dit is een benchmark suite wat puur op de rekenkracht van je CPU leunt, en ook veel loops in de code bevat. Hij laat ook zien met andere metingen dat het uitschakelen van de loop buffer bijna compleet wordt opgevangen door de (veel grotere) op cache.

Er is wel een onverklaarbaar verschil in zijn Cyberpunk 2077 tests, maar we moeten niet vergeten dat hij dit alleen kan testen met twee verschillende BIOS versies en niet enkel het effect van de loop buffer kan uitsluiten. Aangezien Cyberpunk natuurlijk ook zwaar afhangt van zijn GPU kunnen er ook andere verandering in de BIOS update zitten die hier invloed op hebben.

[bwerg]

de Loop Buffer is ook in de huidige architectuur relevant en verschild niet of nauwelijks van wat er beschreven word , herhaal code en/of compiling = output = prestatie en dat beïnvloed zekers

Kwalitatief, misschien, maar je doet een kwantitatieve uitspraak ("tot wel 6.5%") gebaseerd op een CPU met een totaal andere architectuur, in een ander tijdperk (denk aan 800MHz), waarbij de gelinkte bron niet eens noemt op welke CPU er gemeten wordt (niet meer dan "Itanium" valt ergens tussen neus en lippen door). De resultaten in die context zeggen echt werkelijk nul komma nul over wat die getallen op een moderne CPU zouden zijn. Bottlenecks kunnen verschoven zijn, prestatiedipjes kunnen beïnvloed worden door andere optimalisaties die in moderne CPU's zitten. Dat paper is geen onderbouwing voor zo'n specifieke kwantitatieve stelling.

Om te weten wat de prestatieinvloed is zul je moeten meten, zo simpel is het. En niet op een CPU van 21 jaar geleden dus.

[Reactie gewijzigd door bwerg op 2 december 2024 18:32]

[PacinoAllstars]

Ik snap het. Je zegt dat die loop buffering wel degelijk impact heeft op prestaties, vooral bij specifieke taken zoals compileren en dat soort werk. De 7800X3D met zijn 3D V-Cache doet misschien iets anders met caching wat in andere situaties beter werkt, maar dat betekent niet dat het een 1-op-1 vervanging is voor loop buffering.

Voor de gemiddelde gebruiker maakt het waarschijnlijk niet uit, maar voor wie echt zware taken uitvoert waar die buffering heel nuttig is, kan het een flinke tegenvaller zijn. Het is ook een beetje vreemd dat AMD dit zomaar zou wegdoen zonder iets nieuws te bieden dat net zo goed of beter werkt, tenzij ze echt een goede reden hadden zoals stabiliteit of nieuwe, betere technieken.

[Squee]

De 7800X3D met zijn 3D V-Cache doet misschien iets anders met caching wat in andere situaties beter werkt, maar dat betekent niet dat het een 1-op-1 vervanging is voor loop buffering.

De 3D V-Cache werkt op een hele andere plek in de geheugen hierarchie dan de loop buffer. De 3D V-Cache is onderdeel van de L3 cache van de CPU, de laatste cache op weg naar je RAM. De loop buffer bevindt zich echt binnen in de CPU core, nog dichterbij dan de L1 Instructie cache, en in de buurt van de ingebouwde op-cache waar al gedecodeerde instructies in zitten. Ik ben niet bekend met de specifieke eigenschappen van het AMD design, maar de L3 cache zal waarschijnlijk een vertraging van 50 clock cycles hebben terwijl de loop buffer direct uitgelezen kan worden (dus met in feite 0 of 1 cycles latency, afhankelijk van hoe je het bekijkt)

[The Zep Man]

Als dit klopt zal AMD dit niet enkel via BIOS updates laten doen, maar ook via microcode updates die meegeleverd worden met besturingssystemen.

Microcode wordt ingeladen via:
• CPU
• BIOS
• OS

De nieuwste versie "wint".

[Reactie gewijzigd door The Zep Man op 2 december 2024 12:59]

[Blokker_1999]

Dat vind ik dan zelf weer gevaarlijk, want dan zijn kwetsbaarheden weer eenvoudiger te misbruiken lijkt mij als je het OS een minder goede microcode laat inladen.

[Troepje]

Door signing kun je dat redelijk mitigeren (qua man in the middle). Als iemand al zo diep in je kernel zit heb je denk ik een ander beveiligingsprobleem. De microcode moet dacht ik elke boot geladen worden, dus je kunt niet een cpu infecteren en plaatsen. M.a.w het zit goed dicht,.maar je houdt altijd een risico over idd

[Powerblast]

Ik heb eigenlijk geen idee hoe dat juist werkt? Ik zou juist denken dat je instructieset en aansturing van de cpu zelf enkle op bios level toegankelijk is. Dat zet anders de deur toch volledig open voor malware die zelfs rechstreeks op je cpu load.

[The Zep Man]

Dat zet anders de deur toch volledig open voor malware die zelfs rechstreeks op je cpu load.

Microcode is cryptografisch beveiligd en wordt gecontroleerd door de CPU zelf voordat die in gebruik wordt genomen.

[Reactie gewijzigd door The Zep Man op 2 december 2024 14:11]

[ari3]

De nieuwste versie "wint".

Je bedoelt de laatst ingeladen versie denk ik, dat is niet persé de nieuwste beschikbare versie.

[The Zep Man]

Een CPU weigert om een oudere versie microcode in te laden. Anders zou malware de beveiliging van nieuwere microcode ingeladen via de BIOS kunnen omzeilen door vanuit het OS oudere microcode in te laden.

Dus "de nieuwste versie wint".

[Reactie gewijzigd door The Zep Man op 2 december 2024 18:39]

[Nemesh]

Op 5 November zat deze patch al in de BIOS update voor mijn moederbord (ASUS ROG Crosshair X670E Extreme).
Deze BIOS kan je hier vinden.

[neps]

Klinkt als een ingreep tegen een nog niet bekendgemaakte kwetsbaarheid? Zo snel kan ik geen andere goede reden bedenken om dit zo laat na release uit te zetten.

[Lampuhkap]

X670 GAMING X AX V2 (rev. 1.0)
F32d 12,32 MB Oct 16, 2024
Checksum : 9B13
Update AMD AGESA 1.2.0.2a for next gen Ryzen X3D CPU performance optimized
Add X3D Turbo Mode support

Gigabyte was er al veel eerder bij

[Reactie gewijzigd door Lampuhkap op 2 december 2024 13:07]

[WhiteSnake76]

Dat had ik ook gezien, Gigabyte is er meestal als 1 van de eerste bij met Bios updates.

[sneakfreak]

Ik verwacht dat er wel een onderliggende bug zal zijn, maar die wil je niet bekend maken voor de patch is uitgerold. Die verklaring zal er dan wel komen.

[Powerblast]

Vreemd wel dat ze niet toelichten waarom het uitgeschakeld wordt. De functie zit er toch in dus dan kun je het evengoed gewoon gebruiken denk ik dan. Ik gok op een bug maar dat hadden ze ook gewoon kunnen zeggen.

[dutchgio]

Wellicht een bug/kwetsbaarheid? En dan eerst zorgen dat de patch er is voordat de details naar buiten komen, zodat je er iets aan kunt doen voordat het uitgebuit kan worden.

[polord1]

Mss leuke bijwerking dat het niet blijft hangen bij ashrock logo elke dag de eerste x opstarten

[LikeABawzs]

Hier ook Asus logo ja.
Booten is echt tergend langzaam.

[Mr_gadget]

Hoeveel systemen krijgen daadwerkelijk bios updates? Tweakers doen dat misschien. Maar vaak is 'als het werkt niks meer aan doen'. In bedrijfsomgevingen is het natuurlijk ook veel werk.

[mr_evil08]

Ook Tweakers doen het regelmatig niet, als het werkt niet aankomen gezien je nieuwe problemen kunt ophalen, bios update,s kunnen via Windows update binnenkomen.

[Reactie gewijzigd door mr_evil08 op 2 december 2024 22:12]

[roelie101]

Bedrijfsomgevingen doen het denk ik meer dan je in eerste instantie denkt. Ik weet dat de Dell’s en HP’s die ze bij ons op het werk hebben zichzelf doen updaten. Dit wordt gwn vanuit de fabrikant zelf gepushed.