APUs überall. Compiler?

[Avalox]

APUs sind nun an jeder Ecke präsent.

Ob es alsbald entsprechende direkte Komponenten Bibliotheken und Compiler Einstellungen, für die gebräuchlichen CPU Programm Compiler geben wird.
Vorbei an der Abstraktion OpenCL oder DirectCompute?

[Brillus]

Damit das so vernünftig geht müsste man schon fast, die Befehlssätze der APUs standartisieren. Ich weiß jedoch auch gut informierter Quelle das dran gearbeitet wird C++ -> OpenCL zu compilieren.

[Ganon]

Ich finde die "abstrakte" "Fütterung" der GPU eigentlich ganz vorteilhaft. So kann der Treiber für jede GPU selbst entscheiden, wie ihm die Befehle besser schmecken, als wenn das ganze schon in den Maschinencode festgenagelt wird. Eine Anwendung die vor 6 Jahren compiliert wurde, wird wohl kein SSE4 nutzen (als Beispiel). Eine die zur Laufzeit kompiliert wird, kann dies durchaus.

[Brillus]

Ich finde die "abstrakte" "Fütterung" der GPU eigentlich ganz vorteilhaft. So kann der Treiber für jede GPU selbst entscheiden, wie ihm die Befehle besser schmecken, als wenn das ganze schon in den Maschinencode festgenagelt wird. Eine Anwendung die vor 6 Jahren compiliert wurde, wird wohl kein SSE4 nutzen (als Beispiel). Eine die zur Laufzeit kompiliert wird, kann dies durchaus.
Sehe ich auhc so mir fallen nur Nachteile ein.

Standartisierte Instructions: die Instructions müssen stabel bleiben was aktuell ehr nicht so gerne gemahct wird sieh VLIW5->VLIW4. Die unterschiedlichen Herstller müssen einen gemeinsamen Nenner habe.

Keine Optimierung an die aktuell ausführende APU.

[Trap]

Ob es alsbald entsprechende direkte Komponenten Bibliotheken und Compiler Einstellungen, für die gebräuchlichen CPU Programm Compiler geben wird.
Vorbei an der Abstraktion OpenCL oder DirectCompute?
Ja, es gibt schon Bibliotheken, die einem das OpenCL/DirectCompute Code schreiben abnehmen, z.B.: http://developer.amd.com/zones/java/aparapi/Pages/default.aspx

Vorbei an der Abstraktion wird es hoffentlich nicht mehr geben.

[Nighthawk13]

Bisher spielen die APUs ihren Vorteil der direkten Kopplung kaum aus, da konzeptionell in OpenCL/DirecteCompute/Cuda immer noch von getrennter CPU+Graka ausgegangen wird.

Es fehlt noch das Konzept einer programmierbaren Kontroll-CPU(denke konkret an die ARM Kerne auf Nvidias Maxwell. Aber auch SandyBridge/Fusion könnten so eine KontrollCPU in Software bereitstellen).

Dann würde es aus Sicht des Compute-Programmier so aussehen, das (ähnlich dem Kernel-Code) Kontroll-Code hochgeladen wird, der
a.) serielle Berechnungen durchführen kann(evtl. auf wenigen Threads)
b.) auch kurze Kernel effizient starten/abfragen kann
=> Die Mischung aus abwechselnd parallelen und seriellen Abschnitten wird möglich(An den kurzen seriellen Abschnitten scheitert heute meist eine GPU-Portierung).

Dabei halte ich es für wichtig, das eben nicht davon ausgegangen wird, dass KontrollCPU==HostCPU.
Vor allem KontrollCPU Nicht-x86 sollte möglich sein => der Kontrollcode sollte auch portabel als C-ähnlicher Sourcecode vorliegen, der in die Compute-API gesteckt wird.

[Coda]

APUs sind nun an jeder Ecke präsent.

Ob es alsbald entsprechende direkte Komponenten Bibliotheken und Compiler Einstellungen, für die gebräuchlichen CPU Programm Compiler geben wird.
Vorbei an der Abstraktion OpenCL oder DirectCompute?
Nein.

