Apple's Grand Central Dispatch goes open source -- get at those cores, people
By Donald Melanson 
posted September 15th 2009 3:26PM
posted September 15th 2009 3:26PM
Grand Central Dispatch may not exactly be a household name to the average Apple user, but it's certainly a hot topic among developers, who may know it better as "libdispatch," and are no doubt thrilled that Apple has now made the whole thing open source. Among other things, that means developers are now able to take full advantage of multi-core processors in Snow Leopard, which obviously has some fairly big implications for applications as soon as those developers are able to get a handle on things. Know what you're doing? Just like to get in over your head? Then you can find the complete source code and other necessary information at the read link below.
[Via Slashdot]
[Via Slashdot]
gcd is just marketing fluff like things apple usually are. its a freakn thread pool! .net 1.1 had it like five years ago and even then it was not a new concept.. it doesnt "automatically" make programms paralell and it doesnt really solve paralellism problems like shared state and such. the only thing it and other thread pools to is recycle threads and thus create less overhead compared to spawning new threads all the time (an expensive process)
gcd is ok i guess and a step in the right direction.. but its easily out class by things like TPL (google it) both in terms of features and achitecture
Wow, nobody has a clue about OS X and why this is both important and sad.
To Mac Haters..
OS X has been multi-threaded and able to use multi-cores/SMP since it first shipped; however, because of the way Apple 'integrated' the MACH/BSD kernel multi-core and SMP performance was really bad if not non-existent most of the time.
MacFans....
You need to go look up Funnel Locks, and why OS X is horrid at SMP/Multi-core processing.
When Apple integrated the MACH/BSD kernel technologies for OS X based on XNU, it had a couple of serious problems that are still in OS X today.
The first one is low level kernel multi-queue/task messaging - it is what you will find people arguing about when they talk kernel technologies. Basically this means that the kernel can get bogged down handling multi-threads at the very low level where BSD and MACH interface.
Apple and the XNU project 'attempted' to fix this to an extent, but when they did, they created the second problem which is funnel locks.
So Apple basically went with the mentality, we are going to try to get OS X to multi-task at the kernel level on a SINGLE CPU at the expense of being good at handling multiple CPUs, as multi-cpu designs in 2000 were not common. And these changes were just to 'catch' up with other kernel technologies that didn't have the same queue locks at the kernel level.
So the second problem that was created by the limited queue of the kernel design 'patches' created a major hole in how OS X works on multi-processor/multi-core/SMP machines. Basically to not get confused and to get the most performance out of ONE CPU it allows applications and drivers and even the OS itself to lock CPUs.
What this means is that most of the time OS X is running on a multi-core CPU, everything is running on ONE CPU, as applications and the OS scheduler are constantly locking and unlocking the other CPUs for use.
So an 8 Core XEON based Mac running OS X often is only getting the performance of one CPU at a time, with 7 CPUs sitting idle.
This is in vast contrast to modern OSes like OpenBSD, Linux, or Windows NT, where multiple CPU threading and scheduling doesn't have these types of locks.
Truly Bing or Google "OS X Funnel Locks", and read about what OS X is doing and why is sucks.
Yet not many people outside of OS theorist/engieers or hard core OS X developers even realize this problem exists in OS X, and SADLY Apple has been shoving multi-core systems at users and charging good money for hardware that OS X cripples.
This gets even 'worse' as the new library for multi-core application development added in Snow Leopard only addresses 'new' applications built upon the new libraries, and doesn't affect the OS or existing Applications that STILL run with CPU locks and will often be limited and limiting other applications to running on one CPU at a time.
Apple should have rebuilt the OS X kernel model so that the OS and all existing applications would just automatcially take advantage of the multi-core systems without the funnel locks. But because of the rigid kernel desing of OS X, they couldn't without breaking a lot of crap and basically having to create a whole new kernel.
wasn't the problem with funnel locks addressed in 10.4?
If this is what i think it is - open sourcing something that could benefit not just OSX, but also other OS - then this is the first apple news in months, or even years that makes my opinion about apple get a bit better.
It is still pretty low, given the shit they have been doing lately, but its at least something.
And before everyone calls me *notapple*fanboy, relax, i actually am an apple user (as well as linux and MS)
1) Windows (the NT line) is one of the only desktop OSes designed from the beginning to be multi-threaded. Linux was not. OS X was not. BSD was not. BeOS of course was, but a lot of good it did them.
2) Grand Central Dispatch is catch-up for Apple, it isn't an edge. It has a couple of neat tricks, but mainly it is providing functionality that Windows has offered since Windows 2000 (i.e. thread pools) and *some* bits of what C++ 0x / VS2010 are offering. But there are notable gaps between what GCD offers and what Windows 7 offers. For instance, Windows 7 introduces user-mode scheduling, allowing the Task Parallel Library to switch threads enirely in user mode, without incurring the overhead of a context switch.
3) Historically, OS X has been downright awful for parallel programming. It's has virtually zero infrastructure for building multi-threaded apps (Oh great, I can make pthreads! Woot!). And doing so wasn't even worth it since the OS itself was not designed to run multi-threaded apps in the first few releases. If you don't know what I'm talking about, read up on the "split funnel" architecture that basically crippled multi-threaded apps until Tiger came along and finally began making multi-threading even useful on the Mac. Even then, they've spent two releases playing catch up in this area because their original OS architecture simply wasn't built with multi-core in mind.
4) Windows has been helping developers write multi-threaded apps for a long time. For almost a decade Windows has offered a native thread pool API, has included advanced and dead simple to build marshalling via COM for even longer than that, and for years now it's offered VERY simple and effective threading mechanisms in .NET. In fact, in .NET you already have lambda expressions which can be invoked on any given thread (background thread, UI thread, etc) just in like in Grand Central Dispatch. We'll have those in native C++ with VS 2010 / C++ 0x very soon.
There is literally *nothing* that Grand Central Dispatch offers that isn't already available on Windows in .NET, and nothing that won't be availible to native code developers in VS 2010.