Ja gut wenn es die software nur nicht kann weil der Software die logischen Kerne ausreichen. Dann werden die recheneinheiten nicht optimal ausgelastet. Und dann müsste die CPU auch weniger Strom verbrauchen und auch weniger Abwärme produzieren. Ja moment mal bei Spielen ja da ist dies na schon der Fall. Nur wenn es bei den Anwendung ebenso ist, dann sieht es ja wieder anderst aus.
News AMD Ryzen: Hybrid-Prozessoren sollen nicht Intels Ansatz folgen
- Ersteller PCGH-Redaktion
- Erstellt am
bitsbytes
PC-Selbstbauer(in)
Macht jemand von Euch auch recording, Anwendungen mit near-realtime Anforderungen?
Wie sieht es mit der Verteilung von ASIO Treibern, DAW (digital audio workstation) Applikationen, VSTs und VSTis aus? Muss man demnächst damit anfangen, zig Programme irgendwo im CPPC nachzujustieren, wo die zu laufen haben? Das hört sich für mich nach viel zu viel Fummelei an.
Oder wie wirkt sich dass auf DPC Latenzen (-> Latency Mon) aus?
Beim Recorden möchtest Du u.a. gerne effiziente Treiber haben, so dass CPU Kerne möglich nicht durch schlechte Treiber blockiert werden.
Jetzt wird das ganze noch durch unterschiedliche Arten von Kernen "möglicherweise" verkompliziert.
Bei Recording Anwendungen möchte man sowieso eines nicht .. energiesparen ... da zählt nur Power und Effizienz und u.a. auch eine hohe single thread performance.
Ich stehe dem ganzen mit dieser Mischung aus P- und E-Cores sehr skeptisch gegenüber.
Wenn ich mit meinem System Energie sparen möchte, dann geschieht das automatisch über
Bitsums "Process Lasso Pro". Da kann ich das System generell auf Energieprofil "Balanced" stellen.
Wenn ich mal am Rechner nicht aktiv bin wird bei mir nach 15 Secunden über das Feature IDLE saver das Energiesparprofil eingestellt.
Darüber hinaus kann ich Applikationen, die ein Energieprofil (Bitsums highest Performance) zuweisen, dass dann auch den IDLE Saver zur Laufzeit deaktiviert. Manche Applikationen brauchen die Power auch dann, wenn ich als user IDLE bin. Games per Steam werden auch erkannt wenn ich das noch richtig in Erinnerung habe.
Dieses "dynamische" Umschalten des Stromverbrauchs finde ich viel praktischer, also dieses Rumgewurschtele mit unterschiedlich Performanten Kernen. Am Ende gibt es genug Situationen, in denen man eigentlich nichts also schiere Performance und geringstmögliches Lag (DPC Latenzen, "whatever") haben möchtest.
Nicht nur beim Recorden, natürlich auch beim Gamen (keine Ruckler, fps, ..).
Wie sieht es mit der Verteilung von ASIO Treibern, DAW (digital audio workstation) Applikationen, VSTs und VSTis aus? Muss man demnächst damit anfangen, zig Programme irgendwo im CPPC nachzujustieren, wo die zu laufen haben? Das hört sich für mich nach viel zu viel Fummelei an.
Oder wie wirkt sich dass auf DPC Latenzen (-> Latency Mon) aus?
Beim Recorden möchtest Du u.a. gerne effiziente Treiber haben, so dass CPU Kerne möglich nicht durch schlechte Treiber blockiert werden.
Jetzt wird das ganze noch durch unterschiedliche Arten von Kernen "möglicherweise" verkompliziert.
Bei Recording Anwendungen möchte man sowieso eines nicht .. energiesparen ... da zählt nur Power und Effizienz und u.a. auch eine hohe single thread performance.
Ich stehe dem ganzen mit dieser Mischung aus P- und E-Cores sehr skeptisch gegenüber.
Wenn ich mit meinem System Energie sparen möchte, dann geschieht das automatisch über
Bitsums "Process Lasso Pro". Da kann ich das System generell auf Energieprofil "Balanced" stellen.
Wenn ich mal am Rechner nicht aktiv bin wird bei mir nach 15 Secunden über das Feature IDLE saver das Energiesparprofil eingestellt.
Darüber hinaus kann ich Applikationen, die ein Energieprofil (Bitsums highest Performance) zuweisen, dass dann auch den IDLE Saver zur Laufzeit deaktiviert. Manche Applikationen brauchen die Power auch dann, wenn ich als user IDLE bin. Games per Steam werden auch erkannt wenn ich das noch richtig in Erinnerung habe.
Dieses "dynamische" Umschalten des Stromverbrauchs finde ich viel praktischer, also dieses Rumgewurschtele mit unterschiedlich Performanten Kernen. Am Ende gibt es genug Situationen, in denen man eigentlich nichts also schiere Performance und geringstmögliches Lag (DPC Latenzen, "whatever") haben möchtest.
Nicht nur beim Recorden, natürlich auch beim Gamen (keine Ruckler, fps, ..).
Nun ich gebe zu ich mache zwar selbst auch mal recording aber nicht in den großen maße wie du es machst. Nur gelegentlich nehme ich sowas wie ein Video aus dem Internet auf. Weil man ja heutzutage manche Videos nicht mehr so herunterladen kann. Sind halt so eingebettet Videos. Nun ja ne andere Option gibt es halt nicht.
Dank dem Programm könnte man bei mehreren Programmen auch zielgerichtet zuordnen. Ich selbst habe leider nicht die pro Version. Sollte ich mir echt mal holen. Weil damit steigerte ich die effizientes auch beim Video umwandeln sehr.
Bei wem einen threadripper 24 Kerner zielgerichtet fest an einer Programm und das zweite die anderen. So war dann mit 2x12 kernen die CPU optonimaler ausgelastet gewesen. Die aktuelle threadripper der 5000 Serie brachte das jedoch nix mehr. Scheinbar hat AMD hier richtig optimiert sodass die CPU nun viel besser arbeitet. Man merkt also durch aus die Unterschiede.
Aber selbst bei meiner CPU könnte das Wunder vollbringen. Ich weiß nicht wie gut es auf meinen dann laufen würde. Das wären ja dann 2x8 kerne mit smt. Also jeder bekommt 16 Thread fest zugeordnet.
Bei den e und p kernen habe ich das so noch nicht gemacht gehabt. Aber scheinbar muss man das ja machen weil windows 11 scheint da ja total blöd zu sein mit 2 gleichen taks nicht klar zu kommen. So viel zu optimiert. Also ich weiß zwar nicht was sie alles bei Intel optimiert haben aber scheinbar nicht gründlich genug. Hier kommt man in dem Falle nicht um ein externes Tool wie Picasso drum rum.
Und wer weis was man da aus der CPU noch holen könnte.
Es wäre also durchaus interessant entweder bekommt 2x4 p und 2x8 e Kerne oder Programm 8 p kerne und das zweite Programm die e Kerne.
Wäre also durchaus interessant was dann passieren würde. Im taskmanger kann man das ja nicht ganz so optimal zuordnen und dann auch für immer nie.
Aber gut software ist halt was kann man da schon erwarten eben nicht so gut. Das kennt man ja nicht anderst. Ich finde es schade das es dir Hardware alles richten muss, aber da kommt man nicht drum rum.
Ich hoffe jedenfalls das es AMD besser hinkriegt als Intel.
Dank dem Programm könnte man bei mehreren Programmen auch zielgerichtet zuordnen. Ich selbst habe leider nicht die pro Version. Sollte ich mir echt mal holen. Weil damit steigerte ich die effizientes auch beim Video umwandeln sehr.
Bei wem einen threadripper 24 Kerner zielgerichtet fest an einer Programm und das zweite die anderen. So war dann mit 2x12 kernen die CPU optonimaler ausgelastet gewesen. Die aktuelle threadripper der 5000 Serie brachte das jedoch nix mehr. Scheinbar hat AMD hier richtig optimiert sodass die CPU nun viel besser arbeitet. Man merkt also durch aus die Unterschiede.
Aber selbst bei meiner CPU könnte das Wunder vollbringen. Ich weiß nicht wie gut es auf meinen dann laufen würde. Das wären ja dann 2x8 kerne mit smt. Also jeder bekommt 16 Thread fest zugeordnet.
Bei den e und p kernen habe ich das so noch nicht gemacht gehabt. Aber scheinbar muss man das ja machen weil windows 11 scheint da ja total blöd zu sein mit 2 gleichen taks nicht klar zu kommen. So viel zu optimiert. Also ich weiß zwar nicht was sie alles bei Intel optimiert haben aber scheinbar nicht gründlich genug. Hier kommt man in dem Falle nicht um ein externes Tool wie Picasso drum rum.
Und wer weis was man da aus der CPU noch holen könnte.
Es wäre also durchaus interessant entweder bekommt 2x4 p und 2x8 e Kerne oder Programm 8 p kerne und das zweite Programm die e Kerne.
Wäre also durchaus interessant was dann passieren würde. Im taskmanger kann man das ja nicht ganz so optimal zuordnen und dann auch für immer nie.
Aber gut software ist halt was kann man da schon erwarten eben nicht so gut. Das kennt man ja nicht anderst. Ich finde es schade das es dir Hardware alles richten muss, aber da kommt man nicht drum rum.
Ich hoffe jedenfalls das es AMD besser hinkriegt als Intel.
Für SMT braucht man mindestens einen zweiten Satz Register für den Programmkontext des zweiten Threads und was auch immer man braucht, damit ein Betriebssystem eine weitere CPU erkennt. Ist insgesamt nicht viel und die frühen Atoms hatten z.B. SMT statt Out-of-Order-Execution, weil SMT ähnliche Probleme lindert. Daraus könnte man schließen, dass SMT weniger aufwändig ist, vielleicht aber auch, dass es bei niedrigen Kernzahlen besser skaliert, ich tippe jedoch auf ersteres oder beides.Nach meinem Kenntnisstand ist SMT rein virtuell, das heißt es verbessert nur die Ausnutzung bestehender Transistoren und Sonstigem, und braucht keine zusätzliche hardware auf der CPU.
Falls ich mich da täusche, darfst du mich aber gern eines Besseren belehren.gif "sm_=) =)")
Da gibt es wirklich viel Spielraum. Man könnte prinzipiell die Recheneinheiten von allen Kernen zusammenlegen und daraus einen CPU-Kern mit n-fach SMT machen. Allerdings bekommt man dann vermutlich zu große Verzögerungen bei der Auswahl des nächsten Threads oder bis ein Thread wieder dran ist. Ich vermute, dass in der Praxis nur Platz für einen zweiten Programmkontext geschaffen wird, um überschüssige Einheiten auszulasten. CPUs haben ja die meisten Einheiten mehrfach, damit man aufeinander folgende Befehle, die unabhängig von den vorhergehenden, sich noch in der Pipeline befindlichen, Befehlen sind, parallel ausgeführt werden können. Da gibt es ein typisches Limit, wie viel da in der Regel möglich ist. Um maximale sequentielle Performance zu gewährleisten ist die Anzahl der Einheiten entsprechend großzügig dimensioniert, so dass oft Einheiten frei bleiben. Wenn dann der aktuelle Thread ins Stocken kommt, können diese im Moment überschüssigen Einheiten von einem zweiten genutzt werden. Kann natürlich aber auch sein, dass für bestimmte SMT-Implementierungen einzelne Einheiten, die besonders in so einem Fall doch in einem "Single-Thread-Kern" nicht oft genug vorkommen und so den Effekt von SMT stark behindern würden, entsprechend öfter vorhanden sind.
Kann man vermutlich so stehen lassen. Der einzige Sinn, sich gegen SMT zu entscheiden sind vermutlich Marketing, Defekte, wenn die CPU intern nicht parallel genug aufgebaut ist, dass sich das lohnt, wenn man sich ausrechnet, dass die Komplexität für einen Scheduler, noch mehr Threads zu verwalten, höher ist als der Nutzen oder eben irgendeine Kombination davon.
Jein. An sich ist das so intuitiv und würde auch stimmen, gäbe es da nicht die Turbos. Die sorgen dafür, dass ein Überschuss im Energiebudget in mehr Takt umgesetzt wird. Eine CPU würde bei besserer Auslastung also niedriger Takten, aber trotzdem mehr schaffen.
IBM hat 8 fach SMT, also soo theoretisch ist die Überlegung garnicht.
Power-Architektur – Wikipedia
Aber auch das sind physische Mehrkerner, nur eben mit mehrfachem SMT. Was ich meinte, wäre ein einzelner physischer Kern, der die Recheneinheiten von vielen Kernen vereint und diese dann nur per SMT aufteilt. Aber ja, mehrfaches SMT gab es schon in der Praxis. SMT kann Latenzen verstecken, solange genug Threads vorhanden sind und spart Zeit bei Kontextwechseln. Wenn man sehr viele Threads pro Kern laufen lassen möchte und nebenbei viellecht mit höheren Latenzen zu kämpfen hat, wie z.B. in Supercomputern, deren einzelne Knoten mit irgendeinem Netzwerk verbunden sind, kann man da viel gewinnen. Ich habe mich schon öfter gefragt, warum man im x86-Bereich bis jetzt nur 2-fach SMT gesehen hat, aber irgendeinen Grund wird es geben. Und wenn es nur ist, weil alles andere im Desktopsegment zu Problemen führt und der Gewinn im Serverumfeld zu gering ist.
SMT soll vor allem Wartezeiten maskieren – braucht Operation B zwingend die nicht vorhersagbaren Ergebnisse von Operation A, dauert es eben einen kompletten Pipeline-Durchlauf, ehe der gleiche Thread weiterarbeiten kann und Daten aus L3 oder gar RAM sind sowieso ewig unterwegs. Arbeitet man in der Zwischenzeit an einem anderen Thread, der schon vor längerer Zeit alles angefordert/vorbereitet hat und seitdem warten musste, laufen die Recheneinheiten nicht leer und man gewinnt Leistung. Wie groß dieser Anteil an Wartezyklen wäre, hängt aber stark von der Anwendung an. Zum Beispiel Vierfach SMT wurde im Serverbereich schon oft eingesetzt; ich tippe mal darauf das Datenbanken häufiger was mit Daten machen. .gif "sm_B-) :-)")
Bei gut optimierten respektive von Sprungvorhersage und Prefetchern gut vorhersagbaren Code stellt sich das Problem dagegen gar nicht erst, also reicht 2-fach SMT oder es stört sogar schon, weil die abwechslende Bearbeitung letztlich natürlich eine Verzögerung im Ablauf jeden einzelnen Thread bedeutet.
@empy: Register wurden von Intel meiner Erinnerung nach als gemischt genutzte Ressource klassifiziert, bei der sich jeder Thread gerade eine beliebige freie Ressource schnappt, von denen insgesamt halt etwas mehr da sein sollte. Ich schätze mal, durch CISC-to-RISC ist man bei der Zuordnung von physischen Speicherelementen und logischen Registern sowieso flexibel. Die SMT-Implementierung bei Bonnell war durch In-Order auf alle Fälle deutlich einfacher und hatte bezüglich der Auslastung einen ähnlichen Effekte wie OoO: Man konnte die Pipeline länger lassen und hatte trotzdem immer dispatch bereite Instruktionen zur Hand. Das im Gegenzug die Bearbeitungslatenz innerhalb der Threads anstieg, war für das Anwendungsgebiet dagegen egal – die Software wollte sowieso mehr Berechnungen gelöst haben, als die kleinen Atoms ASAP durchführen konnten.
Bei gut optimierten respektive von Sprungvorhersage und Prefetchern gut vorhersagbaren Code stellt sich das Problem dagegen gar nicht erst, also reicht 2-fach SMT oder es stört sogar schon, weil die abwechslende Bearbeitung letztlich natürlich eine Verzögerung im Ablauf jeden einzelnen Thread bedeutet.@empy: Register wurden von Intel meiner Erinnerung nach als gemischt genutzte Ressource klassifiziert, bei der sich jeder Thread gerade eine beliebige freie Ressource schnappt, von denen insgesamt halt etwas mehr da sein sollte. Ich schätze mal, durch CISC-to-RISC ist man bei der Zuordnung von physischen Speicherelementen und logischen Registern sowieso flexibel. Die SMT-Implementierung bei Bonnell war durch In-Order auf alle Fälle deutlich einfacher und hatte bezüglich der Auslastung einen ähnlichen Effekte wie OoO: Man konnte die Pipeline länger lassen und hatte trotzdem immer dispatch bereite Instruktionen zur Hand. Das im Gegenzug die Bearbeitungslatenz innerhalb der Threads anstieg, war für das Anwendungsgebiet dagegen egal – die Software wollte sowieso mehr Berechnungen gelöst haben, als die kleinen Atoms ASAP durchführen konnten.
Wobei nicht gesagt ist, dass SMT Threads abwechselnd verarbeitet. Ich glaube sogar, dass das bei x86 selten passiert und der Wechsel eher gemacht wird, wenn irgendeine Latenz auftritt. Alles andere würde den sequentiellen Fluss einzelner Threads ja halbieren.
Puh, mag sein, aber eigentlich müsste die Anzahl der Register im Befehlssatz festgelegt sein und man braucht halt genau so viele, wie man maximal brauchen könnte und das halt pro Thread. Der Witz von SMT ist ja genau, dass man nicht wie bei einem "normalen" Kontextwechsel die Register füllen muss, bevor man losrechnen kann und wenn da zu wenig Register vorhanden wären, würde das jeglichen Vorteil in einem Konfliktfall komplett vernichten. Von daher und auch weil es wirklich nur sehr wenig Fläche braucht, ich habe jetzt bei einer kurzen Suche irgendwas von acht allgemeinen Registern gelesen, also irgendwas in der Größenordnung von deutlich unter einem KB, denke ich nicht, dass man das riskieren möchte. Außerdem würde ein Mapping ja auch Zeit oder Transistoren kosten.
Nach dem, was ich lese, war die Pipeline von Bonnell mit 16 Stufen nicht sonderlich lang, aber ja, wenn man OoO hat, muss man mehrere Befehle im Voraus betrachten können und das pro Thread. Dementsprechend ist SMT mit OoO aufwändiger als ohne und umgekehrt, aber ich denke auch, dass OoO allgemein aufwändiger als SMT ist. Vermutlich sogar deutlich. Und wie wir ja beide schon gesagt haben, erfüllen sie einen ähnlichen Zweck: Leerläufe vermeiden, wenn Latenzen auftreten. Die Vorteile von OoO hätten aber vermutlich aufgrund der niedrigen Rohleistung der CPUs einfach in keinem Verhältnis zum Aufwand gestanden, das ist ja die andere Seite: Wenn nur wenige und/oder langsame Recheneinheiten verbaut sind, ist es auch leichter, diese trotz Latenzen auszulasten.
OK verstehe. Wie sieht es aus wenn 3s geneu zwischen vollast auf allen kernen und teilst liegt. Dann ist der boost nicht so stark anliegend.
Und naja meine Anwendung scheint ja nichts von beiden zu sein. Weil ein ryzen 9 7950x schafft ja allcore ja was von 5,7 oder ist dies der single core takt davon? Also wenn das so ist, wäre ja da der 5,1 der allcore takt. Stimmt das etwa?
Ps: wie sieht es mit smt und Speicher bandbreite so aus?
Und naja meine Anwendung scheint ja nichts von beiden zu sein. Weil ein ryzen 9 7950x schafft ja allcore ja was von 5,7 oder ist dies der single core takt davon? Also wenn das so ist, wäre ja da der 5,1 der allcore takt. Stimmt das etwa?
Ps: wie sieht es mit smt und Speicher bandbreite so aus?
Zuletzt bearbeitet:
Nathenhale
Volt-Modder(in)
Um das Thema mal etwas auf zu lockern:
But Can it run Crysis ?
Oder Aktuell can it run any AAA game ?
But Can it run Crysis ?
Oder Aktuell can it run any AAA game ?
Infi1337
Freizeitschrauber(in)
Crytek hatte damals im Bezug auf Multithreading auch von 6 GHz gesprochen und wurde ausgelacht, dabei wusste man tatsächlich das es mit dem Multithreading in Games sehr sehr schwierig werden würde, da die Latenz beim Multithreading in Echtzeitanwendungen den tatsächlichen Leistungsvorteil bei den Drawcalls für die GPU auffrisst.
Bezüglich der Frequenzen spricht man von Single-Core bzw. Dual-Core Boost heutzutage nicht mehr von Allcore, zumindest bei "aus der Verpackung".
Es ging aber ja um Chipfläche seitens latiose88, sprich auch wenn es keine zusätzlichen tatsächlichen Einheiten gibt, verbrauchen SMT und HT natürlich trotzdem einkalkulierte physische Chipfläche wegen Hitze und Energie. Aber wahrscheinlich weniger als mehr Cache oder zusätzliche "echte" Kerne, ob das effizienter ist hängt immer von der Anwendung und dem Umgang mit SMT und HT ab.
Ich glaube intern regeln das die Firmen so das man von Leistung bzw. aufgebrachter Energie und Rechenleistung spricht, schwankt natürlich je nach Anwendung, aber sprich etwa 30% mehr Leistung bei etwa 10% mehr Energie pro Kern usw..., gibt natürlich noch SMT4 und auch SMT8.
Bezüglich der Frequenzen spricht man von Single-Core bzw. Dual-Core Boost heutzutage nicht mehr von Allcore, zumindest bei "aus der Verpackung".
Kann durchaus sein. Wenn auf allen Kernen gleichmäßige Teillast anliegt, müssten die Kerne aber ohne SMT vermutlich höher Takten und würden mehr Energie brauchen. Ist aber zugegebenerweise ein seltenes Szenario, weil die Kerne oft schneller und höher takten als sie müssten, damit Lastspitzen abgefangen werden und das System schnell auf Nutzereingaben reagiert. Aber wenn alle Kerne voll ausgelastet sind, bzw. das Energielimit erreicht ist, sollte die Leistung mit SMT höher sein.
Ich habe die Turbostufen für Last auf einer bestimmten Anzahl Kerne nicht im Kopf, aber spezifikationsgemäß sollte er keine 5,7GHz allcore machen. Basistakt sind 4,5GHz, so weit würde er runtertakten, wenn er sonst über dem Powerlimit liegen würde. Ansonsten liegen die Kerne je nach Auslastung irgendwo dazwischen. Allerdings wechselt der Takt deutlich häufiger als die meisten Tools das anzeigen und einzelne Threads werden auch zwischen den Kernen hin- und hergeschoben, so dass das schwer zu dokumentieren ist, wenn ungleichmäßige Last anliegt.
Eine ausreichend hohe Speicherbandbreite sorgt dafür, dass die CPU nicht auf Daten warten muss. Mit SMT wird potenziell mehr gerechnet, also wird auch mehr Speicherbandbreite benötigt, bzw. die vorhandene Bandbreite besser ausgenutzt. Ist also nichts schlechtes, kann aber den Bottleneck Richtung Speicherbandbreite schieben.
Ja ist interessant.Es sei denn man befindet sich ja noch unterhalb des maximums.In falle des 7950x ist es 230 Watt.Er braucht allerdings nur 200 Watt.In dem falle wäre es mal interessant ob die Aussage stimmt,dann müsste es ja ohne SMT über die 200 Watt hinaus gehen.
Die 5,7 ghz werden sich ganz bestimmt auf die Single core Takt beziehen oder halt auf 2 Kerne und so.Allcore steht ja was mit 5,1 ghz ,also ist diese System fast an sein Limit gekommen.Da hilft dann nur noch noch mehr Takt,ansonsten wird das wohl nix.Also kan man nur noch mit noch mehr Takt das Limit erweitern.
Vielleicht ist das ja bei den Threadripper der Fall,weil die brauchen ja die doppelte Bandbreite als ein Ryzen 16 Kerner.So das die zwar eigentlich mehr Leistung gehabt hätte aber durch zu wenig Bandbreite eben SMT es ausgebremst hatten.Zwar die neuesten nicht mehr aber ich weis das SMT abschalten für Leistung gebracht hatte.
Laut AMD ist die TDP 170W. Aber keine Ahnung, mach einen Cinebench oder so mit und ohne SMT, schau, wie die Leistungsaufnahme ist und was am Ende dabei rauskommt.
Ja, wenn du an deine eingestellte TDP nicht rankommst, kannst du vermutlich die Turbostufen für mehr Kerne unter Last noch anheben.
Nein, das kann eigentlich nicht sein. Es wird ja nicht mehr Bandbreite pro Leistung verbraucht, eher sogar etwas weniger, weil man Kontextwechsel spart. Das wird eher ein Schedulerproblem gewesen sein.
Ähnliche Themen
