News Neuer Programmierstandard für CPU/GPU-Systeme

Parwez

Admiral
Registriert
Jan. 2004
Beiträge
7.472
Gemeinsam mit Cray, der Portland Group (PGI) und CAPS hat Nvidia einen neuen Programmierstandard entwickelt, der die Nutzung heterogener CPU/GPU-Rechnersysteme für paralleles Rechnen erleichtern soll. Da es im Interesse der Unternehmen liegt, eine breite Entwicklerbasis zu schaffen, ist „OpenACC“ ein offener Standard.

Zur News: Neuer Programmierstandard für CPU/GPU-Systeme
 
Die Richtung GPGPU sollte gerade von den GPU Herstellern weiter vertieft werden... Denn die Rechen Leistung der GPU wird immer mehr auch in der Industrie eingesetzt... Gerade in der industriellen Bildverarbeitung ist das denke ich schwer im kommen. So gab es au der dies jährigen Vision eine Smartcam mit einer Rechenleistung von 90GFLops zu bestauen :) (Auf AMD basis)

Die Sache mit GPUs für die industrielle Bildverarbeitung hatte ich in einem Projekt schon einmal untersucht... Bei hochauflösenden Bilder kann man mit einer vergleichbaren GPU fast 80 mal so schnell sein wie mit einer CPU!
 
Super, hoffen wir mal das so was von allen Weiterentwickelt wird.
Besonders gut für Llano und Brazos, die ja so schon sehr interessant für nicht Gamer sind.
 
Ich denke bis das Einzug auf regulären Desktopsystemen erhält und Anwendungen das einsetzen sind Llano und Brazos schon komplett veraltet. Da halte man sich doch lieber an OpenCL.

Gruß FatFire
 
Hört sich ja ganz interessant an, aber ich fänds besser, wenn die ganzen Unternehmen an einem Standard, wie OpenCL, festhalten würden und dort konsequent weiterentwickeln.
Ist natürlich auch nicht schlecht, wenn man seinen bestehenden Code komplett behalten kann und nur durch hints eine Beschleunigung des Programms umsetzen kann.

Gruß, Kami
 
Was viele wahrscheinlich interessieren wird, findet man in den offiziellen FAQs auf der Projektseite:

Will OpenACC run on AMD GPUs?
o It could, it requires implementation, there is no reason why it couldn’t

Will OpenACC run on top of OpenCL?
o It could, it requires implementation, there is no reason why it couldn’t

Ohne mindestens einen der beiden Punkte dürfte sich das im Consumerbereich auch kaum durchsetzen und wäre dann für die meisten Leser hier sicher nicht so sonderlich interessant. ^^

Aber wenn durch dieses OpenACC ein offener Weg geschaffen wird, der das parallele Programmieren erleichtert und damit die GPGPU-Nutzung verbreitet, dann ist das nur gut :)
 
leider irgendwie blödsinn! überlegt mal wie viele standards es für solchen kram gibt, da macht ja echt jeder irgendwo seinen eigenen aber nix is unifiziert! bitte bitte macht doch einfach mal alle z.B. für/mit opencl. CUDA ist mir im moment ein bissel zu stark. :)
 
Guck dir lieber C++ AMP (Accelerated Massive Parallelism) an. Darin liegt die Zukunft.

Das ist normales C++ und erlaubt heterogenes computing auf CPUs, GPUs und in der Cloud, während alle anderen Lösungen meistens nur auf eine Sache begrenzt sind.

Ich kann jedem, der sich für Nebenläufigkeit und Parallelisierung interessiert dieses Video nur wärmstens an's Herz legen. Danach versteht man wirklich worum es bei C++ AMP geht und welches Vorteile es gegenüber OpenCL/CUDA, der PPL oder sonstigen Bibliotheken bietet.

Hier sind auch ein paar Beispiele.
Man sollte sich allerdings auch schon mit C++11 auskennen und solche Dinge wie Lambda Expressions beherrschen.

PS: Irgendwann soll AMP eventuell auch in .NET Einzug halten. Das könnte aber noch ein Weilchen dauern. AMP ist noch recht jung und steckt noch in den Kinderschuhen.
 
Zuletzt bearbeitet:
Cray ist toll!
Von denen sagte man doch schon zu Zeiten, als die Prozessoren im Megahertz Bereich getaktet haben, dass ein Cray sogar die Endlosschleife in 4 Stunden durchrechnen könne :lol:

