News Intel AVX10, AVX10.2 und APX: Neue Instruktionen für mehr Leistung auf P- und E-Cores

Ach, wie hübsch. Intel schafft - mal wieder - neue Instruktionen die jahrelang niemand braucht (oder nutzen kann) nur um sie dann irgendwann wieder zu entfernen (abzuschalten). Wie jemand vor mir bin ich auch der Meinung, dass Intel das als Vorteil gegenüber AMD vermarkten wird. Durch spezielle Software, die dann nur mit den von Intel beworbenen Vorteilen auf Intel-Hardware lauffähig sein wird.

Fortschritt ist schön - aber nur wenn er vereinheitlicht und standardisiert wird (-> offen).
 
toll, dann hat man zwar avx512 auf einer cpu, aber mit 512 bit vektorlänge weiterhin nur auf den p-cores und max. 256 bit auf den e-cores. d.h. man kann immer noch nicht ohne aufzupassen einen avx-thread einfach so zwischen den cores hin- und herschieben bzw. man ist auf 256 bit instruktionen beschränkt, wenn man alle cores benutzen will. da erscheint amds ansatz, dass avx512 = 2x avx256 ist, wohl cleverer.
 
  • Gefällt mir
Reaktionen: mae
Dittsche schrieb:
Denn Big/SH.ittle braucht niemand im High Performance Segment!
Die Grundidee, mit P-Cores die ST-Performance zu optimieren und mit E-Cores die MT-Performance effizient zu steigern ist eine gute.

Das Problem bei Intels Implementierung sind die Unterschiede in den unterstützen Befehlssätzen, durch die man einiges kastrieren musste und viel Siliziumfläche verschwendet hat.
 
  • Gefällt mir
Reaktionen: 7H0M45
XRJPK schrieb:
Na super.. es hat Jahre gedauert bis sich AVX512 halbwegs verbreitet hat. Ich mein AVX512 ist aus dem Jahr 2013. Und nun zaubert man mal eben neue Instruktionen aus dem Hut, die wieder Jahre brauchen, bis sie auf AMD laufen usw.

Es wirkt ein bisschen so als müssen wir unsere CPU schneller machen, nur wie bekommen wir das hin?
Ich hasse es auch, dass mein Diesel kein Benzin verträgt. Merkst du was?
 
Also bei Intels Techniken habe ich noch mehr das Gefühl, dass die unsinniger sind als die von NVidia.
Zu speziell, zu wenig genutzt, und schon wieder weg, wenn AMD endlich damit rausrückt.
Und jetzt will man es doch wieder dicker auftragen?
Immerhin wissen wir ja, in dem einen Syntetiktest schmitzt so ein Prozessor förmlich vor sich hin und taktet deutlich niedriger, sobald AVX aktiviert wird.
Vielleicht sollte man erst einmal an allgemeinen DIngen wie Effizienz und Leistungssteigerung arbeiten, anstatt sich da auf Extrawürste zu fixieren?
Da sind für mich die Prioritäten falsch gesetzt, da es absolut keinen Spielraum für die Zusatzlast gibt.
Dafür ist das technische Design der Intelchips leider seit 14 Generationen schlecht gealtert.
Wo bleibt die Revolution der Intelingenieure für ein modernes Chipdesign?
Wo bleibt der WoW-Effekt? Der Paukenschlag? Die Antwort auf Ryzen?
Ergänzung ()

BrollyLSSJ schrieb:
DA bin ich mal gespannt, was die neuen Erweiterungen bringen werden. DiskCryptor konnte z.B. von SSE profitieren bei der Verschlüsselung. Das fand ich gut.
Das ist mir viel zu speziell.
Dafür Silizium verschwenden?
Auch integrierte Grafik kostet extrem viel Platz.
Es ist immer die Frage, was man möchte.
 
Zuletzt bearbeitet:
Ja dann heißt es am besten bei kleinen gpus bleiben dann steigt da der flächenbedarf nicht an.
Achja instructionen die nicht verwendet werden bleiben bei der CPU brach.
Das heißt wenn man ne Software verwendet die dafür bekannt ist sehr lange zu brauchen bis da mal das ganze Standard geworden ist oder halt ohne Fehler, dann ist es auch schon zu spät.
Und so einige instuktionen sind einfach nie bei meiner Software hinzugefügt zum nutzen. Das heißt ein Teil der CPU bleibt immer brach.

