Grand Central Dispatch

[Gast]

Ist Grand Central Dispatch etwas neues bzw. besonderes oder einfach nur der Apple-Name für etwas "altes"?

PDF:
http://images.apple.com/euro/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf

Und hier die Werbung: http://www.apple.com/de/macosx/technology/#grandcentral

[Gast]

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

[Coda]

Nix neues. Thread Pools gibt's schon ewig. Das kann man sich relativ einfach auch selber zusammenbasteln.

[Ganon]

Nur das es hier halt einfacher ist, da es entsprechende Spracherweiterung gibt. Siehe das PDF. Developer-Doku sollte ja spätestens im September für alle verfügbar sein.

Die Technik im Ansatz gibt es auch schon in OS X Leopard >> NSOperation. In SnowLeopard halt vereinfacht und nicht nur auf Objective-C beschränkt.

[Hydrogen_Snake]

Ist Grand Central Dispatch etwas neues bzw. besonderes oder einfach nur der Apple-Name für etwas "altes"?

PDF:
http://images.apple.com/euro/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf

Und hier die Werbung: http://www.apple.com/de/macosx/technology/#grandcentral

Grandcentral ist ein, in seiner Nutzung, verinfachter ThreadPool.

Was mich allerdings schon überrascht. Eigentlich hatte ich angenommen das die Mail.app an der die Demo
gezeigt wurde, Multithreaded läuft. Sieht aber nicht so aus.

Wie ist das beim iPhone, ich kann z.B. beim Versand von Bildern in einer E-MAIL auch nur eine Instanz nutzen.

[SentinelBorg]

Ein Threadpool wie z.B. .NET ihn schon seit Version 1.0 anbietet. Apple schaffts halt mal wieder daraus marketingtechnisch gleich das 8. Weltwunder zu zimmern. ^^

[Gast]

So eine Diskussion gibt es auch anderen Stellen, z.B.:
http://www.reddit.com/r/programming/comments/8qtmc/an_overview_of_apples_grand_central_dispatch/

[Gast]

Was ist denn mit OpenCU
Mit OpenCU scheint aus der vorhandenen Hardware (CPUs und GPUs) eine virtuelle Struktur gebildet zu werden, mit einem Host-Prozessor und Stream-Prozessoren, auf die die Rechenlast von Host-Prozessoror verteilt wird.

Patent: http://www.wipo.int/pctdb/en/wads.jsp?IA=US2008004648&LANGUAGE=EN&ID=id00000006932039&VOL=90&DOC=00f018&WO=08/127622&WEEK=NA&TYPE=NA&DOC_TYPE=PDOC&PAGE=1

[Gast]

AMD reverses GPGPU trend, announces OpenCL SDK for x86

..
..

In other words, these common apps don't solve data-parallel, compute-intensive problems—rather, they have specific parts that need acceleration, and if there's a capable GPU available then they can use OpenCL to hand off that part to it.

