Apple Open Sources Grand Central Dispatch 342
bonch writes "Apple has open sourced libdispatch, also known as Grand Central Dispatch, which is technology in Snow Leopard that makes it easier for developers to take advantage of multi-core parallelism. Kernel support is not required, but performance optimizations Apple made for supporting GCD are visible in xnu. Block support in C is required and is currently available in LLVM (note that Apple has submitted their implementation of C blocks for standardization)." Update: 09/11 15:32 GMT by KD : Drew McCormack has a post up speculating on what Apple's move means to Linux and other communities (but probably not Microsoft): "...this is also very interesting for scientific developers. It may be possible to parallelize code in the not too distant future using Grand Central Dispatch, and run that code not only on Macs, but also on clusters and supercomputers."
GCD is task parallelism (Score:5, Informative)
RTFA (Score:5, Informative)
Introducing Blocks and Grand Central Dispatch
Concurrency Programming Guide
Grand Central Dispatch (GCD) Reference"
Re:OK, I give up...what is it? (Score:4, Informative)
There's a decent article [wikipedia.org] on wikipedia about it. Basically, it's Apple's multithreading algorithms.
Re:OK, I give up...what is it? (Score:5, Informative)
From the first paragraph:
Grand Central Dispatch (GCD) is a revolutionary approach to multicore computing that is woven throughout the fabric of Mac OS X version 10.6 Snow Leopard. GCD combines an easy-to-use programming model with highly-efficient system services to radically simplify the code needed to make best use of multiple processors. The technologies in GCD improve the performance, efficiency, and responsiveness of Snow Leopard out of the box, and will deliver even greater benefits as more developers adopt them.
libdispatch is the open source implementation of GCD.
Re:What? (Score:5, Informative)
Blocks are sections of program that can be passed around between functions as arguments. They basically allow 'functional' programming in C.
Re:OK, I give up...what is it? (Score:2, Informative)
It is operating system infrastructure that allows programmers to harness modern programmable graphics hardware and regular CPUs as a single anonymous "multi-threaded" resource.
The idea being that now GPUs are becoming double precision capable they are looking increasingly like super computers from yester-year and Grand Central Dispatch allows programmers to easily capitalise on this advance.
Re:What? (Score:2, Informative)
Blocks are the closest C will probably ever get to first-class functions. They're close enough that you can reap most of the benefits of first class functions.
Blocks and GDC (Score:5, Informative)
Blocks:
In Snow Leopard, Apple has introduced a C language extension called "blocks." Blocks add closures and anonymous functions to C and the C-derived languages C++, Objective-C, and Objective C++.
Perhaps the simplest way to explain blocks is that they make functions another form of data. C-derived languages already have function pointers, which can be passed around like data, but these can only point to functions created at compile time. The only way to influence the behavior of such a function is by passing different arguments to the function or by setting global variables which are then accessed from within the function. Both of these approaches have big disadvantages
Full Read: http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
Directly in line with blocks is Grand Central Dispatch (and this is, where blocks become really usefull):
GDC is a a technology to resolve the concurrency conundrum by giving programmers a very easy way to split tasks into multiple sub-tasks which can then be loaded onto different threads/cpu. All this also works with normal threading, but GDC makes the process far easier, with the intention to prepare OSX for future multicore machines:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12
It does so by using blocks as separate tasks:
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13
"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 it's not 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." (source = above url)
Re:What? (Score:5, Informative)
Re:OK, I give up...what is it? (Score:5, Informative)
ArsTechnica always does a pretty thorough and reasonably technical review of each OSX release, and the latest one gives a pretty good explanation of GCD as well as Blocks.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars [arstechnica.com]
The GCD stuff in particular starts on page 12, but the previous couple pages give a little bit of useful background on why it's important.
Re:OK, I give up...what is it? (Score:5, Informative)
You should check out this astounding OpenCL demo here: http://www.macresearch.org/opencl_episode1 [macresearch.org]
Re:This does not help, Apple. (Score:2, Informative)
Abstraction is the main theme in progression in programming. Blocks (Language change) and the rest of the package provide such an abstracted view.
GCD also does not need kernel changes as written in the sumary.
Re:Apache and a threading framework (Score:4, Informative)
pthreads and fork/exec are the equivalent of assembly language for parallelism compared to GCD. The API makes it easy to create anonymous methods that can be parallelized, have dependencies, be put in serial or parallel queues, etc. Then the OS implementation can prioritize at a finely-grained level based on dynamic resource availability, relative process priority, etc., on a system-wide basis. (The OS implementation of GCD was already open-sourced as part of 10.6's Darwin xnu kernel release last week.)
It's pretty nifty stuff. And it's good to see Apple continue MacOS X's tradition of openness and support of open source.
GCD -vs- OpenMP (Score:4, Informative)
It looks like GCD [wikipedia.org] is very similar to OpenMP [wikipedia.org]. I am always biased toward using an open standard, when possible. Since many compiler vendors support OpenMP, why didn't apple just implement that for Objective-C, instead of creating their own threading solution? Judging from the examples, GCD looks much cleaner and simpler. But that often comes with a price.
Re:GPL violation? (Score:5, Informative)
Well, I can see the logic of your concerns but Apple do actually seem to be fairly good at open sourcing infrastructure-related things. Sure they maintain a tight control on the user-facing stuff that makes Apple products distinctive - on the iPhone they even maintain a tight control on applications. But bear in mind they're working on an open source kernel, employ developers to work on the LLVM compiler (open source), open sourced an init-ish daemon (launchd) they developed, etc etc. On stuff that's "for geeks" they seem fairly enlightened wrt open source.
It's quite surprising from a company like Apple but the fact that they manage to make surprising decisions like that looks like a strong technical management team at work, to me.
Re:Use Cilk (Score:5, Informative)
GCD is designed for small, short-running blocks of code. Read the Ars article on Snow Leopard for examples. Naturally, it will also handle longer-running threads gracefully.
Whoever modded you informative is as ignorant as you.
Re:This does not help, Apple. (Score:3, Informative)
Note that OpenMP is supported in Mac OS X, and has been for a while. It's just not as user-friendly, you have to think a lot more about variable scope and dependencies.
With Grand Central Dispatch, you basically only have to flip a boolean flag and it's running in parallel (in ObjC at least).
Re:Awesome! (Score:5, Informative)
GCD is entirely a developer technology. It's a library for crying out loud! The end-user never does anything with it.
The whole point is to make multi-processing easy for the developer.
I pity the fools who have to use the code you've written.
Wait, WHAT?! (Score:1, Informative)
libdispatch constantly references mach throughout, which is unique to OS X and would take ages to #ifdef out completely. It also makes use of features only available in GCC 4.2.x or later, which means that many older platforms are out in the cold. It also makes a ton of platform assumptions (though luckily many of these are #define'd, so they can be redefined for other platforms later, however there's plenty that isn't, and is coded specifically for Intel platform performance). Furthermore, it codes in some really weird Apple-specific things (like label names for the priority queue levels, #ifdef's for Cocoa support, other very strange code, not clean in anyone's definition).
With some significant work by an interested party, it could be made portable, but Apple didn't Open Source it with the idea that it'd immediately build on non-x86, Linux, or Windows (and in fact, it might be ages before it builds on the latter, using pthreads and functions like sysctlbyname(3) throughout). It could be portable... some day. But as it stands it's not. At all.
Re:Use Cilk (Score:5, Informative)
No, GDC is purely a "C with block extensions" API. The blocks are essentially anonymous methods you can pass directly in to functions. It's integrated at a much lower level than Objective-C, which is only used for the higher-level application framework in MacOS.
Apple open-sourced the GDC API with this announcement, block extensions to C with LLVM implementation last week, and the OS support necessary as part of the xnu kernel Darwin release for 10.6.
Re:Uh oh (Score:1, Informative)
Re:GCD -vs- OpenMP (Score:5, Informative)
GCD and OpenMP have very little in common. OpenMP is a language extension. It requires the programmer to understand what environment their program is going to run in, what variables can be shared and how, etc. GCD merely asks you to identify blocks of code that are independent and it handles parsing them out to threads, variable replication, etc. It's the difference between providing detailed blueprints of a car (the OpenMP way) and just saying "I want a car" (the GCD way). You can *almost* think of GCD as a user-friendly frontend for OpenMP.
Re:GPL violation? (Score:4, Informative)
P.S. As in interesting tidbit, you'll notice that clamAV is posted there as well. Hmm, makes you wonder.
The Key new feature of Grand central is (Score:5, Informative)
Grand central dispatch has many innovations, but the key feature it provides is that thread pooling is now handled by the OS not the program. This means that in a dynamic environment you don't have each application stepping on each other when they ask for too many threads --all total-- than the multi-core system can optimally handle. So if Mail asks for fifty threads and Firefox asks for fifty threads and CPU you are running on can realistically only handle 10 threads then GCD figures out how to manage things so you don't get a spinning beachball.
It turns out a lot of tricks were required to do this including a lot of things like just in time compiling LVM and this C-Blocks stuff, but that's way over my head.
I've been working with it in C (Score:5, Informative)
I've come to really like GCD; I haven't played with it much in Cocoa (Obj-C) but I've been moving some of the stuff I wrote a long time ago in C to use it and I think I can say that what it does is *really* *really* awesome. It helps when writing code to be run in parallel; it does is not help you in determining *what* should be done in parallel. By putting your work into queues, by way of closures (yeah, blocks, whatever...I'm sticking with the closure name), it's up to the underlying OS to determine what thread gets what work, and on what processor. Having worked with multithreaded stuff on Windows, and calling GetThreadAffinityMask or whatever it was, and being told that it's just a *hint* to the OS, which is free to ignore you, which it always did, GCD really does spread out the work evenly among my 16-proc MacPro, and then turns around and does it just as well on the dual-core mini.
I've wanted something like this for years; a really decent OS thread scheduler that divides up the work on the other processors in a sensible fashion. I was even looking into how much effort it would take to write something like this from scratch for Linux, and now I don't even have to. Sweet!
Caveats: This is in OS X only, so no iPhone GCD (at least, not yet...not really necessary until we have multi-core iPhones), and while I've lived with additions to C++ through the years (templates mostly), the idea of adding, well, anything to C seems strange, let alone something as run-time dependent as closures.
Re:GPL violation? (Score:3, Informative)
Don't forget they've contributed a lot to WebKit, which now seems to be used by every new browser that comes out.
Re:Comparisons with Other Technology? (Score:3, Informative)
That's great and all, but systems have been doing this for years. When I launch a thread on Linux I don't care where it ends up. The scheduler takes care of it. Same with Perl, pthreads, OpenMP and pretty much every other threading technology I've ever used.
What's new here?
With GCD, you don't "launch a thread". You "start a task", and how it is scheduled in a thread pool is up to the library. You don't muck around with locks, either - you define dependencies between tasks, and they're scheduled accordingly.
Why don't you just look at some examples of GCD use, and see for yourself? It really is much clearer to see the code in this case.
Microsoft has a very similar thing, by the way - Parallel Patterns Library [microsoft.com] - except that one is for C++ only, and uses C++0x lambdas rather than a (currently) proprietary C extension. But central ideas, and use patterns, are very similar.
Re:What? (Score:4, Informative)
They're an alternate implementation of lambda-like technology. Apple's Chris Lattner wrote the first public announcement on blocks and noted: "To head off the obvious question: this syntax and implementation has nothing to do with C++ lambdas. Blocks are designed to work well with C and Objective-C, and unfortunately C++ lambdas really require a language with templates to be very useful. The syntax of blocks and C++ lambdas are completely different, so we expect to eventually support both in the same compiler."
If only due to type inference, I'd prefer the syntax of C++ lambdas, but Blocks aren't half bad at what they do within the frame of the C model.
Re:The Key new feature of Grand central is (Score:5, Informative)
Re:OK, I give up...what is it? (Score:3, Informative)
What sort of explanation would you like?
A general overview for the layman? [gizmodo.com]
A more thorough overview for the OS enthusiast? [arstechnica.com]
A detailed overview from a developer's perspective? [apple.com]
Re:Excellent, but apple isn't the first! (Score:3, Informative)