Edit: Ich muss doch genauer werden: Irgendwelchen magischen Compiler-Flags die einem das Denken abnehmen wird es nicht geben.

[Limit]

Bisher spielen die APUs ihren Vorteil der direkten Kopplung kaum aus, da konzeptionell in OpenCL/DirecteCompute/Cuda immer noch von getrennter CPU+Graka ausgegangen wird.

Von welchen APUs reden wir hier? Sandy Bridge unterstützt bisher OpenCL afaik nur CPU-seitig. Bei Bobcat sollte wohl sowohl die CPU als auch die GPU OpenCL unterstützen, aber gehört oder gelesen habe ich von OCL@Bobcat noch nichts.

Der Hauptvorteil bei APUs ist ja, dass CPU und GPU direkten Zugriff auf einen schnellen gemeinsamen Speicher haben, so dass das herumkopieren über den Bus komplett vermieden wird. Inwiefern die OCL&Co Device Memory = Host Memory erlauben, weiß ich nicht, aber es sollte keine große Sache sein das einzubauen, wenn es nicht sowieso schon vorhanden ist.

Es fehlt noch das Konzept einer programmierbaren Kontroll-CPU(denke konkret an die ARM Kerne auf Nvidias Maxwell. Aber auch SandyBridge/Fusion könnten so eine KontrollCPU in Software bereitstellen).

Dann würde es aus Sicht des Compute-Programmier so aussehen, das (ähnlich dem Kernel-Code) Kontroll-Code hochgeladen wird, der
a.) serielle Berechnungen durchführen kann(evtl. auf wenigen Threads)
b.) auch kurze Kernel effizient starten/abfragen kann
=> Die Mischung aus abwechselnd parallelen und seriellen Abschnitten wird möglich(An den kurzen seriellen Abschnitten scheitert heute meist eine GPU-Portierung).

Dabei halte ich es für wichtig, das eben nicht davon ausgegangen wird, dass KontrollCPU==HostCPU.


Du kannst beliebige Devices unter OpenCL benutzen. Es ist also prinzipiell möglich in einem x86 Rechner z.B. einen Cell Beschleuniger, eine GPU (von mir aus auch mit ARM Core) und ein FPGA einzubauen und sie am gleichen Problem arbeiten zu lassen, sofern sie alle OpenCL fähig sind. Was du als Kontroll-Code bezeichnest ist doch im Prinzip nur ein ganz normaler Kernel, der eben mehr sequentiellen als parallelen Code enthält. Da du frei entscheiden kannst welchen Kernel du welchem Device zuteilst, sehe ich das Problem nicht.

Vor allem KontrollCPU Nicht-x86 sollte möglich sein => der Kontrollcode sollte auch portabel als C-ähnlicher Sourcecode vorliegen, der in die Compute-API gesteckt wird.

Der Code wird in OpenCL geschrieben und muss von "jedem" OpenCL-fähigen Device ausgeführt werden können. Da sich x86 und ARM CPUs von der Grund-Architektur nicht wesentlich unterscheiden sollte jeder Kernel, der auf x86 gut läuft auch ganz gut auf ARM laufen.


APUs sind nun an jeder Ecke präsent.

Ob es alsbald entsprechende direkte Komponenten Bibliotheken und Compiler Einstellungen, für die gebräuchlichen CPU Programm Compiler geben wird.
Vorbei an der Abstraktion OpenCL oder DirectCompute?

Das wird es in absehbarer Zeit nicht geben, da die Befehlssätze zu sehr variieren und im Fluss sind.

Im besten Fall wirst du Bibliotheken für z.B. C/C++ bekommen, die irgendwelche Funktionen bereitstellen und die dann auf entsprechende OpenCL Kernel mappen.

[del_4901]

Man kann da eventuell was ueber die Sprache drehen. Eine funktionale Programmiersprache ist beispielsweise viel einfacher zu vektorisieren und parallelisieren.

[Nighthawk13]

