Slashdot Mirror
Apple Open Sources Grand Central Dispatch
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."
You don't think that libdispatch will be very genial to widespread usage, as it has a lot of OS-specific calls, which is an understandable position to take. But as an alternative you offer something whose "only caveat" is that it needs an entirely different compiler to build. A compiler whose most recent activity dates from two years ago.
... How is that a superior alternative?
You are posting in a thread about the fact that Apple made their implementation open source and you are claiming vendor lock-in?
Are you one of those rabid Apple-haters we see so often around here? Or are you just amazingly stupid?
What if you're running two applications that both are capable of monopolizing all your cpu time? How will your app know that it's only going to get 50% of the available cpu time form the OS, so it should only start threads for half the cpus?
GCD decides how many threads a collection of tasks should be split across. If an app running on an 8-core machine wants to run 100 tasks, then they could be spread across anywhere from 1 to 8 threads, depending on what else is running. Since it's the OS that knows what else is running, it can make more intelligent decisions about how many threads should be running.
The question is... how is this different to Intel's Thread Building Bocks, or OpenMP, both of which are better supported and more widely available to non-Mac developers.
If I'm not mistaken the technologies are for an application.
GCD can coordinate all applications running on the same system.
I guess having their own implemntation (for the mac) makes sense, as they can integrate it throughout the OS. I don't know anything about GCD either, but could it be used in Linux to make that a more parallel-friendly OS with less developer effort, and more standardisation of parallel execution?
Theoretically yes.
Apple here is in unique position.
Most software developers care solely about their own application. Old example from the desktop. On Windows I have 7-zip archiver installed. I have dual core CPU and this 7-zip is configured to use the 2 cores. From prospective of software developers it's all what they can do: let users tell how much cores/CPUs can be used. But I also have a video encoding application installed - and also configured to use two cores. If I try to run them both in parallel, that would cause erroneous amount of context switching harming performance of both the tasks. In worst case that might make my desktop completely unresponsive. As user I'm also lazy to reconfigure every time applications how many CPUs they should use.
Apple itself now produces number of applications which can utilize multiple CPUs (iTunes audio conversion, iMovie/QuickTime/FC video conversion, etc) and obviously they run into the problem that when applications left on their own to decide how much CPU resources they should use, system would overload leading to all the effects. Requiring user to reconfigure all the applications all the time is also kind of stupid.
Since Apple is in control of the OS and applications - and their own software might suffer from the problem, they went out and implemented the solution: system-wide batch queue with a thread pool. They are still threads - local to the process - but they are scheduled on system-wide basis. You do not need to configure applications how many CPUs they should use - nor applications have to think about: they simply put tasks (to be threads) of the queue of GCD.
I'm using the 'batch queue' term because this is the closest what exists now. Though classical UNIX batch queues are different in nature: those are processes and they are executed at some unknown point of time. GCD is real-time in its nature and its threads run immediately, unlike traditional batch queues which wait for system to be idle.
All hope abandon ye who enter here.