Besonders sympathisch sind sie für mich immer dadurch, dass sie in ihrer HPC Ware eigentlich nur Opterons verbauen. Und mit den Opteron 6200 haben sie eine mächtige "Waffe" in die Hand bekommen.
 
noxon schrieb:
Ich kann jedem, der sich für Nebenläufigkeit und Parallelisierung interessiert dieses Video nur wärmstens an's Herz legen. Danach versteht man wirklich worum es bei C++ AMP geht und welches Vorteile es gegenüber OpenCL/CUDA, der PPL oder sonstigen Bibliotheken bietet.

Sehr interessantes Video. Aber Lambdas werden meiner Meinung nach nie Teil vom "Mainstream" sein. Noch dazu wo der Durchschnittsentwickler heutzutage C/C++ nur vom Namen her kennt.

Insofern verspricht das Video einiges mehr als es letztendlich halten kann. Nichtsdestotrotz natürlich interessant zu sehen das auch Microsoft in diesem Bereich aktiv zu sein scheint.


[EDIT]

[F]L4SH schrieb:
Cray ist toll!
Von denen sagte man doch schon zu Zeiten, als die Prozessoren im Megahertz Bereich getaktet haben, dass ein Cray sogar die Endlosschleife in 4 Stunden durchrechnen könne :lol:

Das Unternehmen heute hat mit dem Unternehmen damals aber nicht viel mehr außer dem Namen gemeinsam. Letzten Endes sind sie heute nicht viel mehr als PC-Zusammenbauer ähnlich wie Dell.
 
Zuletzt bearbeitet:
Warum einen neuen Standard erschaffen? OpenCL deckt doch bereits alles ab und ist ebenfalls Open. Ich verstehe die Intention der Leute nicht, warum man unbedingt seinen eigenen Kram bringen muss.
 
Zuletzt bearbeitet:
Cytrox schrieb:
Sehr interessantes Video. Aber Lambdas werden meiner Meinung nach nie Teil vom "Mainstream" sein. Noch dazu wo der Durchschnittsentwickler heutzutage C/C++ nur vom Namen her kennt.
Also ohne Lambdas kann ich schon gar nicht mehr auskommen. Wer zum Beispiel in .NET programmiert, der kommt schon seit langem nicht mehr drum herum. Das ganze Framework ist auf Lambdas ausgelegt. Ohne kannst du es gar nicht mehr verwenden. Zumindest die neueren Features, die in letzter Zeit hinzugekommen sind.

Ich finde die Lösung, wie sie C++ AMP mit den Lambdas implementiert haben auch ganz elegant. Ich sehe nicht, wo der Mainstream da irgendwelche Probleme mit haben sollte.

In Java halten die jetzt jetzt auch nach langer langer Zeit endlich einzug. (Wird auch langsam Zeit) Damit werden die also in jeder modernen Sprache vertreten sein und der Mainstream wird damit auch zurecht kommen, denke ich. Das sollte also nicht das Problem sein.
 
Zuletzt bearbeitet:
noxon schrieb:
Also ohne Lambdas kann ich schon gar nicht mehr auskommen. Wer zum Beispiel in .NET programmiert, der kommt schon seit langem nicht mehr drum herum. Das ganze Framework ist auf Lambdas ausgelegt. Ohne kannst du es gar nicht mehr verwenden.
*PANIK* OH MEIN GOTT, ich kann mit den Lamda-Ausdrücken nicht umgehen und bin VB-Programmierer, heißt das ich bin jetzt komplett nutzlos?!?

Ne, mal ehrlich: selten so einen Schmarrn gelesen. Lambda-Ausdrücke sind ein nice to have, genau so wie der Rest von Linq, brauch aber de Facto keine Sau :evillol:
An Unis und Fachhochschulen kommt man da vielleicht schon seit einer Weile nicht mehr drumherum, aber in der realen Welt-Programmierung kommt das jetzt erst langsam an (ich rede hier immer noch von .NET).
Beides gibt es erst sei .NET 3.0, es gibt viele die der Kompatibilität gegenüber einer großen Anwenderschicht zuliebe standardmäßig noch auf 2.0 programmieren und nichts vermissen.

Gruß FatFire
 
