Intel-Patent: Virtuelle Super-Kerne für höhere Singlethreading-Leistung

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.548
Das Konzept ist nicht neu und wurde in der Vergangenheit für einzelne Funktionseinheiten immer wieder verwendet: Die Rede ist von konfigurierbaren CPU-Kernen, die sich gewisse Ressourcen teilen, um so in bestimmten Anwendungen eine höhere Rechenleistung zu erreichen. Intel hat vor einigen Wochen in gleich mehreren Ländern ein Patent "Software-defined Super Cores" (SDC) eingereicht. In den USA läuft dies unter der Patentanmeldung US20250217157A1.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
In der Theorie funktionieren solche Patente super, schauen wir mal, ob die das auch in der Zukunft,

in die Praxis umsetzen können. Meisten sollen solche Patente eine Firma vor möglichen Klagen der Wettbewerber schützen,

weil man ähnliche Konzepte nutzt, wie die anderen Entwickler auf diesem Gebiet.
 
Intel nimmt Anleihen bei der "Bulldozer"-Archtitektur? Und der Code für den Thread muss auch noch entsprechend präpariert sein? "vielversprechend" würde ich was anderes nennen.
Dazu kommt: nicht alle Dinge lassen sich parallelisieren.

Aber ich lass mich gerne positiv überraschen.
 
Gespannt welche Software das dann definieren soll. Ich hoffe nicht der OS Kernel und nicht die Anwendung. Es gibt schon genug Chaos im Scheduler durch P+E.

Man kann den Klamauk aber wie sonst auch, immer weiter ignorieren...
 
Intel nimmt Anleihen bei der "Bulldozer"-Archtitektur? Und der Code für den Thread muss auch noch entsprechend präpariert sein? "vielversprechend" würde ich was anderes nennen.
Dazu kommt: nicht alle Dinge lassen sich parallelisieren.

Aber ich lass mich gerne positiv überraschen.
Ich hab das so verstanden das eben nicht parallelisiert wird. Sondern mehrere Kerne als eine Einheit fungieren. Zwischen den Kernen gibt es ne Brücke die dafür sorgt das die Instruction zu den Nachbarn rüber rutschen können.

So wie wenn man sagt, das Glas ist voll und der Überschuss fließt in ein neues Glas ab. Das ist ja nicht parallel sondern weiterhin seriell.

Aber man darf Intel es daran bemessen, wenn es draußen ist und funktioniert. Wir dürfen gespannt sein.
 

Jim keller hatte soetwas bei intel ja in der arbeit.
 
Intel versucht erst viel mit Software.
Erst APO+ und jetzt Bulldozer Software
 
So wie wenn man sagt, das Glas ist voll und der Überschuss fließt in ein neues Glas ab. Das ist ja nicht parallel sondern weiterhin seriell.
Wenn man den Vergleich weiterverfolgt, wäre die Rechenleistung hier wie schnell die Gläser voll werden.
Wenn du mehrere Gläser hast, aber nur eine Wasserquelle hast, musst du die natürlich sequentiell füllen. Dabei ist es egal ob du zwei 0,5l Gläser füllen willst, oder ob diese zwei Gläser zu einem virtuellem 1L-Glas zusammenfügst. Es wird dadurch nichts schneller.

Wenn da irgendwas schneller machen willst, brauchst du entweder eine Wasserquelle mit mehr Durchsatz, oder mehrere Wasserquellen die dann parallel befüllen können.

Und auch bei dieser Lösung wird parallelisert. Das steht ganz klar in der Meldung:
Spezielle Instruktionen - sogenannte "Flow Control Instructions" – werden dazu in eine Single-Threaded-Anwendung geschrieben, damit der Scheduler weiß, welche Abschnitte er parallelisieren kann.
Heisst, damit das überhaupt funktioniert, muss der Code schon entsprechend geschrieben werden und weil am Ende doch wieder parallelisiert wird, ist die Frage wie stark sich das auswirken kann/wird.

a + b + c + d kann man parallelisieren, tut aber keiner, weils viel zu aufwändig ist und für diese kleine Aufgabe der Multithreadingoverhead mehr Zeit kostet als man gewinnt. Wenn das mit der Intellösung aber einfach und ohne große Verluste geht kann das was bringen... aber wohl nur ein kleines bisschen.

Ist quasi Hyperthreading rückwärts. Was beim P4 noch halbwegs Sinn gemacht hat, weil man dadurch die Pipelines besser auslasten konnte, wenn man denn mehrere Threads hat. Mittlerweile bringt Hyperthreading nur noch sehr wenig. Mehr erwarte ich von dieser Lösung auch nicht: In ganz speziellen Situationen mit darauf zugeschnittenem Code kann man vielleicht ein bisschen was rausholen.