Die wenn nicht unterstützt wird, heißt es noch mal 10-20 % der CPU was brach liegt.
Das heißt dann muss ich mir noch weniger sorgen machen das die CPU zu heiß wird oder spielt dies keine Rolle wie stark die Transistoren maximal einer CPU ausgelastet werden als Einheit?
 
calluna schrieb:
Ist das nicht schon seit dem Pentium Pro so?
Ich vermute mal mit dem Begriff Altlasten ist nicht die Architektur gemeint sondern der alte 16 Bit-Modus.

Mich würde ja auch interessieren ab welcher CPU-Generation Intel nun x86S umsetzen möchte,
also 64 Bit only im Kernel-Modus der CPU. Sowie Wegfall von 16 Bit Real und Protected Mode.

Soweit mir bekannt sind die 16 Bit-Modi selbst in akt. Intel und AMD CPUs immer noch implementiert, auch wenn diese keiner mehr nutzt... Diese werden nur noch beim Booten des Rechners initialisiert.
 
Erst einmal hört sich es gut an, wenn es Fortschritt gibt !
Mir fehlt es lediglich ein jedes Mal an der Umsetzung/Implementierung.
 
whynot? schrieb:
Mir fehlt hier der technische Background um das fundiert beurteilen zu können aber in der Twitter Xer Community werden diese Änderungen sehr positiv aufgenommen.
😉😂
 
BDR529 schrieb:
Ich hasse es auch, dass mein Diesel kein Benzin verträgt. Merkst du was?
Ufff ist das dünn... Hast du verstanden was eine Instruktion ist, wie die funktioniert? Welche Auswirkungen das für Anwender hat? Klar 90% der CB leser nutzen kein AVX512 o.ä. aber wenn man im Enterprise Umfeld unterwegs ist sieht das anders aus.
Das eine Software ggf. neu gekauft werden muss für mit unter sehr viel Geld. Das mal massive Performance Gewinne und/oder Verluste hat, ergo Zeit, ergo wieder Geld...

Edit: P.S. Hab deine Signatur gelesen und bin vom Stuhl gefallen...
 
Völlig unnötig. Auf dem Desktop möchte ich keine E-Cores. Da brauche ich nichts als performante Cores mit hoher Single Thread Performance, mehr nicht.

Wer darüber hinaus Energiesparen möchte kann das genausogut über Bitsums Process Lasso Pro bewerkstellen durch den Auto IDLE timer, der das Gerät bei keiner Maus-/Tastaturbedienung automatisch in den Energiesparmodus setzt und auch automatisch wieder aufweckt. Ich verwende als Default Energieprofil "Balanced". Darüber hinaus kann man dann noch applikationsspezifisch auf Höchste Performance stellen und wahlweise noch den Performance Mode aktivieren, so dass bei fehlender Maus-/Tastaturbedienung das hohe Energieprofil bleibt.

Darüber hinaus kann man noch mit Bitsums Process Lasso Pro die im Wesentlichen interessanten Energieprofile anpassen, so dass man bei Balanced nur die Haupt Cores verwendet (also 50% der Cores, die Hyperthreads, abschaltet, wenn keine hohe Last da ist). Oder dass Energiesparen wirklich auf die niedrigste Anzahl Cores und den niedrigsten Takt runtergeht.

Diese Funktionalität in Windows zu integrieren und nur mit Performance Cores zu arbeiten wäre wesentlich sinnvoller. Das würde auch jegliche Komplexität hinsichtlich Process Scheduler vermeiden oder dass nachher sogar die falschen Prozesse auf den E-Cores landen. Das wäre zB ganz Fatal bei Recording/Mixing/Mastering Anwendungen mit near-realtime Anforderungen.

Alles in allem finde ich ist das alles ein Schrott Design und geht für mich in die verkehrte Richtung.
Ergänzung ()

XRJPK schrieb:
Ufff ist das dünn... Hast du verstanden was eine Instruktion ist, wie die funktioniert? Welche Auswirkungen das für Anwender hat? Klar 90% der CB leser nutzen kein AVX512 o.ä. aber wenn man im Enterprise Umfeld unterwegs ist sieht das anders aus.
Das eine Software ggf. neu gekauft werden muss für mit unter sehr viel Geld. Das mal massive Performance Gewinne und/oder Verluste hat, ergo Zeit, ergo wieder Geld...