Von welchen APUs reden wir hier? Sandy Bridge unterstützt bisher OpenCL afaik nur CPU-seitig. Bei Bobcat sollte wohl sowohl die CPU als auch die GPU OpenCL unterstützen, aber gehört oder gelesen habe ich von OCL@Bobcat noch nichts.

SandyBridge/Bobcat natürlich nur, wenn die GPU genutzt wird. OpenCL@CPU ist wenig spannend in meinen Augen. Man kann damit mit wenig Aufwand SSE+Multicore programmieren, aber mit OpenMP + asm/intrinsics hat mehr Optimierungsmöglichkeiten.


Der Hauptvorteil bei APUs ist ja, dass CPU und GPU direkten Zugriff auf einen schnellen gemeinsamen Speicher haben, so dass das herumkopieren über den Bus komplett vermieden wird. Inwiefern die OCL&Co Device Memory = Host Memory erlauben, weiß ich nicht, aber es sollte keine große Sache sein das einzubauen, wenn es nicht sowieso schon vorhanden ist.

Um das Kopieren zu Vermeiden gibt's in Cuda schon länger mapped memory: Die GPU kann direkt lesend/schreibend auf speziell allokierten CPU-Speicher zugreifen. Wenn die GPU ein Ion ist, greift sie damit direkt auf den Hauptspeicher zu, gibt ja nix anderes;)
Als eine "echte" APU würde ich Ion dennoch nicht sehen, es fehlt die Möglichkeit schnell zwischen seriellen+parallelen Codeteilen hin- und herzuschalten(Stichwort: Kernel Launch Overhead).
Das ist für mich der Hauptvorteil einer APU: Sie muss gemischt serielle/parallele Workloads schnell Abarbeiten können.


Du kannst beliebige Devices unter OpenCL benutzen. Es ist also prinzipiell möglich in einem x86 Rechner z.B. einen Cell Beschleuniger, eine GPU (von mir aus auch mit ARM Core) und ein FPGA einzubauen und sie am gleichen Problem arbeiten zu lassen, sofern sie alle OpenCL fähig sind. Was du als Kontroll-Code bezeichnest ist doch im Prinzip nur ein ganz normaler Kernel, der eben mehr sequentiellen als parallelen Code enthält. Da du frei entscheiden kannst welchen Kernel du welchem Device zuteilst, sehe ich das Problem nicht.

Im Kernel kann kein weiterer Kernel aufgerufen werden bzw. der Status eines gestarteten Kernels abgefragt werden(läuft er noch/beendet?).
Ansonsten hast du aber Recht, man könnte die (OpenCL-)Sprache nehmen und um Kernelkontrolle auf anderen Devices erweitern.

[Coda]

Man kann da eventuell was ueber die Sprache drehen. Eine funktionale Programmiersprache ist beispielsweise viel einfacher zu vektorisieren und parallelisieren.
Mein Eindruck ist, dass das für massive Parallelisierung auch eher Wunschdenken ist. Zumindest müsste man den Code trotzdem speziell auslegen.

[Avalox]

Das wird es in absehbarer Zeit nicht geben, da die Befehlssätze zu sehr variieren und im Fluss sind.


Doch dieses ändert sich doch gerade. Es ist die Kernidee der Überlegung.

Die Diversität nimmt durch die APU drastisch ab.

Die GPU bleibt über die gesamte Laufzeit der CPU gleich, auch wird die eine CPU immer mit der einen GPU geliefert. Zudem ist die GPU deutlich näher an der CPU und Latenzen entsprechende geringer.

Die APU ist doch viel mehr als nur eine günstigere Grafik. Der Ansatz ist doch viel revolutionärer und bietet deutlich mehr Möglichkeiten.

