News Intel AVX10.2: Intel Core alias Nova Lake bekommt neue Zusatzinstruktionen

[iWebi]

Intel gebt lieber Alder Lake sowieso Raptor Lake die Funktion zurück. Verstehe bis heute nicht warum ihr uns das genommen habt.

 

[stefan92x]

@Raptorlake Ganz einfach: Threads, die AVX512-Instruktionen nutzen, können nur auf den P-Cores laufen. Würde ein solcher Thread auf einen E-Core geschoben, würde dieser crashen, weil der Core die Instruktion nicht kennt. Nun kann der Scheduler im voraus nicht wissen, ob solche Instruktionen aufgerufen werden. Für dieses Problem gab es keine Lösung.

Und wenn wir das große Ganze betrachten: Wenn es dafür eine Lösung gäbe, dann würde AVX512 immer verbreiteter werden und immer mehr Software würde es verwenden. Und dann gäbe es immer mehr Software, die nur auf P-Cores lauffähig ist und die E-Cores würden mehr und mehr brachliegen. Alder Lake/Raptor Lake/Arrow Lake würden effektiv mit jedem Software-Update langsamer werden.

Wenn es diese Entwicklung schon seit Alder Lake gegeben hätte, wäre Arrow Lake insbesondere in vielen produktiven Anwendungen ein absoluter Rohrkrepierer geworden und noch viel schlechter am Markt positioniert als eh schon.

 

[latiose88]

Was mir allerdings egal ist weil meine Anwendung höchstens 256 sind bei avx und damit habe ich bei Intel und AMD keine Unterschiede was Leistung angeht ,zumindest in dieser Hinsicht .
Wann ich nun bei Intel die e Kerne von 4,6 auf 4,8 oder 5 GHz anhebe,kostet ja nicht so viel Strom und die Abwärme steigt kaum an. Dann gleiche ich fast den Unterschied zwischen e und p kerne dann an. Vorausgesetzt ich wähle ein oc Board aus .
Mit so einer Aktion ist dann der 265k dann schneller als der 285k mit minimal höheren Stromverbrauch und minimal höheren Temperaturen . Oder ist das eine blöde Idee?

Achja l3 Cache kostet ja auch etwas Strom aber Abwärme keine Ahnung .
Da es für mich irrelevant ist außer ich nutze mal nen ps3 Emulator wo es dann nen Unterschied zwischen avx 2 oder 512 ist . Naja ansonsten spielt es für mich keine Rolle sondern nur für die richtigen Arbeiter wie Workstation usw .

 

[mae]

Mich wuerde mehr interessieren, ob Nova Lake dann APX kann, was zum selben Zeitpunkt wie AVX10 vorgestellt wurde.

@Volker: Die Sache mit dem Heruntertakten beim Einsatz von (manchen) AVX und AVX-512-Befehlen wurde von Intel anfangs relativ heftig gemacht (wie Du schreibst), aber schon im im Ice Lake (2019) waren es 0MHz-100Mhz und beim Rocket Lake 0 MHz und ausserdem wurde das bei spaeteren Prozessoren auch weniger extrem ausgelebt (WIMRE wurde nur mehr der konkrete Kern gebremst und nicht alle).

Soweit ich es verstanden habe, hat der Grund fuer das Heruntertakten zwar schon mit dem Stromverbraucht zu tun, aber nicht mit dem Gesamtverbrauch. Wie man in dem Link oben sehen kann, passiert es beim Ice Lake nur, wenn ein Kern aktiv ist.

Es ist wohl so, dass der hoehere Stromverbrauch der breiteren und schwereren (heavy) Befehle die Spannung runterzieht, und um dann nicht falsche Ergebnisse zu bekommen, muss dann der mit dieser Spannung versorgte Bereich entweder langsamer laufen, oder die externe Spannung erhoeht werden, um das auszugleichen. Ich vermute einmal, in den spaeteren Prozessoren wurde vor allem letzteres gemacht und deswegen faellt das Heruntertakten schwaecher aus, aber bei den hoechsten Taktraten sind die Spannungen ohnehin schon so hoch, dass man sie nicht noch hoeher schrauben wollte, und lieber mit der Taktfrequenz ein bisschen heruntergegangen ist.

Travis Downs hat ausserdem noch die Uebergaenge zu AVX bzw. AVX-512-Befehlen untersucht.