noxon schrieb:
Also ohne Lambdas kann ich schon gar nicht mehr auskommen. Wer zum Beispiel in .NET programmiert, der kommt schon seit langem nicht mehr drum herum. Das ganze Framework ist auf Lambdas ausgelegt. Ohne kannst du es gar nicht mehr verwenden. Zumindest die neueren Features, die in letzter Zeit hinzugekommen sind.

Naja, man sollte wohl zwischen Lambdas in ihrer "allgemeinen Form" und speziellen Features in .Net unterscheiden. In .Net wird man ja als Entwickler an die Hand genommen und vorsichtig durch die komplexen Teile geführt .. Teilweise/Notfalls klickt man ja nur noch durch Assistenten wenn man sonst keine Ahnung hat.

noxon schrieb:
In Java halten die jetzt jetzt auch nach langer langer Zeit endlich einzug. (Wird auch langsam Zeit)

Hm.. das ist mir entgangen. Mal sehen was da draus wird. Jedenfalls ist die Einfachheit der Sprache damit jetzt wohl dahin und wir werden in Zukunft einiges mehr an kryptischem Java Code sehen als bisher :\

Andererseits wurden ja auch Annotations vor einer Weile eingeführt, aber wirklich breite Akzeptanz, außer bei JSPs/Servlets/EJBs, haben die auch nicht gefunden.

FatFire schrieb:
An Unis und Fachhochschulen kommt man da vielleicht schon seit einer Weile nicht mehr drumherum, aber in der realen Welt-Programmierung kommt das jetzt erst langsam an (ich rede hier immer noch von .NET).

Unis haben sich in der Hinsicht schon fast perfekt der Arbeitswelt angeglichen und gehen sogar nen schritt weiter in dem Sie .Net gar nicht mehr unterrichten...

Wozu auch. Java bietet alles um vorgestellte Algorithmen zu implementieren, hat kaum (um nicht zu sagen keinerlei) kryptische Konstrukte mit denen sich Professoren oder Studenten selbst ins Aus manövrieren könnten, und ist obendrein auch noch vollständig gratis.
 
Zuletzt bearbeitet:
Cytrox schrieb:
Unis haben sich in der Hinsicht schon fast perfekt der Arbeitswelt angeglichen und gehen sogar nen schritt weiter in dem Sie .Net gar nicht mehr unterrichten...

Wozu auch. Java bietet alles um vorgestellte Algorithmen zu implementieren, hat kaum (um nicht zu sagen keinerlei) kryptische Konstrukte mit denen sich Professoren oder Studenten selbst ins Aus manövrieren könnten, und ist obendrein auch noch vollständig gratis.
Mit welcher Programmiersprache man dort konfrontiert wird, ist letztendlich doch immer stark vom Professor abhängig. Wenn man während seiner kompletten Studienzeit aber nur mit Java konfrontiert wird, finde ich das etwas weltfremd.
Klar, angefangen haben wir dort auch mit Java, aber im Laufe der Zeit kamen C++, C#, Perl, PHP und noch so ein paar Kandidaten mal zumindest in Erscheinung. Letztendlich ist es egal, mit welcher Sprache man konfrontiert wird, weil es darum geht, die Denkweisen der Sprachen zu verstehen. Dann sollten es zumindest zwei sein, um zu erkennen, wie einfach es eigentlich ist, Konzepte aus einer in eine andere Sprache mit zu nehmen.
Ich würde mir wünschen, das dort auch alternative Programmierkonzepte vorgestellt werden wie z.B. funktionale Programmierung. In welcher Form ist ja auch relativ egal, ob es im Rahmen von Linq, F#, Scala oder auch SQL ist spielt ja keine Rolle. Hauptsache, man hat die unterschiedliche Denkweise mal mitbekommen.

Man kann übrigens auch mit .NET vollkommen gratis programmieren, das Framework ist gratis, von Microsoft selbst gibt es die Visual Studio-Express-Versionen und man kann sogar auf recht gute Dritt-IDEs zurückgreifen (SharpDevelop). Also da hat sich seit den Anfängen von .NET doch einiges getan und ich kenne eigentlich keine Hochschule, die ihren Studenten keine vollständigen MSDN-Zugänge und damit Zugriff auf die nötigen Entwicklungswerkzeuge bietet. Klar, die machen das auch nur zum Anfixen, aber einem geschenkten Gaul...
Und ich persönlich programmiere gefühlt auch flüssiger mit Visual Studio als mit Eclipse oder Netbeans. Natürlich ist Java hinsichtlich der Portabilität unschlagbar. Nur das der ganze Krempel jetzt unter Oracles Fittichen steht stößt mir doch sehr übel auf. Kann den Laden nicht leiden. Freue mich trotzdem jedes Mal, wenn ich auf der Arbeit mal wieder Java programmieren "muss". ;)

Gruß FatFire
 
FatFire schrieb:
Klar, angefangen haben wir dort auch mit Java, aber im Laufe der Zeit kamen C++, C#, Perl, PHP und noch so ein paar Kandidaten mal zumindest in Erscheinung.

Je nach Uni. Bei meiner kleinen "Dorfuni" hier gibt's nicht viel mehr als Java ... zumindest nicht außerhalb von Vorlesungen.

FatFire schrieb:
und ich kenne eigentlich keine Hochschule, die ihren Studenten keine vollständigen MSDN-Zugänge und damit Zugriff auf die nötigen Entwicklungswerkzeuge bietet. Klar, die machen das auch nur zum Anfixen, aber einem geschenkten Gaul...

Oh doch, da wird ins Maul geschaut. Wenn man weiß das man für den kommerziellen Einsatz später mal blechen darf ist die Bereitschaft sich das genauer anzusehen eher gering.

Und es sind nicht nur die Tools sondern das ganze Ökosystem - Drittanbieter-Bibliotheken, Betriebssystem, etc.
 
Cytrox schrieb:
Oh doch, da wird ins Maul geschaut. Wenn man weiß das man für den kommerziellen Einsatz später mal blechen darf ist die Bereitschaft sich das genauer anzusehen eher gering.
Aber die Entscheidung treffe im Normalfall doch nicht ich selbst, sondern mein Arbeitgeber. Und selbst wenn Du Dich selbstständig machst oder beratende Tätigkeiten in einer Firma übernimmst und letztendlich mit entscheidest, womit gearbeitet wird, kann auch kostenlose Software gegenüber kommerziellen Produkten im Endeffekt teurer sein. Vielleicht weil der Wartungsaufwand größer ist oder der Entwicklungsprozess nicht so schnell von der Hand geht. Da kann man mit besserer Software Personalkosten sparen bzw. mehr Aufträge in kürzerer Zeit erledigen. Sowas sollte immer vorher geprüft werden.

Und wenn Du die Möglichkeit hast, während Deines Studiums diese ganze Software kostenfrei auszuprobieren, so solltest Du dies aus wahrnehmen. Erstens ist es nie verkehrt, seinen Horizont zu erweitern und zweitens weißt Du nie, womit Du im späteren Arbeitsleben konfrontiert wirst.

Gruß FatFire

PS: Man verstehe mich bitte nicht falsch, ich will jetzt hier bestimmt nicht die Microsoft-Werbetrommel rühren. Ich bin selbst ein großer Fan von Open-Source, aber im Arbeitsleben zählen einfach andere Dinge als Ideologien oder persönliche Vorlieben. Und im Kostenvergleich schneidet Open-Source, Kostenlos und Geiz ist Geil eben nicht immer am Besten ab.
 
Also, das ist zwar ein "neuer" Pseudostandard, allerdings lehnt er sich doch stark an HMPP an. Wer bereits Erfahrungen mit OpenMP gemacht hat (wer ernsthaft entwickelt und im technisch/wissenschaftlichen Umfeld aktiv ist, sollte dies ...), wird sicher das Potential dieser "Standards" erkennen. Vorhandene Software mus nicht umständlich neu strukturiert und algorithmisch an die Datenmodelle von OpenCL oder CUDA angepaßt werden.

Microsoft will ja auch in diesem Umfeld Fuß fassen. Der Ansatz von M$ ist allerdings meiner Meinung lächerlich, weil kommerziell. Offene Standards, die sich in quelloffene Compiler einbinden lassen, wie etwa LLVM/CLANG, messe ich eine größere Chance bei.

Das OpenCL/CUDA Modell ist wie OpenMPI einfach zu umständlich, wenn auch sehr mächtig (wobei wir/ich OpenCL bevorzugen).
 
Zurück
Oben