Wenn ein Intel oder ein AMD eine neue APU auf den Markt bringen, erweitern sie eben ihrere Komponenten Bibliothek, mit ein paar portierten häufiger gebrauchte und passenden Standardfällen. Welche entweder schick auf der GPU der APU laufen und wenn diese nicht vorhanden ist, eben schön optimiert als Fallback auf der CPU gerechnet werden. Der Hersteller der Software liefert, wenn überhaupt nötig, ein Update.
Besonders dramatisch wäre es nicht und gerade bei den zukünftigen Zielplattformen mit den eher etwas schwächeren CPU Kernen würde es eine Menge bringen, da gerade Anwendungsfälle profitieren werden, welche besonders langsam waren. Ein schönes Alleinstellungsmerkmal eines Herstellers wäre es zudem.

Intel baut tolle Compiler, weshalb sollten sie also die GPU in der APU so links liegen lassen?

Wenn die 3D GPU niemals in die Grafikkarte eingezogen wäre, sondern von Anfang an als Erweiterung der CPU, eben als APU zu betrachten gewesen wäre: Hätte es dann jemals ein OpenCL oder ein DirectCompute gegeben? Doch wohl eher nicht.


Bin auch ferner mal gespannt, wann das Thema APU als CPU Erweiterung interpretiert wird und das AMD/INTEL CPU Erweiterungs Lizenzaustauschabkommen herangezogen wird... Denn die Verschmelzung von CPU und GPU wird doch weiter geführt werden.

[Trap]

Mein Eindruck ist, dass das für massive Parallelisierung auch eher Wunschdenken ist. Zumindest müsste man den Code trotzdem speziell auslegen.
Der Meinung ist Guy Steele auch: http://vimeo.com/6624203

[Aquaschaf]

Intel baut tolle Compiler, weshalb sollten sie also die GPU in der APU so links liegen lassen?

Automatische massive Parallelisierung ist Wunschdenken. Egal was man macht, man kommt nicht daran vorbei sich die parallele Lösung auszudenken. Auf die eine oder andere Weise. Das kann etwas hardwarenahes wie OpenCL sein, oder z.B. irgendeine high-level funktionale Sprache. Den Compiler der dir deine sequentiellen Programme auf magische Weise parallel macht wird es nie geben. Und den hätte es auch in einer alternativen Zeitlinie in der CPU & GPU nie seperat gewesen wären nicht gegeben.

[Nighthawk13]

Wenn die 3D GPU niemals in die Grafikkarte eingezogen wäre, sondern von Anfang an als Erweiterung der CPU, eben als APU zu betrachten gewesen wäre: Hätte es dann jemals ein OpenCL oder ein DirectCompute gegeben? Doch wohl eher nicht.


Dann hätten wir heute einen x88-Befehlssatz der auf vec3+1 (RGB+A) basiert, weil das vor 7 Jahren(Ati X800 Zeiten) der Stand der Technik war.

Und heute würde jede GPU eine sinnlose Decoder-Schicht haben, die die alten 3+1 Vektorbefehle auf die heutige interne Skalar/VLIW Architektur umsetzt, damit die binären Legacy-Anwendungen von damals auch noch schön laufen.

Es ist imho besser, dass der interne Befehlssatz von GPUs NICHT offenliegt, sondern alle GPU-APIs auf dem relativ hohen Abstraktionslevel der Sprache C funktionieren.
Dann muss man langfristig kein Blei im Chipdesign mitschleifen für Legacy-Support.
Neue Architektur => Neuer Compiler und das wars. Sehe ich langfristig als das bessere Konzept(zumindest im High-Performance-Bereich).

[Avalox]

Automatische massive Parallelisierung ist Wunschdenken.

Warum automatisch?

Es soll nichts automatisch parallelisiert werden.

Eine Bibliothek mit einen Satz von fertig realisierten Lösungen für häufiger auftretende und gut zu parallelisierende Problemfälle im Umgang mit größeren Datenmengen.

Diese Bibliothek würde dann eben auch Implementierung auf der CPU mitliefern, sodass prinzipiell diese auch ohne APU zu nutzen wären, natürlich mit der APU aber zu Höchstleistungen auffährt..

Die Bibliothek wird dann nicht(!) automatisch erstellt, sondern es grübelt der Entwickler der APU darüber.

[Coda]