Apple's upcoming Grand Central Dispatch, which will debut with Snow Leopard, aims to make it easy for Apple developers to do exactly this kind of parceling out of work to the GPU. GCD lets coders write "blocks" of OpenCL that can then be passed on either to a CPU or to a GPU, depending on the system's available hardware. In this respect, the combination of OpenCL and Grand Central Dispatch does overlap a bit with RapidMind (and the software company's former competitor, Peakstream), but insofar as the GCD + OCL combo is pushed by Apple it will certainly see wider adoption.

http://arstechnica.com/hardware/news/2009/08/amd-announces-opencl-sdk-for-x86.ars

[Gast]

Nix neues. Thread Pools gibt's schon ewig. Das kann man sich relativ einfach auch selber zusammenbasteln.
Aber nicht zentral auf Betriebsystemebene?

[Demirug]

Aber nicht zentral auf Betriebsystemebene?

Windows hat seit Vista/Server 2008 eine native Thread Pool API. Im .Net Framework gab es sie schon seit 1.1.

[Gast]

OK. Aber die Block-Geschichte in GCD ist neu oder?

Heise:
"Um an Stabilität zuzulegen und auf zukünftige Hardware-Entwicklungen vorbereitet zu sein, muss unter der Bedienoberfläche des Systems eine Menge passieren. Größte Änderung dürfte die Einführung der Bibliothek "Grand Central" sowie die zugehörige Runtime "Grand Central Dispatch" (GCD) sein. Dabei handelt es sich um eine zentrale Verwaltungsinstanz, die das Management von Ereignissen in der so genannten Event-Loop für alle Anwendungen vereinfachen soll. Dieser Verteiler führt eintreffende Ereignisse aus unterschiedlichen Quellen zusammen und leitet ihre Ausführung in die Wege. Dabei spielt es keine Rolle, ob eine CPU oder eine GPU (auf einer Grafikkarte) das erledigen.

Gleichzeitig kann GCD eine Aufgabe automatisch in kleinere Teile zerlegen (Threads). Da GCD direkt im Kernel verankert ist, weiß es immer über die aktuelle CPU-/Kernauslastung Bescheid und kann dementsprechend die Anzahl der generierten Threads variieren. 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."

bzw. http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf

[Ganon]

Na erst mal auf die Developer-Doku in Snow Leopard warten ;) Vorher spare ich mir sämtliches Rätselraten :D

Weil die Infofetzen die man überall findet sind mir zu wenig ^_^

Oder weiß zufällig jemand ob ein Pool für alle Anwendungen da ist, oder pro Anwendung ein Pool? Weil so wie sich das PDF da liest, ist GCD ein globaler Thread-Pool für alle Anwendungen (wenn man will) und somit der Kernel nicht nur pro Prozess die bestehenden Threads weiterverwendet, sondern Systemweit.

kA wie das bei anderen Systemen ist. Ich kenne halt nur normale Thread-Pool Libs wie NSOperation wo dann jede Anwendungen denn einen eigenen Thread-Pool hat.

[Demirug]

Das ist eigentlich nur syntaktischer Zucker. Funktionszeiger bzw. Implementation pointers (IMP) bei Objectiv C sind in der Benutzung so unhandlich das man für die Masse von Entwicklern einfach etwas einfacheres brauchte.

[Ganon]

Das ist eigentlich nur syntaktischer Zucker.

Also hat Vista auch einen globalen, anwendungsunabhängigen Thread-Pool (sofern ich das PDF von Apple richtig verstehe)?

Sry, mein "Windows-Wissen"-Upgrade wird erst mit Windows 7 kommen ;)

[Gast]

"Dieser Verteiler führt eintreffende Ereignisse aus unterschiedlichen Quellen zusammen und leitet ihre Ausführung in die Wege. Dabei spielt es keine Rolle, ob eine CPU oder eine GPU (auf einer Grafikkarte) das erledigen."

Hö?
Da spielt dann OpenCL mit rein oder wie ist das gemeint?

[Tiamat]

Achwas Threadpools gibt´s eigentlich in jeder kompilierten Programmiersprache. Die Einführung eines Threadpools is garantiert kein GCD.

In der englischen Doku ist das eigentlich recht anschaulich beschrieben.

Blocks
Blocks are a simple extension to C (as well as Objective-C and C++) that make it easy
for you to define self-contained units of work. A block in code is denoted by a caret at
the beginning of a function. For example, you could declare a block and assign it to x
by writing:
x = ^{ printf("hello world\n"); }
This turns the variable x into a way of calling the function so
that calling x(); in the code would print the words hello world.


Die Deklaration und der Aufruf eines Blocks reicht schon um den zugehörigen Code multithreadingfähig zu machen. Allerdings weiß ich nicht, wie man die manuellen Parts beim Threadprogrammieren automatisieren will ( Stichwort wait und notify ). Die genauen Details wird man dann nächsten Monat sehen.


How much faster?
Placing a work item in a GCD queue is a
lightweight operation. In fact, it requires
only 15 instructions, which makes the
blink of an eye seem like a long time.
By comparison, setting up a thread and
assigning work to it can require hundreds
of instructions and take more than 50
times longer.