Von dem Gedanken das da "einfach" mal zwei Kerne zusammengefasst werden und dadurch ein einzelner Thread doppelt so schnell wird, kann man sich denke ich gleich verabschieden.
 
a + b + c + d kann man parallelisieren, tut aber keiner, weils viel zu aufwändig ist und für diese kleine Aufgabe der Multithreadingoverhead mehr Zeit kostet als man gewinnt. Wenn das mit der Intellösung aber einfach und ohne große Verluste geht kann das was bringen... aber wohl nur ein kleines bisschen.

Ist quasi Hyperthreading rückwärts. Was beim P4 noch halbwegs Sinn gemacht hat, weil man dadurch die Pipelines besser auslasten konnte, wenn man denn mehrere Threads hat. Mittlerweile bringt Hyperthreading nur noch sehr wenig. Mehr erwarte ich von dieser Lösung auch nicht: In ganz speziellen Situationen mit darauf zugeschnittenem Code kann man vielleicht ein bisschen was rausholen.

Von dem Gedanken das da "einfach" mal zwei Kerne zusammengefasst werden und dadurch ein einzelner Thread doppelt so schnell wird, kann man sich denke ich gleich verabschieden.
Ich denke der Hauptgedanke ist damit Legacy Software die teuer wäre komplett neu zu schreiben damit diese etwas mehr bumps erhält und weiter verwendet werden kann.
Aber halt erstaunlich wie gut man es als Monopolist hat, anstelle das man sich selbst der Welt anpasst verändert sich die Welt um einem herum das es wieder passt.

Die Entwicklung ist allgemein recht schändlich. Das ist wie typische Software die nur für Windows geschrieben ist. Da gibt es halt echt Leute und Firmen die sehen den Eisberg und rasen voll darauf zu.
Das Argument ist wir können ja nichts dafür das der Eisberg jetzt da ist und rasen weiter drauf zu bis es knallt.
 
Ich denke der Hauptgedanke ist damit Legacy Software die teuer wäre komplett neu zu schreiben damit diese etwas mehr bumps erhält und weiter verwendet werden kann.
Genau das wird eben nicht funktionieren, weil wie schon in der Meldung steht: Der Code müsste Flow Control Instructions beinhalten. Das hat Legacysoftware aber garantiert nicht.

Die Entwicklung ist allgemein recht schändlich. Das ist wie typische Software die nur für Windows geschrieben ist.
Da verstehe ich jetzt den Zusammenhang ehrlich gesagt nicht.
Eine Entwicklung die ich schädlich finde ist, wenn man Optimierungen für Spiele in den Grafiktreiber packt. :ROFLMAO:
 
Genau das wird eben nicht funktionieren, weil wie schon in der Meldung steht: Der Code müsste Flow Control Instructions beinhalten. Das hat Legacysoftware aber garantiert nicht.


Da verstehe ich jetzt den Zusammenhang ehrlich gesagt nicht.
Eine Entwicklung die ich schädlich finde ist, wenn man Optimierungen für Spiele in den Grafiktreiber packt. :ROFLMAO:
Ich denke das die Flow Control Instruction leichter einzufügen sind wie das Programm komplett neu zu schreiben.
Wie bei Games, anstelle groß nachträglich zu optimieren einfach FSR einfügen und per Default immer mit laden schon verbessert sich die Performance auf magische Weise, aber ohne das Problem zu lösen.

Der Zusammenhang ist, das sehr viel Software für Windows geschrieben wurde und obwohl die Praktiken seitens MS die letzten Jahre zu bedenken gibt, denken die wenigsten Softwarefirmen daran ihre Server Software auf Linux umziehen.
Das wird mit dem Flow Control Instruction ähnlich ablaufen, anstelle das Problem an der Wurzel anzugehen wird man schauen das man billig den alten Gaul noch weiter reitet.
 
Ich denke das die Flow Control Instruction leichter einzufügen sind wie das Programm komplett neu zu schreiben.
Wie bei Games, anstelle groß nachträglich zu optimieren einfach FSR einfügen und per Default immer mit laden schon verbessert sich die Performance auf magische Weise, aber ohne das Problem zu lösen.
Du hast nicht viel Ahnung von Softwareentwicklung oder?
Die Flow Control Instructions musst du in den Code einfügen, im günstigsten Fall erkennt der Compiler selber stellen wo welche (sinnvoll) eingefügt werden könnten. Du musst also mindestens neu kompilieren, oder sogar Sourcecode anpassen/erweitern. Beides will bei Legacysoftware wirklich niemand mehr machen.
Das ist nichtmal ansatzweise damit vergleichbar wie man FSR einbindet. Das ist ein externes Modul das man nur mit Daten füttern muss.