Das gibt's doch alles schon. Jegliche Abstraktion wird aber immer die Mächtigkeit beschneiden müssen gegenüber OpenCL/CUDA/etc. wenn es einfacher sein soll.

[Aquaschaf]

Warum automatisch?

Es soll nichts automatisch parallelisiert werden.

Eine Bibliothek mit einen Satz von fertig realisierten Lösungen für häufiger auftretende und gut zu parallelisierende Problemfälle im Umgang mit größeren Datenmengen.

Diese Bibliothek würde dann eben auch Implementierung auf der CPU mitliefern, sodass diese auch ohne APU zu nutzen wären.

Die Bibliothek wird dann nicht(!) automatisch erstellt, sondern es grübelt der Entwickler der APU darüber.

Weil du von Compilern geredet hast. Klar, an solchen Bibliotheken wird auch gearbeitet. Aber ich denke nicht dass es Sinn ergeben würde da auf einem noch niedrigerem Level als es OpenCL, DirectCompute oder Cuda bereits sind aufzusetzen.

[Avalox]

Aber ich denke nicht dass es Sinn ergeben würde da auf einem noch niedrigerem Level als es OpenCL, DirectCompute oder Cuda bereits sind aufzusetzen.

Was ist denn der Sinn der Abstraktion aus Sicht des APU Bauers?

Auch heute kommen neue CPU Erweiterungen mit jeder Prozessorgeneration hinzu, alte fliegen aus der CPU heraus.

So hat auch heute jede neue APU Version dann eben eine neue GPU als Erweiterung. Müssen halt Anwendungen neu kompiliert werden und dass sich alsbald die Architektur des GPU Teils so sehr ändert, dass sich auch der Befehlssatz massiv ändern wird steht auch noch auf einen anderen Blatt.

Weshalb sollte der CPU/APU Entwickler so sehr auf die unabhängige Abstraktion Wert legen? Damit die hinterletzte Grafikkarte, welche eh durch ihre Entfernung zur CPU kaum geeignet sein wird Ersatz zu leisten noch genutzt werden kann, oder die Lösung des Wettbewerbers automatisch auch funktioniert?

[Coda]

alte fliegen aus der CPU heraus.
Das ist bei x86 noch nie passiert.

Und ich bin mir auch sehr sicher, dass wir nie direkt auf GPU-ISA kompilieren werden. Das ist komplett sinnlos und wiederspricht völlig der allgemeinen derzeitigen Richtung eh Bytecode zu verwenden. Vorteile hätte das rein gar keine keine, bis auf eine etwas geringere Ladezeit und Nachteile en Masse.

[Aquaschaf]

Was ist denn der Sinn der Abstraktion aus Sicht des APU Bauers?

Abwärts- und Aufwärtskompatibilität. Verstecken von Implementierungsdetails um die Portabilität zu vereinfachen (auch zwischen unterschiedlicher Hardware aus eigenem Hause). Die Möglichkeit Anwendungen von Compiler-Optimierungen profitieren zu lassen ohne dass dafür die Anwendung neu kompiliert werden muss. Da kann man eine ziemlich lange Liste machen.

Und wie gesagt, das ist alles eine relativ dünne Abstraktionsschicht. In gewisser Weise sieht man das schon daran dass sich das herstellerspezifische Cuda kaum von OpenCL unterscheidet.

Soll das mit den Wettbewerbern ein Witz sein? Da könntest du genauso gut fragen wieso die Hersteller so blöd sind einen Standard wie DirectX oder OpenGL zu benutzen, schließlich laufen Anwendungen dann auch auf der Hardware ihrer Konkurrenz.

[Avalox]

Soll das mit den Wettbewerbern ein Witz sein? Da könntest du genauso gut fragen wieso die Hersteller so blöd sind einen Standard wie DirectX oder OpenGL zu benutzen, schließlich laufen Anwendungen dann auch auf der Hardware ihrer Konkurrenz.

