Gesteigerte Singlethread-Leistung durch Multi-Threading

[Gast]

http://www.xbitlabs.com/news/cpu/display/20100519235548_Intel_Outlines_New_Tech_to_Boost_Performance_of_Single_Threaded_S oftware_on_Multi_Core_Chips.html

http://portal.acm.org/citation.cfm?id=1555754.1555813&coll=ACM&dl=ACM&type=series&idx=SERIES416&part=series&WantType=Proceedings&title=ISCA&CFID=89838298&CFTOKEN=40410271

Wobei ein Speed-up von 40% bis 160% bei wohl 48 Kernen schon zeigt, dass es bei aktuellen Multi-Core-CPUs nicht soviel bringen würde.

[Pinoccio]

"The proposed technique features a set of novel hardware mechanisms that support the execution of threads generated at compile time. These threads result from a fine-grain speculative decomposition of the original application and they are executed under a modified multi-core system"
Hart-nichtparellelisierbare Sachen werden sich damit vermutlich auch nicht beschleuinigen lassen und ob der Trade-off bei 48 Kernen vs 160% schneller sinnvoll ist, wage ich auch zu bezweifeln.
Aber interessant ist das natürlich schon.

mfg

[mapel110]

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8013592#post8013592
Wurde auch schon ab hier diskutiert.

[Spasstiger]

Hart-nichtparellelisierbare Sachen werden sich damit vermutlich auch nicht beschleuinigen lassen und ob der Trade-off bei 48 Kernen vs 160% schneller sinnvoll ist, wage ich auch zu bezweifeln.
Aber interessant ist das natürlich schon.
Kommt halt drauf an, wie groß diese 48 "tiny cores" sind. Wenn sie nicht mehr Transistoren verbraten als die vier Kerne eines Core i7, kann das schon Sinn machen.
Vor allem, wenn dieser Speedup generell vorhanden ist, weil die spekulative Zerlegung logischerweise auch mit den Einzelthreads von Multithreading-Software funktionieren müsste.

[BlackBirdSR]

Und dann muss man sich fragen, ob diese Techniken bei einem komlexen Kern wir den großen x86 überhaupt spürbar etwas bringt.
Denn was habe ich von 46% höherer Single-Thread-Leistung, wenn diese von Beginn an sehr niedrig ist?

[moloch]

Das soll ja auch nur eine Krücke für alte Programme sein oder Programmierer die unfähig sind mehrere Kerne zu nutzen.

[Spasstiger]

Der Fokus liegt denke ich eher darin, wie man einen Prozessor mit sehr vielen Kernen ausgelastet bekommt und nicht darin, wie man einen faulen Programmierer entlasten kann. ;)

[Gast_samm]

The proposed technique features a set of novel hardware mechanisms that support the execution of threads generated at compile time. These threads result from a fine-grain speculative decomposition of the original application and they are executed under a modified multi-core systemKann mir mal jemand zu den von mir fett gemachten Stellen bisschen was erklären: Programme müssen also neu kompiliert werden, damit diese Threads erstellt werden können? Oder anders betrachtet: Der erste Satz klingt eigentlich extrem banal, da jede CPU Threads ausführen kann - und dass Threads während des Kompilierens generiert werden, sprich bei der Umsetzung von Text in Maschinencode erst in das Programm gelangen wie überhaupt alles andere auch, grenzt ja an eine Tautologie.
Zudem, was heisst "modified"?

[Gast]

Kann mir mal jemand zu den von mir fett gemachten Stellen bisschen was erklären: Programme müssen also neu kompiliert werden, damit diese Threads erstellt werden können? Oder anders betrachtet: Der erste Satz klingt eigentlich extrem banal, da jede CPU Threads ausführen kann - und dass Threads während des Kompilierens generiert werden, sprich bei der Umsetzung von Text in Maschinencode erst in das Programm gelangen wie überhaupt alles andere auch, grenzt ja an eine Tautologie.
Zudem, was heisst "modified"?

Naja ich denke mal dass die Threads entweder beim Kompilieren oder durch eine Laufzeitumgebung wie .NET erzeugt werden können.
Ich kann mir nicht vorstellen, dass Das die CPU irgendwie "Selbständig" durchführen kann.
Mit modified ist wohl gemeint, dass man dazu spezielle Hardware benötigt, Was ja auch klar im Intresse von Intel sein sollte.

[Gast]

Der Fokus liegt denke ich eher darin, wie man einen Prozessor mit sehr vielen Kernen ausgelastet bekommt und nicht darin, wie man einen faulen Programmierer entlasten kann. ;)

Fauler Programmierer == fehlerfreiere und günstigere Programme(Normale Menschen nennen das geringeren Entwicklungsaufwand durch bessere Tools);)

[Tiamat]

Man könnte damit einen schlankeren und 46% langsameren Core verbauen und hätte bei Single-Threading Apps die gleiche Performance wie ein 46% schnellerer Core. Das ist doch für den Anfang gar nicht mal schlecht ;)

[mrt]

Das ist auch für simple Kerne gedacht, der Speed-Up dürfte bei komplexen Kernen wohl geringer sein.

[davidzo]

Naja ich denke mal dass die Threads entweder beim Kompilieren oder durch eine Laufzeitumgebung wie .NET erzeugt werden können.
Ich kann mir nicht vorstellen, dass Das die CPU irgendwie "Selbständig" durchführen kann.
Mit modified ist wohl gemeint, dass man dazu spezielle Hardware benötigt, Was ja auch klar im Intresse von Intel sein sollte.

Ich sehe die Zukunft sowieso in Laufzeitumgebungen wie Java (.NET ist lahm und Plattform abhängig, daher imo völlig überflüssig). Damit kann man unabhängig von OS, Hardware, etc. Prozessorthreads generieren, die für das jeweilige system passen. Optimaler prekompilierter code mag derzeit noch schneller sein, aber bei zunehmender Diversifikation der Plattformen nimmt der Vorteil von on-the-fly Lösungen zu.

hat man z.B. binary-code mit zwei threads auf einem system das vier threads unterstützt liegt der vorteil von on-the-fly code doch schon auf der hand. auch bei einem singlethreaded system würde wahrscheinlich die on-the-fly methode gegenüber einem 4-thread binary soviel an overhead sparen das es sich lohnt.

Heute müsste man im optimalen Fall für eine Software schon fünf binaries erstellen, für single-, dual-, triple-, hexa- und quadcores. Das ist doch der horror für jeden coder, code-redundanz in welcher weise auch immer ist unbedingt zu vermeiden, weil es zu Inkonsistenzen führt. Inkonsistenzen führen häufig zu unerwarteten bugs und machen das debugging zu einer großen qual.