Ich seh´s schon kommen :
NSAutoReleasePool *pool = [[NSAutolease alloc] init];
NSGcdQueue *queue = [[NSGcdQueue alloc] init];
...
;D

[Demirug]

Also hat Vista auch einen globalen, anwendungsunabhängigen Thread-Pool (sofern ich das PDF von Apple richtig verstehe)?

Sry, mein "Windows-Wissen"-Upgrade wird erst mit Windows 7 kommen ;)

Natürlich gibt es keinen gloablen Thread pool bei Windows. Das würde völlig die Prozess Kapselung und die damit verbundenen Sicherheitskonzepte unterlaufen.

[Gast]

Blocks
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10

Concurrency in the real world: a prelude
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/11

Grand Central Dispatch
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12

Grand Central Awesome
Of all the APIs added in Snow Leopard, Grand Central Dispatch has the most far-reaching implications for the future of Mac OS X. Never before has it been so easy to do work asynchronously and to spread workloads across many CPUs.

When I first heard about Grand Central Dispatch, I was extremely skeptical. The greatest minds in computer science have been working for decades on the problem of how best to extract parallelism from computing workloads. Now here was Apple apparently promising to solve this problem. Ridiculous.

But Grand Central Dispatch doesn't actually address this issue at all. It offers no help whatsoever in deciding how to split your work up into independently executable tasks—that is, deciding what pieces can or should be executed asynchronously or in parallel. That's still entirely up to the developer (and still a tough problem). What GCD does instead is much more pragmatic. Once a developer has identified something that can be split off into a separate task, GCD makes it as easy and non-invasive as possible to actually do so.

The use of FIFO queues, and especially the existence of serialized queues, seems counter to the spirit of ubiquitous concurrency. But we've seen where the Platonic ideal of multithreading leads, and not it's a pleasant place for developers.

One of Apple's slogans for Grand Central Dispatch is "islands of serialization in a sea of concurrency." That does a great job of capturing the practical reality of adding more concurrency to run-of-the-mill desktop applications. Those islands are what isolate developers from the thorny problems of simultaneous data access, deadlock, and other pitfalls of multithreading. Developers are encouraged to identify functions of their applications that would be better executed off the main thread, even if they're made up of several sequential or otherwise partially interdependent tasks. GCD makes it easy to break off the entire unit of work while maintaining the existing order and dependencies between subtasks.

Those with some multithreaded programming experience may be unimpressed with the GCD. So Apple made a thread pool. Big deal. They've been around forever. But the angels are in the details. Yes, the implementation of queues and threads has an elegant simplicity, and baking it into the lowest levels of the OS really helps to lower the perceived barrier to entry, but it's the API built around blocks that makes Grand Central Dispatch so attractive to developers. Just as Time Machine was "the first backup system people will actually use," Grand Central Dispatch is poised to finally spread the heretofore dark art of asynchronous application design to all Mac OS X developers. I can't wait.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13

[Gast]

Apple hat die User-Space-Implementierung von Grand Central Dispatch (GCD) aus MacOS X 10.6 als Open Source freigegeben. Mit GCD sollen Entwickler die Vorteile von Multikernprozessoren einfacher ausreizen können.

http://www.golem.de/0909/69764.html

[Ganon]

Nicht zu vergessen, dass sie Blocks als C/C++ Standard vorgeschlagen haben

[Coda]

Wird aber kaum durchkommen, weil C++0x schon Lambdas hat und Apple dafür einen völlig anderen Syntax verwendet.

Ich frag mich ernsthaft wie sie das überhaupt in GCC gemerged bekommen haben.

[Ganon]

Ich frag mich ernsthaft wie sie das überhaupt in GCC gemerged bekommen haben.

Apple verwendet noch GCC 4.2 aus LLVM. Und spätestens in 10.7 nutzen sie voraussichtlich sowieso LLVM/Clang. Afaik ist Clang bei ObjC sogar schon Standard-Einstellung. Hat ja auch diverse Vorteile gegenüber GCC.