Edit: P.S. Hab deine Signatur gelesen und bin vom Stuhl gefallen...

Soweit ich weiß verwenden auch manche Recording Anwendungen AVX512 Instruktionen, zB Cubase.
Darum ging bei mir auch immer der Takt etwas runter, wenn solche Instruktionen, die anscheinend mehr Abwärme verursachen, ausgeführt werden. Bei der E5-1650v4 CPU ganz schön blöde, weil die dann auf das gleiche geringe niveau wie die v3 Version zurückfiel und statt mit 3.8 GHz dann nur mit 3.5 GHz performte.
 
Ja beim Video Encoden und Decoden kann es verwendet werden und steigert die Performance dann schon erheblich
 
Matthias B. V. schrieb:
Das Instruktionen über alle Kerne verfügbar sind wird Zeit.

Generell hatte ich mir flexible Lösungen wie SVE2 von ARM erhofft.

Langfristig hoffe ich dass Intel / AMD die Altlasten (Legacy) über Bord werfen oder nur noch simulieren und eine Art Lean86 Architektur vorstellen - gerne auch zusammen - um gegen ARM und RISC-V besser positioniert zu sein.

Ansonsten sehe ich langfristig x86 auf dem absteigenden Ast. Was auch nicht so schlimm wäre und wir mehr Optionen hätten.
Du meinst wie bei ARM für jeden Scheisse eine proprietäre Processing Unit zu verbauen?
 
XRJPK schrieb:
Ja beim Video Encoden und Decoden kann es verwendet werden und steigert die Performance dann schon erheblich

Ja aber nur wenn man die richtigen Einstellung verwendet. Wenn man es so wie ich macht, dann profitiere ich etwas von avx1 und avx2 aber wehe ich stelle avx 512 ein, dann läuft die Anwendung langsamer als ohne.
Instruktionen sind soweit ich weiß Beschleuniger. Aber wenn die dann verpuffen, dann wird ne gewisse Einheit nicht belastet.

Selbst me Instruktion bzw Beschleunigung kostet wafer bzw Transistoren Fläche die man beansprucht obwohl man diese nicht benutzt. Oder habe ich was missverstanden?

Aber keiner weiß genau wie viel Silizium Fläche eine Beschleunigung ala Instruktion diese insgesammt kostet. Bestimmt nicht wenig.
 
latiose88 schrieb:
Ja aber nur wenn man die richtigen Einstellung verwendet. Wenn man es so wie ich macht, dann profitiere ich etwas von avx1 und avx2 aber wehe ich stelle avx 512 ein, dann läuft die Anwendung langsamer als ohne.
Das ist natürlich so...

Bei x265 Encoding mit Handbrake zum Beispiel sind das ~ 7% mehr Geschwindigkeit, aber auch deutlich höhere Leistungsaufnahme, was dann zum Beispiel den sinkenden Takt erklärt
 
x86 mit 32 GPR? Nett!

AVX10 hingegen.. Imho sehen SVE von ARM und die V-Erweiterung von RISC-V eleganter aus.


AAS schrieb:
Du meinst wie bei ARM für jeden Scheisse eine proprietäre Processing Unit zu verbauen?
Geschrieben von einer x86 Kiste mit >>10 propritären Coprozessoren, die propritäre Firmware ausführen.
 
AAS schrieb:
Du meinst wie bei ARM für jeden Scheisse eine proprietäre Processing Unit zu verbauen?
ARM benötigt nicht für jeden Scheiß "properitäre" Co-Prozessoren sondern nur in bestimmten Fällen und das sind meistens Fälle, in denen man mit einer neuen Erweiterung das CPU-Design nur sinnlos aufblasen würde, nur damit man einen "Generalisten" hat.
Piktogramm schrieb:
x86 mit 32 GPR? Nett!
Absolut Nett! Damit kann Intel (und auch AMD) später ggf. auch das "Backend", was die Infrastruktur zum Laden und Speichern von Daten angeht, wieder etwas verschlanken und kann ebenso das Prefetch einfacher gestalten.
Piktogramm schrieb:
AVX10 hingegen.. Imho sehen SVE von ARM und die V-Erweiterung von RISC-V eleganter aus.
Wenn ich AVX10 jetzt richtig verstehe, dann ist es die Zusammenfassung von AVX, AVX2 und AVX512 mit den Modi 128 Bit, 256 Bit und eben "optional" 512 Bit.

Wenn Intel es richtig macht, dann kann die CPU auch mit den 512-Bit-Modi umgehen und splittet diese dann ggf. auf beide AVX-Einheiten oder führt sie in zwei Takten aus.

Man wird mal abwarten müssen, aber es ist gut, dass Intel die Schwachstellen von IA32 angeht und die Register von 16 auf 32 erweitert.
 
XRJPK schrieb:
Das ist natürlich so...

Bei x265 Encoding mit Handbrake zum Beispiel sind das ~ 7% mehr Geschwindigkeit, aber auch deutlich höhere Leistungsaufnahme, was dann zum Beispiel den sinkenden Takt erklärt

Ja das kommt echt drauf an. Wenn man bei 720p, 1080p oder höher umwandelt dann profitiert man in der Tat von avx 512.
Wenn man allerdings so wie ich überwiegend unter 720p Videos umwandelt dann kostet avx 512 sogar Leistung. Wie avx 512 ein war beim test von ryzen 9 7950x3d kostete avx 512 10 % an Geschwindigkeit. Takt blieb jedoch gleich bei 4,8 GHz. Beim 7950x war es ebenso festzustellen. Bei den Intel war das ebenso der Fall. Dabei hatte ich mit nem i9 9980xe eine leistungsstarke CPU gehabt. Avx 512 kostet da auch Leistung. Es waren da bis zu 20% Leistungs Kosten gewesen. Mit hohen Auflösung waren es keine Kosten gewesen sondern Gewinn.
Da ich jedoch nur 576i Aufnahmen überwiegend waren ist der Gewinn nicht vorhanden. Zudem nutze ich h264 anstatt h265. Das macht auch noch nen Unterschied aus. Darum sagte ich ja kommt drauf an welche Einstellung man verwendet. Zumindest avx 1 und 2 kostet keine Leistung. Aber bei mir habe ich eben wohl niedrigere takt gestellt gehabt.
Aber auch wenn takt sich nix ausgewirkt hat, die tempertur stieg dennoch wegen avx nach oben.
 
DevPandi schrieb:
Absolut Nett! Damit kann Intel (und auch AMD) später ggf. auch das "Backend", was die Infrastruktur zum Laden und Speichern von Daten angeht, wieder etwas verschlanken und kann ebenso das Prefetch einfacher gestalten.
Wenn ich auf Apples Mx Chips schaue... Da werden ein paar Änderungen erfolgen, aber wirklich schlanker wird da nichts werden. Es wird allenfalls weniger eskalieren (müssen).

Wenn ich AVX10 jetzt richtig verstehe, dann ist es die Zusammenfassung von AVX, AVX2 und AVX512 mit den Modi 128 Bit, 256 Bit und eben "optional" 512 Bit.
Wenn Intel es richtig macht, dann kann die CPU auch mit den 512-Bit-Modi umgehen und splittet diese dann ggf. auf beide AVX-Einheiten oder führt sie in zwei Takten aus.
Dokumentation zu AVX10 von:
https://www.intel.com/content/www/u...ical/advanced-performance-extensions-apx.html
Wenn ich es richtig sehe, dann hantiert Intel bei AVX10 immer noch mit xmm, ymm und zmm Registern rum um die "Modi" zu realisieren. Vorteil ist, dass für AVX2 bzw. die Anzahl der ymm Register von 16 auf 32 erhöht werden. Wer Software schreibt, muss dennoch zwei Codepfade vorsehen. Einmal 256bit auf ymm und einmal zmm falls 512bit Verfügbar ist. Es ist bisher nicht absehbar, dass Intel vorsieht zu ermöglichen nur die 512bit Variante anzubieten und dass die Prozessoren dann je nach Fähigkeiten die Arbeitsschritte zerlegen. In dem Falle hätte Intel ja fröhlich die Definition für xmm und ymm Register fallen lassen können.
So wie es jetzt ist, schlägt der Spaß ins Transitorbudget vom Frontend..

Man wird mal abwarten müssen, aber es ist gut, dass Intel die Schwachstellen von IA32 angeht und die Register von 16 auf 32 erweitert.
Und der Rausschmiss einiger legacy Befehle ist auch in der Diskussion :)
 
Zurück
Oben