Was bei der Abschaltung von AVX-512 bei Alder/Raptor Lake komisch ist: Intel hat das auch bei den auf den Xeons fuer Sockel 1700 gemacht hat, obwohl sie bei denen die E-Cores deaktiviert haben.

 

[foofoobar]

@Raptorlake Ganz einfach: Threads, die AVX512-Instruktionen nutzen, können nur auf den P-Cores laufen. Würde ein solcher Thread auf einen E-Core geschoben, würde dieser crashen, weil der Core die Instruktion nicht kennt. Nun kann der Scheduler im voraus nicht wissen, ob solche Instruktionen aufgerufen werden. Für dieses Problem gab es keine Lösung.

Man könnte die illegal instruction exception auch abfangen und dann diesen Prozess nur noch auf bestimmte Cores schedulen. Macht aber kein OS, weil wahrscheinlich niemand Bock auf diesen wirren Intel-Kram hat.

Linux sichert z.b. nur die FPU-Register bei einem Context-Switch wenn auch wirklich vorher ein FPU-Befehl von dem Prozess ausgeführt wurde, das wird über die illegal instruction exception gesteuert.

Ergänzung (8. August 2025)

Es ist wohl so, dass der hoehere Stromverbrauch der breiteren und schwereren (heavy) Befehle die Spannung runterzieht, und um dann nicht falsche Ergebnisse zu bekommen, muss dann der mit dieser Spannung versorgte Bereich entweder langsamer laufen, oder die externe Spannung erhoeht werden, um das auszugleichen. Ich vermute einmal, in den spaeteren Prozessoren wurde vor allem letzteres gemacht und deswegen faellt das Heruntertakten schwaecher aus, aber bei den hoechsten Taktraten sind die Spannungen ohnehin schon so hoch, dass man sie nicht noch hoeher schrauben wollte, und lieber mit der Taktfrequenz ein bisschen heruntergegangen ist.

Breite ALUs haben halt eine hohe switching capacity (viele Transen auf einmal), das ist auch der Grund warum GPUs niedriger takten als CPUs.

 

[mae]

Würde ein solcher Thread auf einen E-Core geschoben, würde dieser crashen, weil der Core die Instruktion nicht kennt. Nun kann der Scheduler im voraus nicht wissen, ob solche Instruktionen aufgerufen werden. Für dieses Problem gab es keine Lösung.

Doch, gibt es, sogar mehrere:

1) Man sagt nur Threads, die nur auf P-cores laufen duerfen (unter Linux mit "taskset -c", sowas gibt's doch sicher auch fuer Windows, oder?), dass sie AVX-512 koennen, nur dann werden diese Threads AVX-512 benutzen, aber die laufen ohnehin nur auf den Cores, die das auch koennen.

2) Wenn der Thread eine Illegal Instruction exception produziert und auf einem E-Kern laeuft, kann der Thread als AVX-512-Benutzer markiert, und auf einen P-Kern geschoben werden und dann versucht werden, dort weiterzulaufen. Nur wenn's dann auch diese Exception gibt, wird das als reale Ausfuehrung einer Illegal Instruction gehandhabt. Allerdings, wenn eine verbreitete Library (wie glibc) bei einer verbreiteten Funktion wie memcpy() AVX-512 einsetzt, wenn es vorhanden ist, werden ueber kurz oder lang keine Tasks mehr ueberbleiben, die auf E-Cores laufen koennen.

Bei Loesung 1 werden nur spezielle Tasks AVX-512 benutzen, bei Loesung 2 werden wohl nur spezielle Tasks E-Cores benutzen. Ich tendiere eher zu Loesung 1. Naja, jedenfalls hat Intel es offenbar nicht geschafft, alle wichtigen Betriebssystemhersteller zu so einer Loesung zu ueberreden, also haben sie AVX-512 dann deaktiviert.

 

[stefan92x]

Doch, gibt es, sogar mehrere:

Ich hätte vielleicht besser schreiben sollen, es wurde nichts umgesetzt

werden ueber kurz oder lang keine Tasks mehr ueberbleiben, die auf E-Cores laufen koennen.

Genau das hatte ich dann ja auch weiter als Grund ausgeführt, warum Intel in der Konstellation wahrscheinlich gar kein Interesse mehr an einer Lösung hatte. Lieber die Verbreitung von AVX512 bremsen, als sich mit seiner neuen Architektur ins Abseits zu stellen.

 

[foofoobar]