Da der Vergleich hinkt ja nun etwas.
Erstmal gäbe es auf dem PC gar kein DirectX oder OpenGL, wenn ein 3DFX solch eine Marktdominanz an den Tag gelegt hätte, wie es heute ein Hersteller Intel tut. Zum anderen, stammen diese Ansätze aus einer Zeit, in welcher die Grafikfunktionen fix waren und meilenweit von einer general Purpose Idee entfernt und sich noch den klassischen Gerätetreiber bedienten.
Da waren ja Soundkarten früher programmierbar, als die Grafikkarte. Für welche es übrigens nie eine Abstraktion gab.

CUDA bedient letztendlich auch nur die Abstraktion, weil der Wust an unterschiedlichen Architekturansätzen des Herstellers eh schon vorhanden war.


Sieht man sich, weit entfernte aber vielleicht die nächstmöglichen verwandten Ansätze an, z.B. den CELL, dann wird dieser auch direkt bedient und ein OpenCL ist vielleicht als Notlösung im Gespräch.

Abstraktion wird bedingt durch Varianz, aber eben diese Varianz wird doch tendenziell eher abnehmen mit Einführung der APU.


Das ist bei x86 noch nie passiert.


Spontan fallen mir in einigen x86 das A20 Gate, zwar nicht als Befehlssatz, aber als Kompatibilitätsfaktor ein, wie auch das aktuell heraus gefallene 3DNow! ein.

[Coda]

Avalox, wie wäre es wenn du einfach mal was glaubst. Das ist echt nicht auszuhalten.

Wie Aquaschaf schon sagte könnte ich dir hier mindestens 20 Punkte aufführen warum man nicht direkt auf die GPU-ISA kompilieren will. Entweder du akzeptierst es oder lebst weiter in deiner Traumwelt. Won't happen.

[del_4901]

Mein Eindruck ist, dass das für massive Parallelisierung auch eher Wunschdenken ist. Zumindest müsste man den Code trotzdem speziell auslegen.
Der Meinung ist Guy Steele auch: http://vimeo.com/6624203
Ja sicherlich muesste man den speziell auslegen, das tolle daran ist aber, das der Code auf Cpu, Gpu und solch haesslichen Konstrukten wie Cell halbwegs vernuenftig laeuft ohne das man sich Gedanken ueber die Lokalitaet der Daten machen muss. Denn wenn man sich bei der Definition Derselben keine groben Schnitzer erlaubt, dann kann der Compiler entscheiden, wie er die Daten am besten auslegt.

Das ist uebrigens ne geile Praesi, auch wenn ich mittendrin leicht ins stocken geraten bin. :D

[Aquaschaf]

Sieht man sich, weit entfernte aber vielleicht die nächstmöglichen verwandten Ansätze an, z.B. den CELL, dann wird dieser auch direkt bedient und ein OpenCL ist vielleicht als Notlösung im Gespräch.

CELL ist eine schöne Bestätigung dafür warum Abstraktionen toll sind. Der wäre vielleicht beliebter gewesen, wenn es dafür früher eine abstraktere Programmierumgebung gegeben hätte.

[Nighthawk13]

CELL ist eine schöne Bestätigung dafür warum Abstraktionen toll sind. Der wäre vielleicht beliebter gewesen, wenn es dafür früher eine abstraktere Programmierumgebung gegeben hätte.
Mir fällt da noch ein anderes Beispiel ein: http://software.intel.com/file/15545
Hoffentlich sieht Intel mit Larrabee2 ein, dass eine fixe ISA keine gute Idee ist. (Man stelle sich mal den Murks vor, wenn Larabee3 intern auf VLIW wechseln würde, aber die alten Larabee-Instructions natürlich weiter supported werden müssen)

[Limit]

Um das Kopieren zu Vermeiden gibt's in Cuda schon länger mapped memory: Die GPU kann direkt lesend/schreibend auf speziell allokierten CPU-Speicher zugreifen.

