Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Spezifikationen für OpenCL 1.0 fertig gestellt

Die Khronos Group gab bekannt, die Spezifikationen für OpenCL 1.0 fertiggestellt zu haben. Bei OpenCL handelt es sich um eine Technologie, mit der die normalerweise bei gewöhnlichen Aufgaben nicht genutzte Rechenleistung der Grafikkarte eingebunden werden kann. Da die Grafikprozessoren sehr leistungsfähig sind, lassen sich bestimmte Aufgaben so je nach Anwendungsbereich signifikant beschleunigen. Von der Khronos Group wird OpenCL als erste "offene, lizenzfreie und plattform-übergreifende Lösung" dieser Art bezeichnet. Für Apple ist OpenCL sehr wichtig, da man in Snow Leopard Gebrauch von dieser Technologie machen wird, die es auch ermöglicht, die Leistung von Macs mit mehreren Prozessoren durch parallele Ausführung zu beschleunigen. Apple erwähnt zwar nur deutlich verbesserte Rechenleistung, die bisher nur für grafiklastige Programme möglich war, das Potenzial von OpenCL ist aber noch weitreichender. Was die Technologie dann in der Praxis leistet, wird man mit Snow Leopard sehen, das im nächsten Jahr auf den Markt kommt.
An der Entwicklung von OpenCL beteiligten sich neben Apple unter anderem auch Nvidia (trotz CUDA), ARM und Intel. Generell sind sich OpenCL und Nvidias CUDA sehr ähnlich, ein wichtiger Unterschied ist aber, dass bei Apples Lösung nicht nur bestimmte Nvidia-Grafikkarten eingesetzt werden können. Vor kurzem beantragte Apple auch, die Marke "OpenCL" schützen zu lassen. Momentan ist der Link zur Erklärung von Khronos leider nicht zu erreichen, da es zu einem Datenbankfehler kommt.

Weiterführende Links:

Khronos Group

Apples Eskalationskurs und Gebühren-Wirrwarr

Test FiiO FH19

iPhone 16 Pro: Tippen oder Wischen ignoriert, N...

Beddit ist Geschichte, Apple entfernt Apps

Bewertung der gestrigen Neuvorstellungen: Umwer...

Vor 15 Jahren: Als der iMac riesig wurde

Apple kündigt September-Event an

iPhone 16: Lieferzeiten teils deutlich gestiege...

Kommentare

methos09.12.08 10:29

Bei allem Respekt vor den Apple-Entwicklern, aber ich befürchte das sie sich mit solchen Aussagen über den Geschwindigkeitszuwachs nicht so stark aus dem Fenster lehnen sollten. Das ein Geschwindigkeitsvorteil durch OpenCL entsteht ist bei einer guten Programmierdruchführung auch realistisch, aber leider werden da nur Spezialanwendungen wirklich davon profitieren. Nehmen wir Quartz Extreme das ja auf Basis von OpenGL auch schon die Grafikkarte in das UI einbezieht muss man sich doch mal ehrlich fragen ob man bei TextEdit die zusätzlich verfügbaren Ressourcen der Graka noch nutzen sollte (Energieeffizienz). Ein wenig sarkastisch aber ich denk ihr wisst was ich mein.

macbeutling09.12.08 10:49

Ich vestehe zwar nichtso viel von Prozessor-Architektur, aber bei dem was ich so mitbekomme,können ja schon die wenigsten Anwendungen von Dual-Core-CPUs profitieren,oder?
Wenn das alleine gedeichselt werden würde, wäre der Geschwindigkeitszuwachs doch schon enorm.
methos: ich glaube auch nicht,dass ein Programm wie TextEdit soviel Power braucht, aber alleine eine Konvertierung eines .avi in ein .m4v könnte ein bißchen mehr Speed vertragen.

Glück auf🍀

tiriqs09.12.08 10:52

oder denk an das compilieren beim entwickeln,
photogeshoppe, usw.

methos09.12.08 10:56

Also die Parallelisierung der Anwendungen für MultiCore System ist eine andere Baustelle, da hat OpenCL nur indirekt etwas damit zu tun. OpenCL macht ja einen Parallelisierung zwischen CPU und GPU und soweit ich das jetzt mitbekommen haben nicht zwischen den CPU-Kernen.

Wenn das alleine gedeichselt werden würde, wäre der Geschwindigkeitszuwachs doch schon enorm.

Das ist schon korrekt wie man es ja auch bei FreeBSD 7.0 sehen kann bringt das eine Menge. Jedoch ist bei OpenCL meine Befürchtung das die Leistung proportional zum Stromverbrauch (interessant bei MacBooks) zu unterschiedlich ist. Brauchen wir so einen enorme Leistung beim Finder, der auch davon profitiert weil die GPU meinetwegen bei CoverFlow mitarbeitet. Das geht doch alles zu lasten der Laufzeit.

