News SMT-Nachfolger entwickelt? SHMT mit doppelter Leistung und geringerem Stromverbrauch

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu SMT-Nachfolger entwickelt? SHMT mit doppelter Leistung und geringerem Stromverbrauch

Simultanes Multithreading könnte bald einen Nachfolger erhalten: Mit SHMT wollen Forscher mehrere Komponenten nutzen, um eine noch effektivere Verteilung der Arbeitslast zu erreichen.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: SMT-Nachfolger entwickelt? SHMT mit doppelter Leistung und geringerem Stromverbrauch

 

[Rollora]

auch interessant, schauen wir mal was in 10 Jahren draus wird, ich warte immer noch auf Ergebnisse zum inversen Multithreading

 

[DieLutteR]

Uiuiui, spannend. Da ich beruflich mit Performance & Kapazitätsmessungen in Serverbereich zu tun habe klingt das nach interessanten Ansätzen für meine zukünftige Arbeit. Davon abgesehen läuft das ganze erst einmal mit ARM. Spannend auch, ob IBM für seine POWER CPU so etwas entwickelt. KI Support in der CPU Firmware ist da ja schon integriert...

 

[empy]

Ich finde muss hier mal ganz klar deutlich machen, dass das mit SMT, wie man es kennt, nur sehr grob vergleichbar ist. Das ist kein einfaches CPU-Feature, sondern läuft wohl am ehesten auf eine Art Schnittstelle raus, die dann jede Art von Koprozessor unterstützen muss. So wie ich es verstehe, ist die CPU selbst weiterhin immer der Ursprung aller Aufrufe und auch nicht selbst davon betroffen, sondern macht ganz normal ihr Ding. Aber wenn Aufrufe an andere Einheiten gemacht werden, werden die nicht mehr an eine bestimmte, sondern alle Einheiten weitergeleitet, die sie verarbeiten können. Das heißt beispielsweise, dass die NPU bei GPU-Aufgaben mithilft und umgekehrt.

Auf jeden Fall spannend, aber auch mit einigen Fallstricken behaftet. Wenn z.B. die NPU deutlich schwächer als die GPU ist, muss das auch in der Verteilung der Last berücksichtigt werden, sonst bremst die NPU die GPU aus. Außerdem muss dafür gesorgt werden, dass "fremde" Aufgaben die jeweiligen Koprozessoren nicht von ihrer eigenen Arbeit abhalten. In beiden Fällen ist die Frage, wie groß die Brocken sind, die verteilt werden. Wenn Arbeit häppchenweise verteilt werden kann, ist es nicht so schlimm, weil man immer beim Verteilvorgang prüfen könnte, welche Aufgaben verteilt werden müssen und dann entsprechend priorisieren kann. Andererseits steigt der relative Overhead durch diese Priorisierung mit kleineren Arbeitspaketen auch, aber das muss nicht zwangsweise ein Problem sein.

 

[hrIntelNvidia]

Ohje, hoffentlich wird das nicht auch ein Einfallstor wie es gerade SMT bzw. auch die SMT nahen Technologien sind.

 

[bitsbytes]

Frage mich, wie sich das auf DPC Latenzen auswirkt, die für zeitkritische Anwendungen (Audio, Video) möglichst gering sein müssen.

Schon jetzt wird bei Intel Big/Little (Power/Efficiency Cores) über Probleme im Recording Bereich berichtet, dass "Audio Related" Prozesse falsch auf die langsamen E-Cores verteilt werden, anstatt mit höchster Performance und damit auch geringster DPC Latenz abgearbeitet zu werden. Was letzten Endes zu Schwierigkeiten (Audio Aussetzern) führt.

Auch beim Gamen gab es doch mal Probleme mit Mikrorucklern und auch Gaming partizipiert von einem effizient arbeitenden System mit geringen DPCs...