Mein SnowLeopard ist leider noch nicht gekommen....

[Coda]

Dann wundere ich mich eben wie sich das in LLVM verirren konnte. Weil eigentlich ist es ein riesen Witz.

C++0x hat den sehr viel besseren Vorschlag für Lambdas. Aber anstatt sich an irgend welche Sachen zu halten macht Apple mal wieder seinen eigenen Brei. Dolles Ding.

[Gast]

Aber anstatt sich an irgend welche Sachen zu halten macht Apple mal wieder seinen eigenen Brei.
Stimmt in einigen Dingen aber allgemein gesprochen ist das doch schwer übertrieben, z.B. h.264, AAC, Webkit, ... naja ziemlich OT.

[Coda]

Sie sind nicht so schlimm wie Microsoft. Aber fast.

[Ganon]

C++0x hat den sehr viel besseren Vorschlag für Lambdas. Aber anstatt sich an irgend welche Sachen zu halten macht Apple mal wieder seinen eigenen Brei. Dolles Ding.

Naja, sie brauchten halt auch was für C und Objective-C. Weiß nicht inwieweit da C++0x seine Vorschläge hat, darum kann ich da nicht mitreden.

Und etwas zum Standard vorschlagen heißt ja nicht, dass man nicht noch was dran machen kann ;)

[Gast]

Its more than a threadpool, but I don't if its as big of a deal as it has been made out to be... It needs a few months as least so that the tires can get kicked so to speak.

Anyway, how it is different from a .net threadpool:

1. It isn't a class instantiated in your code. It is an always running background daemon.
2. It knows the topology of the machine it is running on, i.e. how many sockets and cores are available. The primary benefit of this is that you do not have to configure the size of the pool - you just let it handle that itself.
3. In the traditional threadpool approach each application manages its own (probably differing) implementation of a threadpool, and since they do not know of each others existence they often don't have enough information to make the best decisions for the system as a whole. GC is a global threadpool, and as such it has a much broader view of the system and can therefore make better decisions.
4. It is designed to execute closures (Apple calls them blocks, same thing). While this is a restriction, some people consider it a good one because it eliminates a lot of potential blocking issues.
5. Its completely dynamic and requires no pre-planning. By that I mean your code does not (and by definition should not) be concerned with how many threads will be needed or even if your code will actually end up running in parallel or synchronous.
5. It supports FIFO queuing (not unique, but not a common attribute of most threadpool implementations)
6. As I understand it (I may be wrong) it appears to be a M:N threading model, i.e. userspace threads. As such, the GC "threads" themselves are very lightweight.

The bad (or at least potentionally bad):
1. For other platforms, if it gets adopted, it is unclear at this point how things would work, since it requires support for closures, and there are no existing C compilers (besides Apples) that support closures.
2. I may or may not be possible to use it from VM based langauges (i.e. .net, java), but frankly for those types of environments it doesn't make all that much sense either. You would probably want something like it implemented within the VM, it makes more sense there.

In my opinion, it seems like a pretty solid system (at least on paper). I think the main attraction is going to be in using it for hiding blocking behavior in UI applications, i.e. pushing code that might block the main UI thread off to the background. I don't see it as a replacement for a threadpool exactly, there are probably times you want to have application control of thread count and such... But I think its simplicity will attract a lot of users, at least on OSX. Whether it will catch on for other platforms is hard to say.
http://www.osnews.com/permalink?383495

[(del)]

Apple verwendet noch GCC 4.2 aus LLVM.So wirklich wundert mich das nicht. Es gibt immerwieder komische "Krücken" in neueren GCC-Versionen. Ich hab mich mit dem Updaten auch erstmal zur Ruhe gesetzt und schon vor langem downgradet. Das Gefuchtel ist mir momentan zu hektisch und die QS schlecht.

Bei den Sachen die ich mir für x86 selbst zusammenbacke (Winsources wie auch Linux) hab ich die besten Ergebnisse weitgehend auch "immernoch" mit 4.2.4.