tiriqs09.12.08 11:23

es wäre schön wenn man openCL selbst aktivieren/deakt. kann

methos09.12.08 11:39

Es handelt sich aber hierbei um ein Framework bzw. Interface auf das die SL Programme aufsetzen, somit ist es auch immer aktiviert. Durch die Einbindung der GPU werden wir in Zukunft dafür aber auch noch schickere Apps bekommen, wie zum Beispiel ein iPhoto in dem wir unsere Bilder ohne davor aufwendiges Rendering in einen 3D-Bilderbuch anschauen können. Also alles viel dynamischer als mit Quartz alleine und viel eingebetteder als mit einer reinen OpenGL-App. Alles in einem flüssigen Übergang zwischen Cocoa und OpenGL.

tiriqs09.12.08 12:00

hmm, dann würden diese programme aber nie ohne openCL laufen.
ich denke dass sich apple dazu etwas einfallen lässt, dass dynamischer zu gestalten

osxnerd09.12.08 12:24

OpenCL ist nichts weiter als eine Industrienorm für eine Programmierumgebung, mit der man neue, parallelisierte Programme schreiben kann, wenn man das denn will.

Auf bestehende Programme hat das keine Auswirkung. Und Parallelisierung ohne Mitwirkung des Programmierers ist sowieso völlig unmöglich.

Es könnte im allerbesten Fall höchstens eine indirekte Beschleunigung alter Software geben, wenn ein Programm beispielsweise irgendeine Funktion "XYZ" aus Mac OS X nutzt, die bisher lahm programmiert war, die Apple aber zukünftig auf Basis von OpenCL neu entwickelt.

MacRabbitPro09.12.08 12:31

osxnerd

Und Parallelisierung ohne Mitwirkung des Programmierers ist sowieso völlig unmöglich.

Das stimmt so generell nicht. Es ist denkbar dass der Compiler entsprechende optimierungen vornimmt (indem er z.B. Loops aufteilt).

Außerdem geht es bei GrandCentral ja gerade darum, es dem Entwickler wesentlich leichter zu machen, eine App zu entwicklen die für parallel Ausführung geeignet ist. Das hat aber mit OpenCL nix direkt zu tun.

MacRabbitPro09.12.08 12:38

methos

Scherzkeks! Ein Programm wie TextEdit verbringt 99% seiner Laufzeit damit, auf den nächsten Tastendruck des Users zu warten. In der Zeit ist der Prozess Idle und dann wird auch nix gerechnet und im prinzip auch keine Energie verbraucht.

Nur weil OpenCL zur verfügung steht heißt das nicht, dass jetzt jedes Programm wie verrückt rechnet, selbst wenn es nix zu rechnen gibt!

methos09.12.08 13:27

Natürlich verbringt TextEdit dann solange ich keine neue Taste anschlage seinen Prozess im idle Zustand, aber es würde dann ja sobald ich eine Taste gedrückt habe dann jeder kleine Furz parallel aufgeteilt werden. Ich hab mir die Specs angeschaut und dadurch das eben alles "automatisch" gethreadnet wird bekommt man immer wieder solch Kurzeinsätze der GPU. Natürlich können wir alle nicht einsehen ob das dann später auch wirklich so der Fall ist. Kann euch ja auch nicht sagen ob die Jungs in Cupertino das so durchziehen. Es war ja auch nur eine Befürchtung von mir. Außerdem war TextEdit nur ein abstraktes Beispiel.

tomvos09.12.08 13:39

Auf bestehende Programme hat das keine Auswirkung. Und Parallelisierung ohne Mitwirkung des Programmierers ist sowieso völlig unmöglich.

Das stimmt so generell nicht. Es ist denkbar dass der Compiler entsprechende optimierungen vornimmt (indem er z.B. Loops aufteilt).

Die Optimierung muss noch nicht einmal so tief im System ansetzen. Es ist denkbar, dass Apple einige seiner Frameworks an OpenCL ankoppelt.

Viele der Frameworks für Graphik-Funktionen basieren letzten Endes auf OpenGL. Als Entwickler muss eine Graphik-Routine aber nicht in OpenGL implementiert werden, sondern man kann auf diverse übergeordnete Frameworks - wie QuartzCore - zurückgreifen. Das erleichtert die Programmierung, weil man sich nicht um alle Details kümmern muss - trotzdem nutzt eine Anwendung die Möglichkeiten der Grafikkarte.