Allerdings, wenn eine verbreitete Library (wie glibc) bei einer verbreiteten Funktion wie memcpy() AVX-512 einsetzt, wenn es vorhanden ist, werden ueber kurz oder lang keine Tasks mehr ueberbleiben, die auf E-Cores laufen koennen.

Stimmt auch wieder. Unter Linux ploppen ja immer wieder kleine AVX Optimierungen überall auf.
Man sollte sich gedanklich davon lösen das nur bestimmte und wenige Anwendungen davon betroffen sind und das das kein Cornercase mehr ist.

 

[flaphoschi]

Und die diese Cores unterscheiden sich zusätzlich stark in der Leistung, dadurch verschärft sich das Problem mit dem Scheduler wenn der falsche Vorhersagen trifft.

Eben. Was will niemand an einem Computer?

Undefiniertes Verhalten.

 

[Tsu]

Für jemanden und andere, die das nicht kennen:
Was genau macht AVX10.2, warum ist das so anzustreben?

10.2 geht in Richtung Standardisierung.

AVX – wie schon MMX, SEE – sind SIMD, sind Vektorbefehle. Das hatten schon Vorposter erklärt.

Als Beispiel, in 3D-Anwendungen hast du sehr viel mit Matrizen und Vektoren zu tun. Die lassen sich, sofern die Operationen nicht in die GPU gewandert sind, mit diesen Befehlen schön schneller abarbeiten.

Im allgemeinen ist es so, dass wenn du Daten- und Datenstrukturen geeignet wählst, auch mehr von diesen Befehlen profitieren kannst. Aber auch Umstrukturierungen gehen damit eleganter (Scatter-/Gather Befehle). Bei größeren Datenstrukturen kannst du auch direkt in den Speicher schreiben lassen und damit den Cache entlasten (Teilaspekt bei “cache pollution”).

Eine Bibliothek von mir braucht statt ~1500ns pro Operation („Konkurrenz“ bzw. naive Implementierung) dann nur 32ns, String zu Objekt. Vergleiche zweier Objekte dann <1.4ns (essentiell dank einer AVX Instruktion auf die ich optimiert habe) statt ~1450ns.

Ich weiß das meine Anwendung mmx und sse Anwendung ist.

Mit MMX ist das mittlerweile aber ein Exot. Die Einheiten werden heutzutage doppelt mit etwas anderem belegt, afaik der FPU und du musst explizit zwischen den Modi wechseln. Das machen meines Wissens nach nur noch extreme Optimierer, die andere Einheiten frei halten wollen.

Oder in Embedded, wo es auch mal nur 32bit gibt aber MMX und SSE4.x

 

[latiose88]

@Tsu jap ist bei mir genau ,MMX,SSE und das verschiedene davon bei 32 bit.
Dank der neuen CPUs und deren Aufbau wo besser geworden ist ,können sie sich ja viel besser entfalten. Avx ist ja nun breiter und größer und genau darum profitiere ich ja auch etwas davon .Sagen wir mal rund 5 % Dank avx und avx2. Das ist nicht viel aber besser als nix ist es ja allemal .
Das gute ist durch das werden ja am Ende nicht alle Einheiten voll ausgelastet . Das führt dazu daß manche cpus durch das weniger Strom verbrauchen . Oder brauchen die egal ob belastet oder nicht immer gleich viel Strom die CPU ?

 

[Tsu]

Wenn eine CPU Einheit wach gehalten werden muss (vgl. “race to sleep”) verbraucht sie etwas. Deshalb auch der Lag bei Intel, wenn die erstmalig genutzt werden. Dann amortisiert sich der Speedup später auch nicht.

Ansonsten ist der Verbrauch dominiert von der Strecke, die das Datum zurücklegen muss (z.B. wg. flächigem Design; [J/m]). Abwärme von wieviel gleichzeitig passiert, mit Konzentration bei Vektor-Einheiten – deshalb dann das Runtertakten bei AVX Nützung, insbesondere bei vielen Multi-Cores.

Wenn du dich weiter einfuchsen willst: Informatiker (CS), Computeringenieure (CE) bzw. Elektrotechniker mit Richtung Informatik oder Informationstechnik (ET) lernen das in Vorlesung „Rechnerarchitektur“. Schaue mal ob es die irgendwo öffentlich gibt.

 

[foofoobar]

Wenn eine CPU Einheit wach gehalten werden muss (vgl. “race to sleep”) verbraucht sie etwas. Deshalb auch der Lag bei Intel, wenn die erstmalig genutzt werden. Dann amortisiert sich der Speedup später auch nicht.