Da bin ich mal gespannt ... Alles wird oftmals leider nur komplexer und damit meistens auch schlechter,
weil die Leute in vielen Bereichen nur noch "rumflickschustern", als gäbe es kein Morgen mehr,
anstatt auszuprobieren, ob das auch wirklich alle Probleme löst und nicht neue Probleme erzeugt.

 

[Olstyle]

Ohje, hoffentlich wird das nicht auch ein Einfallstor wie es gerade SMT bzw. auch die SMT nahen Technologien sind.

Ich würde tatsächlich sagen das ist ein riesiges Einfallstor. Denn alle Recheneinheiten müssen auf alle Daten zugreifen können. Gibt es also eine Lücke die die GPU betrifft kann man damit auch Dinge auslesen die normalerweise auf die CPU beschränkt waren.

 

[George-Broussard]

Ich würde tatsächlich sagen das ist ein riesiges Einfallstor. Denn alle Recheneinheiten müssen auf alle Daten zugreifen können. Gibt es also eine Lücke die die GPU betrifft kann man damit auch Dinge auslesen die normalerweise auf die CPU beschränkt waren.

Genau das habe ich mir auch gedacht. Als hätten die aktuellen Technologien nicht schon genug mit Sicherheitsproblemenen zu kämpfen.

Die Nutzer scheint es hingegen überhaupt nicht zu stören dass all Ihre Geräte so dicht sind wie eine Abtropfschüssel die man rundherum mit Tesa Film beklebt hat.

 

[empy]

Ich würde tatsächlich sagen das ist ein riesiges Einfallstor. Denn alle Recheneinheiten müssen auf alle Daten zugreifen können. Gibt es also eine Lücke die die GPU betrifft kann man damit auch Dinge auslesen die normalerweise auf die CPU beschränkt waren.

Ich weiß nicht, ob das dadurch jetzt schlimmer wird als bisher. Die CPU delegiert ja scheinbar weiterhin als einzige Einheit und sollte somit auch bestimmen, welche Speicherbereiche von wem genutzt werden dürfen. Also nicht weniger, aber auch nicht mehr Lücken. Aber das wirft ein ganz anderes Problem auf: Wie wird mit Speicher umgegangen, der physisch verteilt ist? Das ist alles schön und gut, wenn es um ein SoC geht und alles an einen einzelnen Speicher angebunden ist, aber wenn der Speicher geteilt ist und bestimmte Bereiche nur per PCIe erreicht werden können, steigt der Kommunikationsaufwand gleich deutlich.

Auf der einen Seite ist die Motivation verständlich, den ganzen Chip zu nutzen, wenn jetzt immer mehr verschiedene Einheiten signifikante Mengen an Platz darauf einnehmen. Auf der anderen Seite muss man sich fragen, ob diese Aufteilung überhaupt passiert wäre, wenn das alles mit derselben Logik auf einem ähnlichen Niveau erledigen könnte, wie angeblich bewiesen wurde und wenn dem so wäre, ob man dann nicht lieber wieder zurückrudert und das vereinheitlicht. Vielleicht wäre dieser Schritt zurück sogar eher ein Schritt vorwärts wie damals die Unified Shader und vielleicht kommt er SHMT sogar sowieso zuvor.

 

[latiose88]

hm als ich das gelesen hatte ,dachte ich geil,ne ordentliche Leistungssteigerung.Als ich dann Softwarebasierend gelesen hatte,war die Freude wieder Weg gewesen.Ich will die alte Version meines Programms weiter nutzen.Hoffte damit mit dieser Technik noch schneller damit agieren zu können,aber das wird nie passieren.Finde ich echt schade,aber kann man nix machen.

 

[BigBoymann]

Ich würde tatsächlich sagen das ist ein riesiges Einfallstor. Denn alle Recheneinheiten müssen auf alle Daten zugreifen können. Gibt es also eine Lücke die die GPU betrifft kann man damit auch Dinge auslesen die normalerweise auf die CPU beschränkt waren.

Ist das so?

