Hat Apples "Grand Central" was mit LLVM zu tun?

[peanball]

Apple hat ja auf der WWDC08 was von einer Technologie namens "Grand Central" erzählt. Damit sollen Objective-C Programme relativ automatisiert auf mehrere Threads verteilt werden.
Das Beste: Diese Threads sollen auf der CPU und auf der GPU laufen können. Zweiteres klingt nach dem Einbeziehen von CUDA bzw. OpenCL.

Ich frage mich, ob die generelle Technik was mit LLVM zu tun hat und der Compiler bei Bedarf für CPU oder GPU compiliert...

Leider habe ich bisher keine weiteren Infos gefunden ob die beiden Techniken was mit einander zu tun haben könnten. Was meint ihr?

[Ganon]

Naja, da spielen mehrere Faktoren mit. Das jetzige Cocoa ist an sich schon recht gut gethreaded. Sogar die OpenGL-Pipeline kann bei bedarf Multithreaded laufen (die ist ja schon in LLVM).

LLVM an sich verspricht kein automatisiertes Threading. Aber von der Theorie her wäre es möglich mit einem GPU Backend für LLVM.

"Normale" Anwendungen wird man so aber wohl kaum auf einer GPU laufen lassen wollen. Das wäre Leistungsmäßig keine gute Idee, da GPUs Streamprozessoren sind.

Was ich mir vorstellen könnte, wäre das Apple ihre "Accelerate" Backends damit schreibt, bzw. es über LLVM steuert.

Das Accelerate Framework übernimmt sehr viele Aufgaben in OS X (BigNum, FFT, etc.). Sei es CoreImage (selbiges läuft schon in so etwas ähnlichem wie LLVM), QuickTime, die Image-Librarys, die Sound-Library). Alle greifen darauf zu.

Das Accelerate-Framework bietet zur Zeit BackEnds für (x86),ppc, SSE und Altivec. Es wäre da für Apple kein Problem diese auch noch um ein OpenCL BackEnd zu erweitern.

Ob Apple das dann aber über LLVM macht, oder direkt, kann man so schlecht sagen.

Erfahrung hat Apple damit ja schon. Wie ich oben schon sagte kann CoreImage selbst entscheiden, ob es SSE, Altivec oder OpenGL2 Code erzeugt, je nach Hardware zur Laufzeit und je nach Bild.

Und LLVM hat ja bereits ein CellSPU-BackEnd. Von da dürfte es ja auch nicht mehr allzu weit sein :D

Also in kurz: Möglich ist es.

Ich wäre auch dafür das Apple LLVM endlich mal für alles einsetzt, da LLVM deutlich schnelleren Code erzeugt, als der GCC.

[Coda]

Ich bin da skeptisch. Ganz ohne zutun der Entwickler ist das kaum machbar.

Auch würde mich interessieren in welcher Art sie das implementieren wollen. Wenn es nur ala OpenMP "#pragma parallel for" ist dann ist es mit der Effizienz nicht weit her.

Ich wäre auch dafür das Apple LLVM endlich mal für alles einsetzt, da LLVM deutlich schnelleren Code erzeugt, als der GCC.
Gibt's da auch eine Quelle dazu? Einen wirklich guten Grund dafür seh ich nicht.

[Gast]

Und LLVM hat ja bereits ein CellSPU-BackEnd. Von da dürfte es ja auch nicht mehr allzu weit sein :D
Wann versteht ihr endlich, dass MT auf CPU != MT auf Cell != MT auf GPU ist?
Ausserdem stammt das SPU Backend von einem Aerospace Project.

Auf der Mailingliste von LLVM kam bisher noch keinerlei Diskussion über ein GPU Client. Deshalb halte ich es für unwahrscheinlich, dass da ein Zusammenhang besteht.

[icemanemp]

Ich bin da skeptisch. Ganz ohne zutun der Entwickler ist das kaum machbar.
Vielleicht nicht wie erwartet, d.h. Kernel/-Funktionsteile sind in Zwischencode gespeichert und werden on the fly bzw. einmalig optimiert kompiliert.
Hier muss man auch sehen, das die Arbeit Apple <-> Intel eine andere ist als mit Microsoft. Ich denke Microsoft wird und kann nicht einfach Compilertechniken in Ihre Betriebssystem implementieren. Apple dagegen scheint mir das bessere abtraktere und modularisierter System zu verwenden um direkt Intel-Techniken einzusetzen?! Ausserdem hat Apple ja auch Hardwareerfahrung und genau Einkäufe getätigt um sich in dem Bereich besseres Know-How zu bilden.
Aber nur eine Vermutung von mir, da mir die Kooperation über die Hardware hinausgehend zu sein scheint...

[Coda]

Ich versteh nicht was das mit dem Problem der automatisierten Parallelisierung zu tun hat. Das Problem ist ein weit größeres als manche es sich offenbar vorstellen.

[(del)]

Ich bin da skeptisch. Ganz ohne zutun der Entwickler ist das kaum machbar.Ich bin sogar erstmal der Meinung, daß Apple damit nur Klamotten meinte die OS X 10.6 selbst beiliegen und der Rest erstmal "dazudichten" ist.

Sprich, der Entwickler muß es "ansprechen".

[Ganon]

Ich bin da skeptisch. Ganz ohne zutun der Entwickler ist das kaum machbar.
Auch würde mich interessieren in welcher Art sie das implementieren wollen. Wenn es nur ala OpenMP "#pragma parallel for" ist dann ist es mit der Effizienz nicht weit her.