Ansonsten ist der Verbrauch dominiert von der Strecke, die das Datum zurücklegen muss (z.B. wg. flächigem Design; [J/m]). Abwärme von wieviel gleichzeitig passiert, mit Konzentration bei Vektor-Einheiten – deshalb dann das Runtertakten bei AVX Nützung, insbesondere bei vielen Multi-Cores.

Breite ALUs haben primär das Problem der hohen switching capacity und dem daraus folgenden Einbruch der Spannung. ( #65 )
Normale floats laufen über die selben ALUs, und damit hast du quasi keine Taktregression.

 

[RealMax123]

Intel hatte mal 1x P-Core plus 4x E-Core, aber kaum verwendet. Ein 2x P-Core plus 2x 4x E-Core blieb Nische, obwohl vielfach für Office ausreichend und sparsam.

1P + 4E ist der Pentium Gold 8505

Ansonsten finde ich ist bei den Intel Mobilprozessoren 2P + 8E (z.B. i3-1220P, i5-1235U, i7-1255U, i5-1335U, i5-1345U, i7-1355U) bis 8P + 8E (z.B. i7-12850HX, i9-12950HX, i7-13700HX, i7-14650HX) am häufigsten.

Intel gebt lieber Alder Lake sowieso Raptor Lake die Funktion zurück. Verstehe bis heute nicht warum ihr uns das genommen habt.

Wäre schön gewesen, aber dafür ist es jetzt leider zu spät.

Doch, gibt es, sogar mehrere:

1) Man sagt nur Threads, die nur auf P-cores laufen duerfen (unter Linux mit "taskset -c", sowas gibt's doch sicher auch fuer Windows, oder?), dass sie AVX-512 koennen, nur dann werden diese Threads AVX-512 benutzen, aber die laufen ohnehin nur auf den Cores, die das auch koennen.

2) Wenn der Thread eine Illegal Instruction exception produziert und auf einem E-Kern laeuft, kann der Thread als AVX-512-Benutzer markiert, und auf einen P-Kern geschoben werden und dann versucht werden, dort weiterzulaufen. Nur wenn's dann auch diese Exception gibt, wird das als reale Ausfuehrung einer Illegal Instruction gehandhabt. Allerdings, wenn eine verbreitete Library (wie glibc) bei einer verbreiteten Funktion wie memcpy() AVX-512 einsetzt, wenn es vorhanden ist, werden ueber kurz oder lang keine Tasks mehr ueberbleiben, die auf E-Cores laufen koennen.

Bei Loesung 1 werden nur spezielle Tasks AVX-512 benutzen, bei Loesung 2 werden wohl nur spezielle Tasks E-Cores benutzen. Ich tendiere eher zu Loesung 1. Naja, jedenfalls hat Intel es offenbar nicht geschafft, alle wichtigen Betriebssystemhersteller zu so einer Loesung zu ueberreden, also haben sie AVX-512 dann deaktiviert.

Mir gefällt Möglichkeit 2 fast besser, und gerade bei den 8P + 8E CPUs sehe ich keine wirkliche Gefahr das die P-Cores knapp werden, zumal die P-Cores ja eh auch noch Hyperthreading können. Da ist die Gefahr das AVX512 ausbremst relativ gering.

Bei 2P + 8E CPUs könnte AVX512 dann natürlich schon ausbremsen.

Da wäre es dann vielleicht schon am besten AVX512 defaultmässig deaktiviert zu lassen. Aber so das Leute die es explizit wollen, in den EFI Einstellungen jederzeit selbst aktivieren kann.

 

[TechFA]

Intel ist eine Chaos-Butze.

Das kannst Du laut sagen, ja. Allein das Chaos um die ständig neu hinzugekommenen ISA-Erweiterungen seit den 2010ern, grenzt schon an Traumata beim programmieren.

Da wurden ständig neue Erweiterungen in den Ring geworfen, deren Implementierung entweder hochgradig fehleranfällig war, oder aber extrem verbuggt – Ein eklatantes Sicherheitsrisiko stellen sie wohl alle dar und das fing gefühlt schon beim ersten AVX an, wobei da eigentlich mit Skylake schon die ersten unrühmlichen Höhepunkte zu beklagen waren.

Weil bis dahin gab's schon unsägliche TGX, TSX/TSX-NI, AES-NI, XSAVE, ADX, SGX/SGX2, SMX, TSE, TXT, (VT-d/VT-i), MPX, CET … blabla, et cetera! Da wird man doch bescheuert!