Mit OpenCL wird das ähnlich. Ein Großteil der Programmierer wird niemals OpenCL direkt nutzen, sondern die darüber liegenden Frameworks. Als Programmierer muss man sich nicht (kaum) umstellen, lediglich einmal den Code mit den neuen Frameworks bauen.

Es ist die Aufgabe von Apple innerhalb von Snow-Leopard die High-Level-Frameworks entsprechend anzupassen, dass diese das auf OpenCL auslagern, was dort gut aufgehoben ist. Ich würde da z.B. an das Accelerate.Framework, DVDPlayback.Framework, QTKit.Framework, vecLib.Framework und anderes denken, die sicherlich von OpenCL profitieren werden.

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

osxnerd09.12.08 13:49

MacRabbitPro

Das stimmt so generell nicht. Es ist denkbar dass der Compiler entsprechende optimierungen vornimmt (indem er z.B. Loops aufteilt).

Nein. Natürlich kann der Compiler optimieren, aber das ist nicht die Art von Parallelisierung, um die es bei OpenCL geht.

iCode09.12.08 14:01

Außerdem geht es bei GrandCentral ja gerade darum, es dem Entwickler wesentlich leichter zu machen, eine App zu entwicklen die für parallel Ausführung geeignet ist. Das hat aber mit OpenCL nix direkt zu tun.

Mit OpenCL wird man sowieso eher selten direkt zu tun haben. GrandCentral vereint die ganzen unterschiedlichen Parallelisierung-/Threading-/ HighPerformance-APIs wie MPI, OpenMP, Acceleration, Xgrid, NSOperation, etc. und jetzt noch OpenCL, in einem zentralen Framework. Man muss dann für "verteilten Aufgaben", egal ob die auf CPUs, GPUs oder Xgrid-Nodes verteilt werden sollen, nicht mehr auf die etlichen verschiedene APIs zurückgreifen, sondern hat das alles komfortabel unter einem Dach.

iCode09.12.08 14:07

Ob das auch alles schon in Version 1.0 so realisiert werden kann, steht natürlich auf einem anderen Blatt.

Moogulator09.12.08 15:39

Interessant dabei ist ja, dass selbst wichtige Teile von OS X noch nicht einmal auf aktuelle Prozessoren vollständig portiert sind. Das kommt, man kann raten, teilweise mit Snow Leopard. Vermutlich auch mit dem Abschuss diverser Software. Da ist Apple ja eher radikal. Das ist ein Tempo, was einige Anwendungsprogrammierer hier und da nicht mitmachen.

Ich habe eine MACadresse!

Michael Lang09.12.08 16:01

Für Apple ist OpenCL sehr wichtig, da man in Snow Leopard Gebrauch von dieser Technologie machen wird, die es auch ermöglicht, die Leistung von Macs mit mehreren Prozessoren durch parallele Ausführung zu beschleunigen.

OpenCl soll doch für die Ausführung von parallelisierbarem Code auf der GPU sorgen. Die Verteilung von Threads auf mehrere Cores/CPUs soll doch GrandCentral übernehmen. Nur um mal diese beiden Dinge voneinader zu unterscheiden...

OpenCl wird für gewisse Aufgaben ein Menge bringen, weil die GPUs (ähnlich wie DSPs) absolute Rechenmonster sind (teilweise um Faktor 10 und mehr schneller als aktuelle CPUs). OpenCl wird nicht bei jeder App zum Zuge kommen (zB. nicht bei TextEdit!!), sonmdern nur bei speziell programmierten Anwendungen (zB. Physikengine bei Spielen, Mathematische Berechnungen bei wissensch. Apps usw.), bzw. bei Frameworks die Apple damit unterstützt (welche bereits genant wurden). Somit sollte sich die vorhanden Rechenkraft wesentlich effizienter nutzen können bei entsprechenden Aufgaben....

- Das größte Maul und das kleinste Hirn,wohnen meist unter derselben Stirn. - Hermann Oscar Arno Alfred Holz, (1863 - 1929), deutscher Schriftsteller

MacRabbitPro09.12.08 17:18

Moogulator

Interessant dabei ist ja, dass selbst wichtige Teile von OS X noch nicht einmal auf aktuelle Prozessoren vollständig portiert sind.

Beispiel?

MacRabbitPro09.12.08 17:32

osxnerd

Nein. Natürlich kann der Compiler optimieren, aber das ist nicht die Art von Parallelisierung, um die es bei OpenCL geht.

Da ging wohl etwas an Dir vorbei:

Zitat:
...So, even optimizing this for a modern parallel workstation or server takes significant work, knowledge of the memory hierarchy, and experimentation. In the past, programmers would have to do this all manually, though advanced compiler technology is now able to achieve this kind of optimization automatically.

Spezifikationen für OpenCL 1.0 fertig gestellt

Kommentare

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.