Die Alarmglocken leuteten hier zuerst als mal 4.4-20081017 gegenüber dem 4.4-20080822 schon recht grausam absackte. Die Goodies nutzen mir oft nur wenig gegenüber dem schlechteren/langsameren Code.

[Ganon]

Naja, hauptsächlich liegt es wohl daran, dass GCC ab Version 4.3 unter GPL V3 steht, soweit ich das noch in Erinnerung habe.

Aber die Arbeiten an LLVM und Clang begannen ja schon weit vorher. Diese (auch LLVM mit GCC-Frontend) erzeugen auch jetzt schon weit besseren Code als der GCC und das Projekt steht unter BSD-Lizenz.

[(del)]

Naja, hauptsächlich liegt es wohl daran, dass GCC ab Version 4.3 unter GPL V3 steht, soweit ich das noch in Erinnerung habe.Da ich mir vor kurzem 4.4.1 reingezogen habe kann ich dazu nur sagen: Gut für OSX-User :freak:

Ok das ist aber recht OT jetzt. Weitermachen ;)

[Gast]

http://www.heise.de/newsticker/Apple-gibt-Grand-Central-Dispatch-als-Open-Source-frei--/meldung/145239

[Coda]

Naja, sie brauchten halt auch was für C und Objective-C.
Dann brauchen sie es noch lange nicht in C++ reinpfuschen.

[Gast]

C++0x hat den sehr viel besseren Vorschlag für Lambdas.
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
Die Syntax sieht aufgeräumter aus als die geplanten Lambda-Expressions von C++0x.
Apple hat das ganze zur Standardisierung vorgeschlagen:
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1370.pdf

[Coda]

*facepalm*

Es gibt einen guten Grund, warum C++0x Lambdas so sind wie sie sind. Und nein das wird sicher nicht in den Standard aufgenommen.

http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/f6479d0d4dab8592 genau lesen.

[Gast]

http://www.heise.de/newsticker/foren/S-Re-Intel-TBB-und-Sony-libspurs/forum-165700/msg-17358803/read/

Kann mal jemand den Beitrag auseinandernehmen bzw. seine Meinung dazu sagen, für jemanden der mit der Sache nicht so firm ist?

[Coda]

Gehört zwar nicht direkt zum Thema, finde ich aber dennoch schwach:

Snow Leopard hat immer noch keine NUMA-Unterstützung. Bei den neuen Mac Pros ist das ziemlich dämlich.

[Ganon]

@Coda
Das NUMA-Thema findet sich hier: ;)
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7530439

[Gast]

FreeBSD Gets Grand Central Dispatch Port
http://www.osnews.com/story/22331/FreeBSD_Gets_Grand_Central_Dispatch_Port

[Gast]

"Es wäre vorellig, GCD als simplen Thread Pool zu betrachten. Apple ist es durch die geschickte Kombination bekannter Elemente (Thread Pool und Warteschlangen) und viel Liebe zum Detail gelungen, etwas qualitativ Neues zu schaffen."

"GCD ist damit in ähnlicher Weise gegenüber Threads qualitativ neu wie eine höhere Programmiersprache gegenüber Assembler."

c't 2009, Heft 26, S. 197.
http://www.heise.de/ct/inhalt/2009/26/194/

[Gast]

apple ist halt die beste firma :)
wenn die etwas anpackt kommt auch etwas bei raus!

[Gast]

Gratisfilm von Mac-TV: Technischer Vortrag zu Grand Central Dispatch in Snow Leopard
http://www.mac-tv.de/index.lasso?Rubrik=Filme

(selber noch nicht gesehen)

[Gast]

irgendwie peinlich das video...

was sagen die experten?

[Gast]

irgendwie peinlich das video...

was sagen die experten?

Um nur einmal zu zeigen was GCD ist und was Es macht ist es nicht schlecht.
Als Programmierer hätte mir ein konkretes Beispiel sehr gefallen.

[Ganon]

MacTV ist auch keine Experten-Seite. Das sind alles freiwillige Helfer und die werden auch nicht bezahlt dafür. Ich finde deren Einsatzvermögen schon sehr lobenswert.