Das Beste ist ja überhaupt die Inkonsistenz! Ich meine TSX ist seit der 12th Gen Intel Core um 2021 komplett deaktiviert, aber Xeon schleppt das Einfallstor bis heute noch mit sich herum, weil ansonsten Intel in vielen Bereichen der Container-Virtualisierung vollkommen disqualifiziert wäre.

---

Ich kann mir das auch mit nur so erklären, daß jeder dahergelaufene Klappspaten mit seiner Idee einer ISA-Erweiterung grundsätzlich auf offene Ohren traf und die Erweiterungen dann umgesetzt wurden, weil sie in Intel's Augen einen vermeintlichen Wettbewerbsvorteil darstellten, zumindest aber Alleinstellungsmerkmal.

Und da hat man das typische, immerwährende Intel-Problem: Am Markt vorbei entwickeln!

Ob die Erweiterungen nämlich von Irgendjemand jemals überhaupt gebraucht würden, geschweige denn daß die Kunden nach einer entsprechenden Funktionsimplementierung gefragt hätten, hat bei Intel niemals eine wirkliche Rolle gespielt – Die Implementieren konnte sogar grob fehlerhaft sein, es ist schlicht egal gewesen.

Weil alles was für Intel zählt, ist die Checkliste in der obligatorischen PowerPoint-Folie, bei der man dann beim Verkaufsgespräch ganz brav aufzählen konnte, was denn alles AMD nicht würde unterstützen und wie rückständig die sein — Tatsächlicher Nutzwert irrelevant!

Alles, worum es Intel geht und immer gegangen ist, ist etwas zu haben, mit dem sie sich gegenüber AMD abgrenzen können. Der eigentliche Nutzwert einer Erweiterung für letztendlichen Kunden ist daher für Intel vollkommen irrelevant und selbst die Sicherheit der Implementierung spielt bloß eine untergeordnete Rolle.

Deswegen hat Intel auch niemals irgendwelche Erweiterungen übernommen, die von AMD vorgeschlagen wurden (obwohl diese sinnvoll waren), mit prominenter Ausnahme von AMD64 – Intel würde mit der Unterstützung der AMD-Erweiterung ja ganz kausal vollkommen den (zumindest von Intel so verstandenen) Zweck verfehlen, da ja das Alleinstellungsmerkmal ihrer selbst damit verloren ginge.

Und Wer jetzt noch ein paar Zellen Grips entbehren kann, kommt selber drauf …
Praktisch jede ISA-Erweiterung, welche Intel jemals einführte, diente zuvorderst nur dem Zweck, um sich von AMD und ihren (vergleichbaren) Prozessoren zu distanzieren.

Und dann guckt mal auf die Zeitleiste!
Als AMD ihren K6 hatte, kam Intel 1997 mit MMX um die Ecke. Als AMD 1999 ihrem potenten K6-III hatte und mit dem tatsächlich deutlich effizienteren 3DNow! kam, anwortete gleich mit mit SSE und trat damit in die nächste Runde.

Als AMD 2000 schon wieder die Überhand mit dem extrem starken original Athlon bekam, konterte Intel mit SSE2 — Vier Jahre Ruhe, weil Intel mit Pentium 4 gar nichts zu melden hatte, und es kam mit Prescot SSE3, damit man sich wieder abgrenzen konnte. Dann 2007 als AMD mit dem Phenom konterte, gabs SSE4.

Kaum hatte man wieder mit Sandy Bridge die Oberhand, kam AVX in 2011, aber da wußte ja keiner um die bei AMD bevorstehende Bulldozer-Flaute, also hielt Intel wieder still, bis man mit Haswell wieder AVX2 brachte. AVX512 hat man derweil am Wegesrand seit 2011 verrotten lassen, weil es war ja keine Not, eine Differenzierung zu schaffen, Intel war ja schneller.

Aber kaum war Intel 2017 wieder am Arsch nach AMD's Ryzen, wurde zielsicher AVX512 ins Consumer-Segment, mitsamt dem immerwährenden obligatorischen Marketing, daß ja alle ohne AVX512-fähige CPU die Gekniffenen werden (selbst wenn bis heute kaum Jemand weiß, wofür man es wirklich benötigt).