Naja, das ändert nicht viel an den Latenzen. Der Weg CPU->RAM->PCIe->GPU bleibt der gleiche. Mapped Memory bringt bei einigen Anwendungsbereichen (vermutlich hauptsächlich "Stromverarbeitung") durchaus Vorteile, aber die Latenzen sind trotzdem um ein vielfaches höher als bei z.B. Multiprozessor-Systemen.

Wenn die GPU ein Ion ist, greift sie damit direkt auf den Hauptspeicher zu, gibt ja nix anderes;)

Da stellt sich die Frage nach der generellen Leistungsfähigkeit von Ion. Wenn die GPU nicht wirklich deutlich schneller ist als die CPU lohnt sich das selbst bei niedrigen Latenzen nicht.

Als eine "echte" APU würde ich Ion dennoch nicht sehen, es fehlt die Möglichkeit schnell zwischen seriellen+parallelen Codeteilen hin- und herzuschalten(Stichwort: Kernel Launch Overhead).
Das ist für mich der Hauptvorteil einer APU: Sie muss gemischt serielle/parallele Workloads schnell Abarbeiten können.

Naja, Ion ist überhaupt keine APU, schon allein weil es nicht eine "Unit" ist, sondern zwei. Der Overhead wird, denke ich, mit jeder Generation kleiner werden, aber ganz verschwinden wird er wohl nie, dafür sind auch die beiden Architekturen zu unterschiedlich (GPUs haben im Vergleich zu CPUs von Natur aus sehr viel höhere Latenzen).

Ansonsten hast du aber Recht, man könnte die (OpenCL-)Sprache nehmen und um Kernelkontrolle auf anderen Devices erweitern.

Das sollte rein technisch kein so großes Problem sein, die Frage ist doch eher, warum man das haben will. Du brauchst ja auf jeden Fall ein Host-System, warum sollte dessen CPU nicht die Organisation übernehmen? Die eigentlichen Berechnungen kannst du ja ohne weiteren in ein Kernel für irgendeine CPU packen.

Doch dieses ändert sich doch gerade. Es ist die Kernidee der Überlegung.

Die Diversität nimmt durch die APU drastisch ab.

Ach ja? Der Befehlssatz der GPUs ändert sich praktisch mit jeder Generation, teilweise sogar innerhalb einer Generation. Die Zyklen sind bei CPUs zwar etwas länger, aber auch dort würde man mit jeder Generation den GPU-Teil aktualisieren und damit dessen Befehlssatz.

Wenn du von min. 3 Herstellern (Intel, AMD, nVidia) ausgehst und sagen wir mal die letzten 3 Generation an Grafikkarten unterstützen willst bräuchtest du schon min. 9 Versionen. Bei so vielen Varianten läuft es doch am Ende sowieso darauf hinaus, dass du eine "universelle" Version schreibst und sie dann einfach durch 9 verschiedene Compiler jagst, warum also nicht direkt in OpenCL schreiben und die Arbeit einen JIT-Compiler übernehmen lassen?

Wenn ein Intel oder ein AMD eine neue APU auf den Markt bringen, erweitern sie eben ihrere Komponenten Bibliothek, mit ein paar portierten häufiger gebrauchte und passenden Standardfällen. Welche entweder schick auf der GPU der APU laufen und wenn diese nicht vorhanden ist, eben schön optimiert als Fallback auf der CPU gerechnet werden. Der Hersteller der Software liefert, wenn überhaupt nötig, ein Update.

So ungefähr wird es laufen, aber eben mit Hilfe von OpenCL/DirectCompute und JIT-Compilern. Wo siehst du da den Vorteil für "native" Compiler?


Intel baut tolle Compiler, weshalb sollten sie also die GPU in der APU so links liegen lassen?

Tut man nicht, man baut eine OpenCL JIT-Compiler.


Das ist bei x86 noch nie passiert.

Und ich bin mir auch sehr sicher, dass wir nie direkt auf GPU-ISA kompilieren werden. Das ist komplett sinnlos und wiederspricht völlig der allgemeinen derzeitigen Richtung eh Bytecode zu verwenden. Vorteile hätte das rein gar keine keine, bis auf eine etwas geringere Ladezeit und Nachteile en Masse.