So wie ich es verstehe, wird das ganze doch als Softwarelösung implementiert und eben diese verteilt dann an die einzelnen Threads, also gänzlich anders als heutiges SMT, was in Hardware gegossen ist. Daher sollte das Thema Sicherheitslücken beherrschbar bleiben, so zumindest mein Verständnis.

Die Nutzer scheint es hingegen überhaupt nicht zu stören dass all Ihre Geräte so dicht sind wie eine Abtropfschüssel die man rundherum mit Tesa Film beklebt hat.

Ohne den Aluhut aufzuhaben, aber die Nutzer kaufen Geräte die quasi als offizielle Abhörzentrale verkauft werden und stellen sich die Dinger wirklich überall hin. Videocameras die sicherheitshalber alles aufzeichnen was sich bewegt und gleich in die Cloud streamen, usw. Also ich glaube, jedem der sich nicht bis ins unendliche mit dem Thema beschäftigt ist auf so vielen Ebenen angreifbar, dass der zumeist physische Zugriff auf den PC da noch das kleinste Problem ist (ich meine zumindest, dass die allermeisten Sicherheitslücken eben diesen physischen Zugriff brauchten).

aber wenn der Speicher geteilt ist und bestimmte Bereiche nur per PCIe erreicht werden können, steigt der Kommunikationsaufwand gleich deutlich.

Ist doch heute auch schon so! Nicht ganz umsonst sind in den letzten Jahren immer und immer wieder die verschiedenen Cachestufen deutlich aufgebohrt worden. Ich meine wir reden im Server aktuell von bis zu 1GB L3 Cache, wo vor 10 Jahren mit viel Glück mal 30MB standen. Geht es aus dem Cache raus kommt der RAM und selbst der ist ja verhältnismäßig langsam, wenn es dann in Richtung Auslagerungsdatei geht, oh wei.

Sehe das Problem aber nicht in Bezug auf SMHT, bzw. nicht exklusiv dort.

 

[roboblut]

So ange man jede verschlüsselung mit Cold Boot-Angriff, ausshebel kann ist das, dass kleinste Problem.

 

[ΔΣΛ]

Zudem ist SMHT keine hardwarebasierte Lösung. Stattdessen liege es an Softwareentwicklern, entsprechende Algorithmen so zu überarbeiten, dass die parallele Belastung mehrerer Komponenten überhaupt durchgeführt werden kann.

Ach so, jetzt bin ich leicht enttäuscht, dann wird es noch zehn Jahre dauern bis es sich halbwegs durchsetzt.

 

[aluis]

SMT ist heutzutage ein gängiges Feature in Prozessoren, ganz gleich, ob diese von AMD oder Intel stammen.

Das ist so nicht richtig. AMD nennt es SMT, Intel HT.
Warum AMD jetzt auf ein SMT 2.0 setzt, während Gerüchte sagen Intel schafft HT ab, bleibt spannend.

 

[Hagal]

Wäre mal von Vorteil wenn Utils (RAR/Zip und x265 ausgenommen) und Game Engines (Unreal Engine v5.3 ausgenommen) auch mal mehr Kerne nutzen würden

 

[empy]

Sehe das Problem aber nicht in Bezug auf SMHT, bzw. nicht exklusiv dort.

Das Problem ist, dass dann gegebenenfalls sehr viel über eine recht enge Verbindung kommuniziert werden muss. Wenn jetzt zum Beispiel eine NPU, die in der CPU sitzt, eine dGPU unterstützen soll, könnte der Haupteffekt sein, dass die PCIe-Verbindung zwischen CPU und dGPU blockiert ist und wenn die dGPU der NPU helfen soll, wird die nur einen Bruchteil ihrer Leistung bringen können, weil sie mit der im Vergleich zum VRAM winzigen Bandbreite auskommen muss. Da wäre es dann vielleicht deutlich besser, das ganze direkt auf der GPU-Seite zu erledigen und nur Ergebnisse zu übertragen.

Das ist so nicht richtig. AMD nennt es SMT, Intel HT.
Warum AMD jetzt auf ein SMT 2.0 setzt, während Gerüchte sagen Intel schafft HT ab, bleibt spannend.