Bekannt ist noch nichts, aber ich denke, wie hier schon gesagt wurde, das Apple eher meint, das sie entsprechende Libs mitliefern, die der Entwickler nutzt.

In Leopard lieferten sie ja auch NSOperation mit, wo man Arbeitsaufgaben festlegt und die in eine Queue packt und die Lib die dann automatisch auf die CPUs verteilt.

Das kann man ja noch ausbauen.

Gibt's da auch eine Quelle dazu? Einen wirklich guten Grund dafür seh ich nicht.

Runterladen->Installieren->Testen ;) Meine alten Threads hast du ja auch dazu gelesen. ca. 20% schneller als GCC4 im JITC-Modus.

[Ganon]

Wann versteht ihr endlich, dass MT auf CPU != MT auf Cell != MT auf GPU ist?

Und was habe ich von Multithreading gesagt?

Ich sagte nur das es ein SPU-Backend hat. Und SPUs und GPUs sind schon deutlich näher als CPU und GPU.

[(del)]

Bekannt ist noch nichts, aber ich denke, wie hier schon gesagt wurde, das Apple eher meint, das sie entsprechende Libs mitliefern, die der Entwickler nutzt.Und vielleicht aber schon eigene Sachen im 10.6 drauf aufbauen. Mehr wird das aber imho nicht sein.

[Ganon]

Und vielleicht aber schon eigene Sachen im 10.6 drauf aufbauen. Mehr wird das aber imho nicht sein.

Ja, das sowieso. Viele Teile von OS X sind ja schon multithreaded. Das Problem ist eher das diese meist nur 2 CPUs nutzen. Man wird dann wohl einiges auf diese Schnittstellen aufbauen, damit auch 4, 8 oder 16, ... genutzt werden können.

Der Hauptvorteil wird wohl im Accelerate Framework liegen, sofern man das überarbeitet. Denn das nutzen alle Programme, die irgendwie davon profitieren können. QuickTime, iTunes, FinalCut, Aperture, ...

Teile von OS X werden ja auch schon per GPU berechnet. Man denke an CoreImage. Vllt. baut man dann auch andere Image-Libs wie NSImage auf CoreImage auf und CoreImage wiederum auf OpenCL als zusätzliches BackEnd. Das dürfte effektiver sein, als der OpenGL 2 Code.

Man kann so ein paar OpenGL-Grenzen übergehen.

[Gast]

Ich sagte nur das es ein SPU-Backend hat. Und SPUs und GPUs sind schon deutlich näher als CPU und GPU.
Näher?
Man kann eher ein gleichseitiges Dreieck bilden mit den 3 Architekturen als Eckpunkte.

Speicherarchitektur der GPU ist einer normalen CPU Architektur wesentlich ähnlicher als die des Cells.
Die Anzahl der benötigte Thread ähnelt beim Cell eher einer normalen CPU. Bei GPU braucht soviele Threads, wie Intel bei ihrem ManyCore auch gerne hätte.
Der Cell verreckt bei dynamischen Sprüngen, die GPU kann sie durch die hohe Threadanzahl verstecken und die CPU sortiert soweit möglich und nutzt auch zusätzliche Threads zum Verstecken (SMT).

Auf ner GPU kann ich sogar meinen Shader richtig debuggen, was beim Programmcode mit dem Cell oft nicht gegeben ist.

[(del)]

@Ganon
Du diese Eigenwerbung ist nicht nötig ;) Davon ab weiß ich das eh alles.

Das wußte ich allerdings noch nicht :up:
http://www.golem.de/0806/60315.html

[peanball]

Auch würde mich interessieren in welcher Art sie das implementieren wollen. Wenn es nur ala OpenMP "#pragma parallel for" ist dann ist es mit der Effizienz nicht weit her.

Laut der Heise Meldung http://www.heise.de/newsticker/WWDC-OS-X-10-6-versteht-sich-mit-Microsoft-Exchange--/meldung/109214 ist das wohl so.

Damit GCD weiß, wie Code in Threads zerlegt werden kann, wurde Objective-C um "Blocks" erweitert. Mit diesem Sprachkonstrukt gibt ein Entwickler GCD Hinweise, an welcher Stelle sich der Code in Threads aufteilen lässt. Den Rest übernimmt GCD automatisch.
GCD = Grand Central Dispatch, also die Steuerung von Grand Central.

Für mich klingt Grand Central insgesamt so, als könnte man mit relativ wenig Aufwand die GPU zum Mitrechnen benutzen. Wie effizient das ganze im Vergleich mit CUDA und optimiertem Code ist wäre interessant. Aber dazu gibt es noch zu wenig offizielle Informationen.

[Gast]

http://en.wikipedia.org/wiki/OpenCL

AMD:
"Das Unternehmen teilte jedoch mit, es habe sich der Khronos Compute Working Group angeschlossen, die an Industriestandards für paralleles Rechnen arbeitet und dazu eine Spezifikation für OpenCL (Open Computing Language) vorgeschlagen hat. OpenCL soll es plattformübergreifend erlauben, die GPU eines Systems für Rechenaufgaben zu verwenden. Unterstützt wird OpenCL unter anderem von Apple mit seinem kommenden Betriebssystem MacOS X 10.6 alias Snow Leopard."
http://www.golem.de/0806/60400.html