*zustimm*

Sieht man sich, weit entfernte aber vielleicht die nächstmöglichen verwandten Ansätze an, z.B. den CELL, dann wird dieser auch direkt bedient und ein OpenCL ist vielleicht als Notlösung im Gespräch.

Ein Grund für den Misserfolg von Cell war die Programmierbarkeit. Sieht man ja auch bei den Konsolen, wo die Xbox Versionen häufig besser laufen, obwohl die PS3 bessere Hardware hat. Man scheut einfach den Aufwand für die spezielle Optimierung.

Abstraktion wird bedingt durch Varianz, aber eben diese Varianz wird doch tendenziell eher abnehmen mit Einführung der APU.

Das ist erst einmal nur eine These, die du so in den Raum stellst. Solange der GPU-Teil der APU einfach nur eine Abwandlung von Stand-Alone GPUs ist, wird sich auch die GPU-ISA der APU weiter ständig ändern.

[FlashBFE]

Ich finde, es entwickelt sich schon gut in eine Richtung, in der aus Programmierersicht die CPUs und GPUs verschmelzen.

Zum Beispiel (weil ich damit zu tun habe) das .NET Framework 4:
Parallele Programmierung in .NET Framework (http://msdn.microsoft.com/de-de/library/dd460693(v=VS.100).aspx)

Darin gibt es die Task Parallel Library, mit der man z.B. solchen eleganten parallelen Code für die Verarbeitung unabhängiger Daten schreiben kann:


' Sequential version
For Each item In sourceCollection
Process(item)
Next

' Parallel equivalent
Parallel.ForEach(sourceCollection, Sub(item) Process(item))


Was das Erstellen von parallelen Aufgaben angeht, gefällt mir die TaskFactory sehr gut:


Dim taskArray() = {Task(Of Double).Factory.StartNew(Function() DoComputation1()),
Task(Of Double).Factory.StartNew(Function() DoComputation2()),
Task(Of Double).Factory.StartNew(Function() DoComputation3())}


Das dritte Feld ist das Behandeln großer Datenmengen, die man datenbankartig abfragen und manipulieren will, was mit Parallel Language Integrated Query funktionert (hab ich aber noch nicht selbst benutzt):


Dim source = Enumerable.Range(100, 20000)

' Result sequence might be out of order.
Dim parallelQuery = From num In source.AsParallel()
Where num Mod 10 = 0
Select num

' Process result sequence in parallel
parallelQuery.ForAll(Sub(e)
DoSomething(e)
End Sub)



Um die Thread- und Hardwareressourcenverwaltung muss man sich bei dem ganzen Kram keine Gedanken machen, weil das Zeug eine Ebene über dem ThreadPool (den es schon vorher gab) angesiedelt ist, der automatisch Threads verwaltet und auf die Kerne zur Abarbeitung aufteilt.

Es wäre damit nur noch ein kleiner Sprung, den .NET JIT-Compiler so aufzubohren, dass er auch z.B. Direct Compute verwendet und den parallelisierten Bytecode dort abarbeitet.

[PatkIllA]

Es wäre damit nur noch ein kleiner Sprung, den .NET JIT-Compiler so aufzubohren, dass er auch z.B. Direct Compute verwendet und den parallelisierten Bytecode dort abarbeitet.Der ganze Krams sind eigentlich nur Bibliotheken. Das ist kein spezielles Sprachfeature von C# oder VB oder .NET. In die Sprache hält das erst in der nächsten Version Einzug.

[FlashBFE]

Der ganze Krams sind eigentlich nur Bibliotheken. Das ist kein spezielles Sprachfeature von C# oder VB oder .NET. In die Sprache hält das erst in der nächsten Version Einzug.

Richtig, aber was ich damit ausdrücken wollte:

die Algorithmen sind jetzt schon alle eingebaut
die Verwendung ist schon jetzt sehr einfach (im Ggs. zum Threads selbst erstellen und verwalten, was lange Zeit Standard bei den Hochsprachen war)