Doch, ist es. SMT ist der allgemeine Begriff, HT die Marketingbezeichnung von Intel. Das SHMT hier hat folglich auch nichts mit AMD zu tun.

 

[SophiaGlencairn]

Warum muss ich da spontan an Mojo🔥 denken. 😅

 

[Jeretxxo]

Klingt nach nem Albtraum, dafür zu optimieren, aber vielleicht bei recht einfachen und parallelisierten Tasks, könnt ich mir vorstellen, das dass Sinn macht in einer recht homogenen Umgebung.

 

[gerX7a]

Wenn man den Artikel schon nicht als ClickBait bezeichnen will, denn der ist immerhin nur ein reines Forschungsapapier und noch weit von praktischer Umsetzung entfernt, insbesonder bzgl. für diese Klientel hier relevante Software, dann ist es der Titel zumindest gesichert.
Mit SMT hat das hier wenig zu tun, aber SMT ist zumindest ein Begriff den diese Klientel hier kennt und so kann man auf Klicks hoffen.
Das Papier erwähnt (conventional homogenous) simultaneous multithreading übrigens nur an einer einzigen Stelle über insg. 12 Seiten (exklusive des Anhangs mit den Referenzen) und nur als kurze Randbemerkung.

In vereinfachter Weise ist das hier beschrieben ein mehrschichtiger SW-Stack, der unterschiedliche Hardwareeinheiten besser und verschachtelt nutzen und damit die Hardware insgesamt optimaler ausnutzen können soll. Konkret werden hier hardwareunabhängige Operationen definiert, damit man auf dem System mit einem universellen Befehlssatz programmieren kann, eine Laufzeitumgebung übernimmt das Scheduling und steuert die heterogene Hardware an und zusätzlich gibt es eine weitere Laufzeitkomponente, die die qualitätstechnischen Maßstäbe bzgl. der Berechnungen sicherstellt, da die unterschiedlichen Hardwareeinheiten über unterschiedliche Ausführungseinheiten, Register und Genauigkeiten verfügen.
Sehr allgemein gesproche kann man das Konstrukt ganz grob mit etwas wie einer Java Virtual Machine vergleichen, jedoch mit dem herausstechenden Unterschied, dass die JVM jeweils für eine spezifische Hardware individuell kompiliert wird und dann nur auf dieser spezifischen Hardware ihren Code ausführen kann.

In diesem Kontext hier wesentlich relevanter und näher an einer konkreten Implementation sind Begriffe wie x64-only, AVX10.1 und 10.2 sowie Rentable Units und eher letzteres wird wohl anscheinend das sein, was bei Intel in den nächsten 2 oder 3 Jahren SMT (bei Intel HT geannant) beerben *) wird und eher auf genau das Gegenteil hinausläuft, nämlich noch mehr ST-Performance pro Kern(cluster), indem geteilte Ausführungseinheiten eines Kerncluster zu einem einzigen , durchsatzstärkeren Kern zusammengeschaltet werden können.

*) Ob das "Beerben" zukünftig einen kompletten Entfall von SMT bedeutet und man den Bedarf nach mehr Threads schlicht mit vielen kleinen, vollständigen Kernen abbildet oder ob es ggf. weiterhin einige ausgewählte Designs mit HT/SMT-Funktionalität geben wird, ist noch unklar. Sieht man sich die Entwicklungsmöglichkeiten moderner Technologien an, könnten viele kleine Kerne aber möglicherweise den erfolgreicheren Weg darstellen.

 

[takan]

Klingt nach nem Albtraum, dafür zu optimieren, aber vielleicht bei recht einfachen und parallelisierten Tasks, könnt ich mir vorstellen, das dass Sinn macht in einer recht homogenen Umgebung.

kommt aufn workload an. und machen games. logik auf der cpu und grafik auf der gpu.

"optmieren" tut das nen compiler, zumindest sollte der das...