Der Zusammenhang ist, das sehr viel Software für Windows geschrieben wurde und obwohl die Praktiken seitens MS die letzten Jahre zu bedenken gibt, denken die wenigsten Softwarefirmen daran ihre Server Software auf Linux umziehen.
Hat absolut nichts mit dem Thema hier zu tun. Und hier würde ich die Steigerung von "nichts" schreiben, wenn es denn eine gäbe. Schwarzes Loch vielleicht? :d

Das wird mit dem Flow Control Instruction ähnlich ablaufen, anstelle das Problem an der Wurzel anzugehen wird man schauen das man billig den alten Gaul noch weiter reitet.
Im Endeffekt wird sich das denke ich verhalten wie ältere "CPU-Erweiterungen" auch schon, z.B. MMX, SSE, AVX usw. Du vermischt hier nicht Äpfel mit Birnen sondern Raumfahrt mit Untertagebau.
 
Du hast nicht viel Ahnung von Softwareentwicklung oder?
Die Flow Control Instructions musst du in den Code einfügen, im günstigsten Fall erkennt der Compiler selber stellen wo welche (sinnvoll) eingefügt werden könnten. Du musst also mindestens neu kompilieren, oder sogar Sourcecode anpassen/erweitern. Beides will bei Legacysoftware wirklich niemand mehr machen.
Das ist nichtmal ansatzweise damit vergleichbar wie man FSR einbindet. Das ist ein externes Modul das man nur mit Daten füttern muss.
Also is das mega aufwendig und bringt vielleicht nichts. Also ein Papiertiger.
 
Für bestehende Anwendungen ist das jedenfalls nichts was nachträglich einfach anflanschbar ist.

Aber warum soll es deswegen gleich ein Papiertiger sein? War MMX in Papiertiger, nur weil alte Software bei dessen Einführung keinen rückwirkenden Nutzen daraus hatte?

Es haben sich jetzt schon seit über 10 Jahren Mehrkern-CPUs etabliert und auch gut was gebracht. Damit das aber was nutzt muss man Software parallelisieren. Je nach dem was man berechnet ist das nicht ganz einfach und selbst wenn mans tut kostet das Overhead.

Das Intel mit der Technik Singlecoreleistung steigern will ist denke ich falsch ausgedrückt. Soweit ich das hier verstehe, soll durch diese Technik Code der Singlethreaded geschrieben ist mit einfachen Mitteln in Teilen trotzdem parallel ausgeführt werden können. Man steigert also eigentlich nicht die Singlecoreleistung, sondern man vereinfacht Multithreading soweit, das es einfach gemacht werden kann und auch für "Kleinigkeiten" ohne großartigen Overhead angewandt werden kann.

Ich mach mal ein Beispiel.
Originalcode, Singlethreaded:
Code:
a = b + c
d = a + e
f = g + h
i = j * k
l = f - i
Da kann man Teile davon parallelisieren. Lohnt sich aber nicht. Sowohl der Programmieraufwand als auch der Ausführungsaufwand ist zu hoch. Du müsstest die Ergebnisse zwischen Kernen hin und herkopieren, etc.
Die Inteltechnik soll aber auch den Ausführungsaufwand reduzieren, z.B. indem die beiden Kerne shared Register haben, auf die sie beide zugreifen können. Wenn man jetzt noch mit diesen FlowInstructions einfach ganze Bereiche als "das kann alles parallelisiert werden" markieren kann, würde daraus z.B. werden:
Code:
#instruction_flow_no_dependency_start
a = b + c
f = g + h
i = j * k
#instruction_flow_no_dependency_end

#instruction_flow_no_dependency_start
d = a + e
l = f - i
#instruction_flow_no_dependency_end
Damit hat der Entwickler dem Compiler (oder Interpreter) mitgeteilt, das die ersten 3 Rechnungen und die letzten 2 keine Abhängigkeiten haben und jeweils parallel berechnet werden können. Und mit der Intelerweiterung wird das dann auch einfach parallel ausgeführt, der Entwickler muss sich aber nicht weiter darum kümmern und es ist trotzdem schneller.

Das Beispiel sollte auch zeign, das es trotzdem nicht reicht einfach ein paar FlowInstructions irgendwo hinzuschreiben. Man muss schon die Logik durchgehen, ggf. Reihenfolgen ändern und dann eben noch die Instructions dazuschreiben. Ja das ist einfacher als ein Programm komplett neu zu schreiben, aber da muss man schon argen Bedarf haben um selbst diesen Aufwand zu treiben, nur damit es am Ende vielleicht 10% schneller wird.
 
Für bestehende Anwendungen ist das jedenfalls nichts was nachträglich einfach anflanschbar ist.

Aber warum soll es deswegen gleich ein Papiertiger sein? War MMX in Papiertiger, nur weil alte Software bei dessen Einführung keinen rückwirkenden Nutzen daraus hatte?
Weil die Zeiten nun gedreht sind. Heute ist das nicht sowas wie MMX, sondern wie 3dnow...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh