News Intel Cascade Lake-SP: Weiterhin 3 CPU-Dies, AVX-512-Takt bis zu 900 MHz geringer

ZeroZerp schrieb:
Ich rede von Singlecoreleistung, Latenz und dem was dadurch pro Kern bei der Anwendung ankommt.

Warum sonst läuft der 9900k an der Kotzgrenze? :D
Intel hat nurnoch Takt, und 140W verbauch.
Aber er liefert halt seine 10% mehr dampf durchn takt.
 
  • Gefällt mir
Reaktionen: nazgul77
Shrimpy schrieb:
Warum sonst läuft der 9900k an der Kotzgrenze? :D
Intel hat nurnoch Takt, und 140W verbauch.
Aber er liefert halt seine 10% mehr dampf durchn takt.
Nicht nur das- Er stemmt einfach einen höheren Datendurchsatz bei kurzen Anfragen aufgrund seiner Latenz und seiner Cache- Struktur, was je nach Einsatzgebiet auch nochmal seinen Teil beiträgt.

Und das Produkt aus IPC, Singlecoreleistung und I/O Latenz ist nunmal der Hauptfaktor, der bei 98% der Anwendungen die lauteste Musik spielt.

Zudem läuft er, wenn man die Intel- Empfohlenen Spezifikationen auf den Mainboards einstellt eben nicht an der Kotzgrenze. Bis jetzt gab es von ca. 30 9900K, die durch meine Hände liefen (ich weiß... ist nicht viel), keinen einzigen, der nicht auf 5.1 Allcore zu bringen war.
Ja - Wir machen Burn- in Tests und testen auf Kundenwunsch die Güte der CPU.

An der Kotzgrenze läuft dann nur eine Standard- Kühlung... Das Silizium wäre aber willig...
Bei der 08/15 Empfehlung von Intel ist der 9900K weit davon entfernt an der Kotzgrenze zu laufen.

LG
Zero
 
5,1 Ghz All Core ist nicht sinnvoll , noch effektiv , es sind grade mal 400 MHz zum normalen all Core Boost und man braucht ne hochwertige Kühlung , aber hey , einige brauchen halt den längsten .... , + 5-7 % Leistung = + 30 -40 % Leistungsaufnahme .
und wie üblich unterschlägst du die Wirkung von mehr Kernen , längst nicht alle Anwendungen sind auf Single Core Leistung angewiesen ...

Der 8auer hat im bezug auf OC der Ryzen 2000 CPUs festgestellt : Es lohnt nicht , die Booststeuerung ist zu gut , man hat 3,2 % Mehrleistung zu Lasten von 27 % höherer Leistungsaufnahme , das steht in keinem Verhältnis ..

Ich erwarte eigentlich beim Ryzen 3xxx eine ähnlich gute Booststeuerung obwohl ich dort mit einer höheren streuung bei der Chipqualität rechne
 
Zuletzt bearbeitet:
MK one schrieb:
5,1 Ghz All Core ist nicht sinnvoll , noch effektiv
Das habe ich auch nicht geschrieben.
Ich habe auf den Vermerk geantwortet, der es als Fakt dargestellt hat, dass der 9900K default an der Kotzgrenze laufen würde.

und wie üblich unterschlägst du die Wirkung von mehr Kernen , längst nicht alle Anwendungen sind auf Single Core Leistung angewiesen ...
Doch- Genau das. Erhöhte Singlecoreleistung kommt immer und bei jeder Anwendung verwertbar als direkter Geschwindigkeitsbonus zum Tragen. Je höher die Corezahl umso höher die Reibungsverluste/Overhead der CPU und umso Spezieller muss wiederum der Workload sein, die eine große Anzahl an Kernen unterstützt. Also eine hochparallelisierbare Anwendung.

Ich finde es im Übrigen gut, was AMD mit seiner in meinen Augen überlegenen Booststeuerung macht. Es wirkt für mich "granularer" bzw. näher an den tatsächlichen Möglichkeiten des Siliziums.

LG
Zero
 
ZeroZerp schrieb:
Nicht nur das- Er stemmt einfach einen höheren Datendurchsatz bei kurzen Anfragen aufgrund seiner Latenz und seiner Cache- Struktur, was je nach Einsatzgebiet auch nochmal seinen Teil beiträgt.

Durchsatz und Latenz korrelieren nur, sofern kleinste Datenmengen an zufälligen Positionen im Arbeitsspeicher abgerufen werden. Das ist nur ein Spezialfall, der nur einen kleinen Beitrag zum durchschnittlichen Durchsatz leistet.

ZeroZerp schrieb:
Und das Produkt aus IPC, Singlecoreleistung und I/O Latenz ist nunmal der Hauptfaktor, der bei 98% der Anwendungen die lauteste Musik spielt.

Ganz sicher nicht "98%" aller Anwendungen bei einer Mixtur aktueller Anwendungen. Da ist die Multi-Thread-Leistung entscheidender.

in practice, almost all modern workloads are multi-threaded to some extent


Ich habe den Eindruck du stellst in deinen Beiträgen sehr viele Behauptungen ohne Quelle auf und überlässt es anderen viele dieser Behauptungen zu wiederlegen.
Ergänzung ()

ZeroZerp schrieb:
Doch- Genau das. Erhöhte Singlecoreleistung kommt immer und bei jeder Anwendung verwertbar als direkter Geschwindigkeitsbonus zum Tragen. Je höher die Corezahl umso höher die Reibungsverluste/Overhead der CPU

Hier muss man differenzieren. Was genau verstehst du unter "Erhöhte Singlecoreleistung"? Taktsteigerung per Boost oder höhere IPC?

Was genau soll "Reibungsverluste/Overhead" bei steigender Zahl CPU-Kerne sein??
 
  • Gefällt mir
Reaktionen: Suteki und rg88
nazgul77 schrieb:
Was genau soll "Reibungsverluste/Overhead" bei steigender Zahl CPU-Kerne sein??

Die Synchronisation und der Abgleich kostet mit einer steigender Kernzahl immer mehr Leistung. Schaue dir mal an wie Cinebench im Benchmark funktioniert um mal zu sehen, wie schon bei der einfachsten Form es zu "Problemen" führt. Bei Cinebench werden Teile von einem Bild auf einzelne Threads aufgeteilt und berechnet,, je nach Komplexität ist so ein Teil schneller fertig und bekommt danach das nächste Teilstück zur Berechnung.

Jetzt stelle dir aber mal vor, du benötigst immer ein komplettes Bild, um mit dem nächsten Abschnitt fortfahren zu können. Bei diesem Fall können viele Kerne gar nichts tun, obwohl sie ihr "Datenpäckchen" schon abgearbeitet haben und natürlich benötigst du auch noch zusätzliche Threads, die die einzelnen Ergebnisse zu einem Ganzen zusammenfügen und sich um eine sinnvolle Aufteilung der Arbeit auf die einzelnen Threads kümmern.

Es entsteht also schnell ein Overhead, der mit einer steigenden Kernzahl immer grösser wird. Die wenigsten Anwendungen skalieren fast perfekt linear mit einer steigenden Anzahl der Kerne, während dies bei einem steigenden Takt meist der Fall ist.

nazgul77 schrieb:
in practice, almost all modern workloads are multi-threaded to some extent

Ein schönes Zitat, allerdings sagt der Text den du zitierst, genau das Gegenteil von dem was du behauptest!
Generally speaking, lightroom, photoshop, and chrome, are going to be a mixed bag depending on how they are used. For batch rendering from lightroom, core count is important. For most manipulations in photoshop, core count doesn't help much. Chrome, spawns at least 1-2 new threads for every tab opened, and spreads its core into numerous threads right off the bat. Chrome makes use of more CPU's if the user creates conditions that demand it (opening lot of tabs containing very active websites).

Was bedeutet es im einzelnen? Wenn du Batchberechnungen im Photoshop machst oder zig Tabs im Chrome geöffnet hast, profitierst du von mehreren Kernen. Für die eigentliche Arbeit mit Photoshop oder für jede einzelne Webseite nützen dir hingegen viele Kerne gar nichts, sondern nur eine möglichst hohe IPC und Takt.

Der Punkt ist, von einem höheren Takt, höherem IPC und niedrigeren Latenzen profiziert jede Anwendung bei jeder Arbeitslast, von mehreren Kernen profitieren hingegen "nur" Aufgaben die sich entsprechend aufteilen lassen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tomasvittek, kisser und .Sentinel.
rg88 schrieb:
Genau darum gings doch: Wirklich Chiplets oder doch ein SoC im Desktop?

Ich wollte eigentlich die Vermutung ausdrücken dass bei einem monolithischen Desktop-Die auch die Server-CPU keine Chiplets gehabt hätte. Der Aufwand für zwei komplett unterschiedliche Designs wäre meines Erachtens zu groß gewesen.

Aber hier gehts um Intels Hitzköpfe, ich wollte eigentlich nur darauf hinweisen dass die Frage wann AMD informiert wurde noch offen ist. Und damit, was mich angeht, wieder zurück zum Thema.
 
@chithanh, @RYZ3N:

Mir ging’s eher darum, daß HEDT ungleich Serversegment ist, nichts anderes wollt ich ausdrücken. Wie gut Intel - oder AMD — da jeweils aufgestellt ist, war an der Stelle für mich erstmal nebensächlich.

Man kann ja von der Scalable Xeon Plattform halten, was man will, aber sie steht nicht in Konkurrenz zu HEDT, sondern zur EPYC Plattform. Da kann man dann diskutieren, was da die bessere Wahl ist.

Threadripper sind weiterhin eine zumindest gefühlte Ausnahme, da sie immer noch nur in Gamerboards gesteckt werden können, wo sie aber eigentlich nicht reingehören. So gesehen stehen die konkurrenzlos da. Ich hoffe mal, daß sich das ändert und daß noch ein ganz paar VIEL mehr WS-Boards für TR4 auf den Markt kommen, nicht die ein(!)stellige Gesamt(!)zahl, die wir grad haben.

Ob und wie Intel dann da kontert oder nicht oder wie oder was ist mir persönlich ziemlich egal. Hindsight is 20/20 und momentan mag ich nicht beurteilen, ob ein Core count in dieser Größenordnung für den gemeinen HeimPC sinnvoll und/oder in sinnvoller Kosten/Nutzen-Relation steht, sei es im Betrieb oder in der Produktion.

Das wird sich zeigen müssen, ebenso wie die Frage, ob es einen Sweet Spot für die Kernanzahl gibt oder ob frei nach RAM ‘je mehr desto gut’ gilt.
 
  • Gefällt mir
Reaktionen: Hayda Ministral
nazgul77 schrieb:
Durchsatz und Latenz korrelieren nur, sofern kleinste Datenmengen an zufälligen Positionen im Arbeitsspeicher abgerufen werden. Das ist nur ein Spezialfall, der nur einen kleinen Beitrag zum durchschnittlichen Durchsatz leistet.
Das ist kein Spezialfall, sondern IMMER gültig. Computer sind grundsätzlich Datenschubser -> 0/1. Jede Anfrage/Operation muss erstmal über die Latenz des I/O Systems. Seis Chipintern oder nach außen hin dann andere Bussysteme.
Je nach Hierarchie passiert das schneller (z.B. Register) oder langsamer (z.B. Bandlaufwerk).

Ganz sicher nicht "98%" aller Anwendungen bei einer Mixtur aktueller Anwendungen. Da ist die Multi-Thread-Leistung entscheidender.
Dann lies nochmal durch was ich geschrieben habe.
Du willst auf einen mehr Kerne= Besser raus und ich habe geschrieben, dass wenig Kerne mit erhöhter Leistung jede Anwendung auf jeden Fall beschleunigen, ob Multicoreaffin oder nicht.
Deshalb ist und bleibt die Singlecoreleistung die Größe, die es nach oben zu schrauben gilt, will man die Geschwindigkeit universell nutzen und nicht nur bei einer mit der Kernzahl immer enger werdenden Softwarebandbreite.
Auch höchst paralellisierbare Anwendungen haben irgendwann den Punkt der Synchronisation. Und dann kommts zu einer sequenzielle und nicht parallelen Aufgabe des Abgleichs.

Multicore im übergeordneten Sinn ist im Standardeinsatz schon deshalb sinnvoll, weil ein Betriebssystem z.B. im Hintergrund mehrere getrennt voneinander operierende Instanzen ausführt. Dies kann dann auch zu 100% asynchron passieren.

Ich habe den Eindruck du stellst in deinen Beiträgen sehr viele Behauptungen ohne Quelle auf und überlässt es anderen viele dieser Behauptungen zu wiederlegen.
Das ist richtig. Ich habe mir angewöhnt Quellen und Erklärungen inzwischen nur auf Nachfrage zu liefern, da ich auch gemerkt habe, dass hier im Forum 90% der Teilnehmer nicht an einer ernsthaften Diskussion interessiert sind, sonder einfach ihren Markenfetischismus und den sich daraus ergebenden Scharmützeln hingeben.
Wenn ich merke, dass jemand ernsthaft an einer Diskussion interessiert ist, dann grabe ich auch gerne tiefer. Ansonsten ist es mir die Zeit/den Aufwand nicht wert, weil zu viele User schon bei einer logischen Argumentation/einfachen Erklärung des Sachverhalts ohne Quellen schon aussteigen und selbst bei ihren Ausführungen keine liefern.

Hier muss man differenzieren. Was genau verstehst du unter "Erhöhte Singlecoreleistung"? Taktsteigerung per Boost oder höhere IPC?
Singlecoreleistung muss man nicht differenzieren, weil sie das Produkt einzelner Faktoren darstellt. Welcher Faktor wieviel dazu beiträgt ist irrelevant.

Den Rest hat der Kollege xexex schon "bebildert".

Grüße
Zero
Ergänzung ()

RalphS schrieb:
Das wird sich zeigen müssen, ebenso wie die Frage, ob es einen Sweet Spot für die Kernanzahl gibt oder ob frei nach RAM ‘je mehr desto gut’ gilt.
Das kommt auf die Anwendung an. Im Normalfall sinkt dir Effizienzkurve ab 16 Threads sprich 8 Kernen mit jedem zusätzlichen Kern. Ab 64 Kernen erhalten wir selbst bei stark paralellisierbaren Aufgaben eine starke Abflachung, wo die jeweilige Verdoppelung dann einen immer geringeren Effekt zeigt.

Hier eine Illustration/ein Beispiel dafür:
https://plumbr.io/blog/performance-blog/amdahls-law-illustrated

Grüße
Zero
 
Zuletzt bearbeitet:
zu einfach ausgedrückt , zu unvollständig ....
https://de.wikipedia.org/wiki/Amdahlsches_Gesetz

Amdahls Gesetz ist eines der pessimistischsten zur Abschätzung des theoretischen Speedups, da es einige positive Faktoren nicht berücksichtigt. Nach Amdahl ist die größtmögliche Beschleunigung linear, also durch die 10-fache Anzahl von Kernen ist maximal die 10-fache Rechenleistung möglich. Jedoch ist in jeder CPU auch Cache integriert, so dass sich auch die Menge an schnellem Speicher verzehnfacht. Im günstigsten Fall ist es so möglich, die gesamte Problemgröße im Cache anstatt im langsamen Hauptspeicher zu halten, was einen super-linearen Speedup ermöglicht, also Beschleunigung, die über die zusätzliche, reine Rechenleistung hinausgeht. Allerdings könnte dies darauf zurückzuführen sein, dass der Vergleich aus dem Grund fehlerhaft ist, dass der integrierte Cache als Teil des Prozessormoduls betrachtet wird. Ein Vergleich ohne Berücksichtigung der Cache-Größe würde nicht zu dem benannten super-linearen Speedup führen. Amdahls Betrachtung für den maximalen Speedup bleibt jedoch in beiden Fällen gültig.

Weiterhin geht Amdahl in seiner Rechnung davon aus, dass die Problemgröße unverändert bleibt; das Ziel ist also, ein Problem in möglichst kurzer Zeit zu berechnen. Für den Fall, in der gleichen Zeit ein größeres Problem zu berechnen, ergeben sich günstigere Voraussetzungen, da der parallele Anteil je nach Problem dann sehr groß werden kann. Je länger eine Berechnung dauert, desto weniger fällt die Zeit für die Initialisierung und abschließende Synchronisierung ins Gewicht.

Grakas setzen übrigens wesentlich mehr als 64 Kerne ein , man kann da bei der Titan V von 5120 Kernen = Cuda Einheiten sprechen ...
Da man nicht unbegrenzt hochtakten kann , im Grunde hängt man schon seit 10 Jahren bei +/- 5 Ghz rum , bleibt eigentlich nur der Weg in die Breite = mehr Kerne übrig , größere Kerne sind da auch keine Lösung , weil diese beinhalten dann auch nur wieder mehr parralell arbeitende Einheiten .
Paradebeispiel für parralelle Bearbeitung : SMD + AVX erst 128 bit dann AVX2 mit 256 bit und zuletzt AVX 512 , bei letzteren muß Intel mittels AVX offset deutlich runtertakten damit das Kühlsystem nicht überlastet wird
 
@MK one
Du weisst schon, dass mein Link ein Praxisszenario beinhaltet, an welchem das Amdahlsche Gesetz illustriert wurde? Ich liefere im Übrigen in meinem Post garkeine Erklärung oder Ausführung zu dem Gesetz.

Dennoch danke für die weiteren Ausführungen.

Die Workload einer GPU und derer Arbeitsweise hat im Übrigen wenig mit der einer CISC- CPU gemein.
Wenn man da Vergleiche ziehen wollen würde, dann müsstest Du hier die Compute Units gegen die CPU Cores stellen und da bewegen wir uns derzeit um die 60 bei den größten Karten.

LG
Zero
 
Zuletzt bearbeitet:
ach bitte ... , CISC wird seit geraumer Zeit bereits in Micro Ops zerlegt so das die Micro Ops schon eher eher RISC entsprechen ...

https://de.wikipedia.org/wiki/Complex_Instruction_Set_Computer
CPUs mit CISC-Befehlssatz waren lange Zeit mikroprogrammiert. Heute findet man kaum noch mikroprogrammierte CISC-CPUs. Ab dem Pentium Pro verfügen die Intel-Prozessoren über eine vorgeschaltete Funktionseinheit, die komplexe Befehle in RISC-ähnliche einfache Befehle übersetzt, die ein RISC-ähnlicher CPU-Kern dann ausführt. Je nach Hersteller und CPU werden diese Einheiten ROP, Micro-Op oder µOp genannt.

im übrigen ändert das nichts daran das GraKa s als Beschleuniger bei Servern und bei Pro Anwendungen im PC fungieren
außerdem meine ich das ein Cuda Core die kleinste eigenständige Recheneinheit ist bei NV , nur AMD / ATI hat CU s , wo GCN Kerne zu CU s zusammengefasst sind weil sie Ressourcen teilen und die CU daher die kleinste eigenständige Einheit ist ....
 
Zuletzt bearbeitet:
MK one schrieb:
ach bitte ... , CISC wird seit geraumer Zeit bereits in Micro Ops zerlegt so das die Micro Ops schon eher eher RISC entsprechen ...
Und das macht sie in Deinen Augen zu "waschechten" Risc- Prozessoren? Wie werden denn die Befehle im Frontend verarbeitet? Du fügst doch die Einschränkungen, die die Aussage ungültig werden lassen in Deiner eigenen Ausführung schon bei?

im übrigen ändert das nichts daran das GraKa s als Beschleuniger bei Servern und bei Pro Anwendungen im PC fungieren
Gedankensprung? Das Thema wurde hier doch garnicht angeschnitten?

außerdem meine ich das ein Cuda Core die kleinste eigenständige Recheneinheit ist bei NV , nur AMD / ATI hat CU s , wo GCN Kerne zu CU s zusammengefasst sind weil sie Ressourcen teilen und die CU daher die kleinste eigenständige Einheit ist ....
Was hat das damit zu tun, dass CPUs und GPUs und deren Workloads nicht vergleichbar sind? Und auch dass ein Cuda Core oder ein Shader nicht mit einem CPU Kern vergleichbar ist?

Mensch- Bleiben wir doch mal beim Thema :) Hier werden ja schon wieder x Dinge reinverwurstet...

Grüße
Zero
 
Zuletzt bearbeitet:
DJMadMax schrieb:
Wieso eigentlich ist in den letzten Jahren das Thema "AVX" so wichtig geworden im Consumer Markt? Wieso wird das mittlerweile in sämtlichen Benchmarks und CPU-News erwähnt? Früher gab's die Instruktionen doch auch schon und niemand hat sich darum gekümmert - höchstens waren einige verwundert, dass bei der einen der drei Benchmark-Settings im Prime95 die CPU immer deutlich wärmer wurde ^^

Ist AVX denn so präsent im Endkundensektor? Welche täglich eingesetzte Software setzt denn auf AVX-Instruktionen? Und WAS genau ist eigentlich so anders an den AVX-Instruktionen, dass die CPU hier "mehr" arbeiten muss? Ich will, dass meine CPU auch in Nicht-AVX-Anwendungen "mehr" arbeiten muss und da noch mehr Dampf entwickelt (laienhaft überdramatisiert dargestellt).

AVX muss ja irgendwo einen Vorteil bringen, sonst wäre es ja nicht so, dass man auf diese Instruktionen setzen würde, gleichzeitig jedoch bis zu 20% des CPU-Taktes verlieren würde. Diesen enormen Taktverlust muss man ja erst einmal wieder wettmachen.

Ich habe meinen i5 8600k z.B. auf 5GHz Allcore laufen (Custom WaKü mit 2x360er dicken Kupfer-Radiatoren) und der AVX-Offset ist bei mir bewusst aus - ohne größere Probleme in Prime95.

ich möchte mich hier mal mit-ranhängen. hat dazu wer ne antwort? das interessiert mich nämlich auch!

übrigens: danke an alle beteiligten in der diskussion. habe hier in eurer diskussion ne menge sachen gelernt. so macht forum spass!
 
  • Gefällt mir
Reaktionen: DJMadMax
Weil man mittlerweile encodieren muß , soll 4K Material nicht in die 100 GB pro 60 min Video Kategorie fallen .
Videos zu encodieren mittels H265 bei 4 K Material ist eigentlich Standard geworden , Rohmaterial braucht unglaublich viel Platz ...
Man kann zwar die GPU zur encodierung mit hinzuziehen , aber meist wird immer noch mit der CPU encodiert , weil qualitativ hochwertiger und flexibler und da macht sich AVX extrem bemerkbar .

Transcodieren ist ein weitere Anwendungsmöglichkeit um Video Material aufs Handy zu bringen oder aufs Tablet .
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tomasvittek
@chithanh - alles bekannte Fakten,trotzdem muß man nun sehen ob HEDT Kunden damit klar kommen.Letzten
Endes kann auch im Serverbereich eine gewisse Handhabungssicherheit nichts schaden. Die flinken Chinesen am Band kommen damit vielleicht noch klar. Wehe ein Service Techniker der eh nicht viel Zeit hat, muss sich damit herumärgern, erst Mal eine CPU vom Kühler zu klauben und nach dem Wechsel beten, das es sie wieder Kontakt bekommt.
 
ZeroZerp schrieb:
@MK one
Du weisst schon, dass mein Link ein Praxisszenario beinhaltet, an welchem das Amdahlsche Gesetz illustriert wurde? Ich liefere im Übrigen in meinem Post garkeine Erklärung oder Ausführung zu dem Gesetz.
Ich komme aus der Programmierung und das Amdahlsche Gesetz ist nur der absolute Worst-Case der Parallelisierung.

Viel relevanter in der Praktischen Informatik ist das Gustafsons Gesetz, welches beschreibt wie viel 'Mehrarbeit' man in einer gewissen Zeit machen kann.
Und in dem Fall gibt es viele Algorithmen welche sich sehr gut auf viele CPU Kerne Skalieren lassen.

Ein Möglichkeit der Skalierung ist z.B. die genannte 'Batch Verarbeitung'.
Ich kann 100Bilder auf 1 CPU Kern machen, oder Ich mache >1500 auf einem 16 Kerner in der gleichen Zeit.

Oder bei Grafikkarten die Bildberechnung. Raytracing z.B. lässt sich nahezu linear auf mehr Kerne verteilen. Sofern das IO System entsprechend Dimensioniert ist.

Oftmals liegt die schlechte Skalierung auf mehrere Kerne nicht am Prozessor, sondern an einer schlechten Programmierung.
Bei uns haben von 10 Programmierer nur 2 bereits mit Multithreading gearbeitet, bzw. implementiert.
 
  • Gefällt mir
Reaktionen: .Sentinel. und rg88
DJMadMax schrieb:
Wieso eigentlich ist in den letzten Jahren das Thema "AVX" so wichtig geworden im Consumer Markt? Wieso wird das mittlerweile in sämtlichen Benchmarks und CPU-News erwähnt? Früher gab's die Instruktionen doch auch schon und niemand hat sich darum gekümmert - höchstens waren einige verwundert, dass bei der einen der drei Benchmark-Settings im Prime95 die CPU immer deutlich wärmer wurde ^^

Ist AVX denn so präsent im Endkundensektor? Welche täglich eingesetzte Software setzt denn auf AVX-Instruktionen? Und WAS genau ist eigentlich so anders an den AVX-Instruktionen, dass die CPU hier "mehr" arbeiten muss? Ich will, dass meine CPU auch in Nicht-AVX-Anwendungen "mehr" arbeiten muss und da noch mehr Dampf entwickelt (laienhaft überdramatisiert dargestellt).

AVX muss ja irgendwo einen Vorteil bringen, sonst wäre es ja nicht so, dass man auf diese Instruktionen setzen würde, gleichzeitig jedoch bis zu 20% des CPU-Taktes verlieren würde. Diesen enormen Taktverlust muss man ja erst einmal wieder wettmachen.

Ich habe meinen i5 8600k z.B. auf 5GHz Allcore laufen (Custom WaKü mit 2x360er dicken Kupfer-Radiatoren) und der AVX-Offset ist bei mir bewusst aus - ohne größere Probleme in Prime95.

Ich zitiere mich hier einfach noch einmal selbst mit zusätzlicher Ernennung von @tomasvittek, den das Thema offenkundig ebenfalls zu interessieren scheint.

Vielleicht wissen ja einige unserer Foren-Altgesteine etwas mehr darüber, z.B. @HisN oder @burnout150 oder eventuell stolpert ja auch der gute @Volker mal über die Frage und kann auf etwas Wissenswertes verweisen - oder mal einen passenden "Test" in naher Zukunft anstoßen so als Artikel? :)
 
Zurück
Oben