Und so kommt es eben, daß ständig neue Bullshit-Erweiterungen in den Ring geworfen werden, die Niemand wirklich benötigt, welche aber unter Garantie das nächste Scheunentor in Core reißen und eine Differenzierung von AMD beabsichtigen, womit natürlich seitens Intel immer nur eine Besserstellung der eigenen Prozessoren suggeriert wird.

Mit anderen Worten: Kaum kam Intel ins Hintertrefefn, kamen sie mit ISA-Erweiterungen, die ihre dahinschwindende Daseinsberechtigung und Mehrwert wieder erhöhen sollten — In vielen Fällen war ein Mehrwert aber überhaupt nicht gegeben, sondern bloß verkaufsfördendes Scheinargument.

Daher ist es auch nicht weiter verwunderlich, daß Intel seit 2017 mit einer wahren Flut an neuen Erweiterung um die Ecke kam, um krapfhaft einen Mehrwert zu suggerieren, obwohl eigentlich schon mit AVX2 der Scheitelpunkt des tatsächlichen Nutzwertes bei der Implementierung dahinschwindete (zu große Die-Fläche für Null nutzen oder gar Nachteile) …

 

[latiose88]

oder nur geringe also wenig Leistungssteigerung ,kannst du da noch hinzufügen.Macht da keinen Unterschied weil die Die Fläche kostet es dennoch sehr viel.

 

[foofoobar]

Das Beste ist ja überhaupt die Inkonsistenz! Ich meine TSX ist seit der 12th Gen Intel Core um 2021 komplett deaktiviert, aber Xeon schleppt das Einfallstor bis heute noch mit sich herum, weil ansonsten Intel in vielen Bereichen der Container-Virtualisierung vollkommen disqualifiziert wäre.

TSX ist/war doch broken by Design?

Und Wer jetzt noch ein paar Zellen Grips entbehren kann, kommt selber drauf …
Praktisch jede ISA-Erweiterung, welche Intel jemals einführte, diente zuvorderst nur dem Zweck, um sich von AMD und ihren (vergleichbaren) Prozessoren zu distanzieren.

AMD hatte mal eine 3-Operanten Maschine für die FPU eingeführt/implementiert. Aber Intel kann da nicht hinterher.
Jetzt soll mit APX wieder eine 3-Operanten-Maschine kommen.

Daher ist es auch nicht weiter verwunderlich, daß Intel seit 2017 mit einer wahren Flut an neuen Erweiterung um die Ecke kam, um krapfhaft einen Mehrwert zu suggerieren, obwohl eigentlich schon mit AVX2 der Scheitelpunkt des tatsächlichen Nutzwertes bei der Implementierung dahinschwindete (zu große Die-Fläche für Null nutzen oder gar Nachteile) …

Seitdem AMD jetzt eine vernünftige Implementierung abgeliefert hat und diese durch eine nachvollziehbare Produktpolitik (Feature $bar gibt es ab Generation $foo) flankiert, breiten sich die AVX-512 Sprenkel mittlerweile ziemlich aus. (Windows keine Ahnung, ist für mich nicht relevant)

Du hast den Bullshit vergessen den INTEL gerade mit SMT abzieht.

oder nur geringe also wenig Leistungssteigerung

Nein: https://www.phoronix.com/search/Eric+Biggers

Die Fläche kostet es dennoch sehr viel.

Zeig uns das mal anhand der Dieshots von Zen4 und Zen5.
Ansonsten implementiert AMD zusätzlich eine platzsparende und softwarekompatible Variante.

 

[latiose88]

Nein: https://www.phoronix.com/search/Eric+Biggers

Hm gut habe zwar die Stelle nicht wirklich gefunden aber gillt wohl nur auf meine Seite. Durch die weniger Auslastung der Einheiten verbraucht wohl Villeicht durch das die CPU weniger Strom .

Zeig uns das mal anhand der Dieshots von Zen4 und Zen5.
Ansonsten implementiert AMD zusätzlich eine platzsparende und softwarekompatible Variante.

Das war auf Intels CPU bezogen und nicht auf AMD. AMD scheint da echt um einiges besser zu sein als Intel .

 

[foofoobar]

Das war auf Intels CPU bezogen und nicht auf AMD. AMD scheint da echt um einiges besser zu sein als Intel .

Was juckt es die Sau wenn der Eber sich am Arsch kratzt?

 

[SSD960]

Hat sich Intel nur da verrannt? Würde mal nein sagen. Der X3D Cache sollte ja auch nur für Server CPUs kommen. Ok heißt jetzt anders aber kommt für den Desktop