Apple's Grand Central Dispatch Ported To FreeBSD 205
bonch writes "Apple's Grand Central Dispatch, which was recently open sourced, has been ported to FreeBSD and is planned to be included by default in FreeBSD 8.1. Also known as libdispatch, the API allows the use of function-based callbacks but will also support blocks if built using FreeBSD's clang compiler package. There's already discussion of modifying BSD's system tools to use the new technology." The port was originally unveiled last month at the 2009 Developer Summit in Cambridge. Slides from that presentation are available via the Dev Summit wiki.
Re:They should use clang instead of GCC (Score:4, Informative)
No because they are different (Score:4, Informative)
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
The other two things you mentioned are ways for programs to more easily use multiple threads, but they are still threads under the main process and not centrally managed - so you have to decide blind how much of the system you can take for your threading needs.
You can compare the Blocks syntax to ways those two systems specify work units to be done in parallel, but that is just a part of the story.
Re:Multicore Enhancements!! :) (Score:2, Informative)
Ah, but the benefit of Grand Central is that you don't need to worry (as much) about thread synchronisation and message passing. Just give it the blocks of code that are independent of each other, collect the results, and you're done. Think of it as giving you a ready-made scaffold; sometimes, it's more efficient to build your own that matches your needs more closely, but usually, it's just simpler to use what's already there.
In other words, the whole point of Grand Central is that you don't need to worry as much about the "boilerplate" code around threads, and can focus more on what the code actually needs to do. This is a Good Thing. If it doesn't fit your needs, nobody is forcing you to use it ... but if it does, it makes life a hell of a lot easier.
GCD is not multithreading, it's thread management (Score:5, Informative)
Grand Central is not introducing multithreading - it's introducing comprehensive thread management. So, how many threads are you going to spin for that task? Too many, and you waste a lot of time on thread management and preemption. Too few, and you have processors sitting idle. Now how will you handle this with multiple CPU's? Multiple cores? Hyperthreading? Different cache amounts and layout? OpenCL and GPU processing? Do you know what the rest of the operating system is doing to plan appropriately?
In short, your program can at best make a stab at these issues, and possibly even do a reasonable job if you put a lot of time, effort, and profiling into it. Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
It's good stuff. And Apple gave it to the community (much like WebKit enhancements, launchd, etc).
Re:Multicore Enhancements!! :) (Score:5, Informative)
While you certainly don't deserve a "Troll" rating, the real improvement GDC brings over current implementations of concurrency is that one central authority is aware of all GDC enabled applications, and can therefore make decisions with knowledge of the entire system load and its capabilities when spinning of threads. When you spin of threads independently in each app you have to guess what the rest of the system looks like. You also have to either guess, investigate or have the user configure the general capabilities of the system.
Re:Multicore Enhancements!! :) (Score:5, Informative)
Ars Technica has a great overview [arstechnica.com] of what GCD is, and why it's important.
I haven't done much multithreaded programming in C, although this looks like an absolute godsend to those who do. Maybe someday we can actually have a modern desktop as responsive as BeOS was...
The article also contains a bit of information about Apple's compiler strategy and refinements to the C language itself. Most of these have been open-sourced under a permissive license, which is pretty damn cool.
Re:No. Really? (Score:5, Informative)
Yep, apple didn't give back all their code on WebKit, or all of Darwin, or all of launchd, or all their patches on zfs, or their code on MacPorts, or darwin streaming server, or CalDav, or iCal format, or their Calander server, or their code on their X server, or their code on ruby, or a bunch of code on smart card services...
Wait, yes they did.
Re:Multicore Enhancements!! :) (Score:3, Informative)
Re:Multicore Enhancements!! :) (Score:4, Informative)
In your zeal to take one statement out of context, you missed the point of the framework. Using dispatch queues, I don't have to create threads, an expensive operation, and I don't have to agonize over performance profiles to determine the right number of threads to use. The operating system automatically maintains a global pool of worker threads based on available system resources, and you submit an asynchronous block of code which the system will assign to a thread and run for you based on current system state--that's what the "automatically distribute their work across all available cores" part means. Quite different from merely creating a pthread. Your code will run in an optimal number of threads for the system it's on, whether it's a Mac Mini Core Solo or an eight-core Mac Pro.
You can even distribute the iterations of a for-loop across queues using dispatch_apply(). Imagine doing a lot of expensive work on items in a collection, automatically threaded for the cores of the system it's running on. Here's an intro to Grand Central Dispatch [mikeash.com]. The followup articles on the site are also recommended.
The API to submit a block for asynchronous execution is very simple:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
do_something_computationally_expensive();
});
Posting anonymously since my "bonch" account has been modbombed.
you're imagining things (Score:3, Informative)
it seems like the ability to share work across machines, not just cores, would be a critical difference.
Neither GCD nor OpenMP allow you to "share work across machines".
Re:Apple's Grand Central Dispatch Ported To FreeBS (Score:2, Informative)
On their stolen computer next to all the other things they stole from school. They even steal the flies from outside who swarm around their unwashed bodies. linux is the devolvement of humanity - a linux user is like an anti-human - taking the opposite form of what a real human should be. They do not know how to reproduce, they cannot interact with others and they long ago forgot the concept of personal hygiene. They believe communism is something we should strive for and believe klingon is a real language. yes... we know of your type.
Re:In other news... (Score:3, Informative)
That's not quite correct. There are two parts to GCD: libdispatch and the kernel support. The kernel support is MIT license, so is compatible with GPL. Besides, the kernel component wouldn't be ported anyway--it would be rewritten from scratch if one were doing GCD Linux, so the license doesn't matter.
Libdispatch is Apache license. It runs in the applications, not the kernel, so the kernel being GPLv2 is irrelevant. What's relevant are the licenses of the applications that might want to use libdispatch. Many of those will be licensed as GPLv2 or later. Those are OK, because Apache license is compatible with GPLv3.
Finally, if libdispatch were to be included as a standard part of Linux, even GPLv2 code could dynamically link to it, because it would fall under the system library exception.
Re:No. Really? (Score:4, Informative)
Re:you're imagining things (Score:3, Informative)
http://en.wikipedia.org/wiki/Xgrid [wikipedia.org]
Re:They should use clang instead of GCC (Score:2, Informative)
Because Apple is sticking with GPLv2
Re:Multicore Enhancements!! :) (Score:1, Informative)
Other posters have provided good answers, however they also miss some important aspects of GCD and repeat less interesting marketing points.
From my experience the main features of GCD are:
- It removes the need to determine how many threads should be used to execute parallel sub-tasks.
One just specifies the tasks and let the system (user-level runtime + kernel) determine how many threads should be dedicated to this work.
Many comments across the web note that this is useful across processes. In my mind the major benefit is to enable composition of parallel subdivision. In Pthread one would typically say "I have N cores, let's split this task up to to C*N threads (with C close to 1)". That's workable if you do so at high-level of the application logic, but it leads to an explosion in thread count when done in libraries. Your code may be called by M threads in parallel and, unless very careful, you can end-up creation M*C*N threads. Repeats across a few layers and you easily overwhelm the system.
With GCD you specify the work items, the serialization constraints by pushing to serial or parallel queues. The system decides how to service how to allocate threads to processes and queues.
- It brings run loops to Posix-level programming
Developing around run loops is a different programming style which is mostly familiar in UI code. GCD extends this style to low-level code. This is a very powerful programming style which, when used properly, brings similar benefits to control flow that object-oriented programming brings to data management.
- It unifies Posix-level event handling
No more sigwait / signal handler / select / poll / waitpid / blocking read() / usleep() for various event sources.
One just create dispatch sources, points them to a queue unto which to execute handlers, and voila.
GCD is not the only attempt at unification. Kqueues / epoll+signal fd + timer fd / etc. are similar/earlier attempts, and indeed GCD is built on top of kqueues on Mac OS X. What's significant with GCD is that the APIs are simple enough that they remove a lot of the traps of those other APIs. GCD also takes care of the dispatching logic which is one of the tricky aspect of dealing with those APIs.
Re:What is the deal with clang? (Score:3, Informative)
It will support C++ soon enough.
The benefits of clang are that it uses llvm as the compiler, which produces better optimized machine code than gcc currently does. Also, it supports Apple's block syntax (kind of like a pointer to a function), which allows things like libdispatch to do its magic. Also, as a C front end, it has much less cryptic error messages, and actually does a pretty good job of finding missed initializations and other hard to find bugs that usually will get caught at the code execution stage.
You should check out Siricusa's more thorough explanation at arstechnica, in his Mac OS X 10.6 Snow Leopard review. He goes into some detail to show how Apple's use of clang in the new XCode is almost "pornographic for developers..." You wouldn't have the same IDE in BSD or Linux, but the same functionality is there. Someone posted a link much higher in the thread.
-- Len
You're missing the point (Score:3, Informative)
Re:No because they are different (Score:2, Informative)
Re:No. Really? (Score:3, Informative)
Webkit is kinda special. For ages, Apple did nothing other than releasing the full source every time they released binaries.
They did _not_ release anything under SCM control, which meant tracking patches etc was _literally_ impossible for the KDE team. No matter what the KDE team did or how often they asked, this did not change. This is a large part of why KHTML and Webkit are as different as they are now. Using both KHTML and the Webkit Kpart in KDE 4.3.2, I can tell you that there are a lot of little differences in rendering and, that is where it hurts, usability. Sucks.
So while Apple followed the letter of the license, they went against its spirit in every possible way for a long time. This may have changed somewhat (iPod, iTunes...?), but one should be aware of the history.
Re:They should use clang instead of GCC (Score:5, Informative)
A massive case of NIH from the GCC team with regard to Apple. See also the patches that Apple submitted well over a year ago adding declared property support to GNU gcc. I found it easier to write all of the code required for clang to support the GNU Objective-C runtime than make even small changes to Objective-C support in GCC (in spite of not having used C++ for a few years and really hating the language).
Oh, and I've had blocks working with clang on FreeBSD for quite a while (since several months before Apple publicly released an OS supporting them, in fact). I added the required runtime library support into Etoile's ObjectiveC2 framework a while ago, which also provides the run time support for most of the Objective-C 2 features. This framework is going to go away soon, because I'm now maintaining a fork of the GNU Objective-C runtime in the GNUstep repository, which merges these improvements and also incorporates most of the ideas from my experimental Objective-C runtime library (without breaking backwards compatibility, although you don't get all of the features if you don't use the new ABI).
By the way, porting to *BSD is much easier than porting to Linux. Libdispatch is based around the kqueue mechanism for unifying kernel event sources, and there is currently no in-tree equivalent for Linux. There are four out-of-tree sets of patches providing equivalent functionality (that I know of, there may be more), as is common with Linux development. On Solaris you can do the same thing with completion ports, which are roughly semantically equivalent but have a different interface.
Re:That is more interesting but not what is differ (Score:4, Informative)
This is between one and two orders of magnitude more expensive than adding a block to a work queue with GCD.
Switching between the threads is also relatively expensive. At the very least, you need to save all of the registers and update the stack pointer (probably in response to a timer interrupt, so also factor in the cost of a transition from kernel space to users pace). With GCD, the kernel will give you one thread per CPU for each priority level (or fewer if there are already lots of CPU-bound threads), so you minimise number of context switches.
This is effectively what an N:M scheduler does, but is slightly better. With an N:M scheduler, you are switching between some threads in userspace, which saves some overhead, but the threads still have largely-disjoint working sets and so you end up with more cache churn (performance killer on modern CPUs). With GCD, you will only be switching between work queues in a given thread between blocks, so there is no cache churn (the old block's cache lines are no longer needed, so you'll kick them out but not then bring them back in immediately). The other nice side effect of this is that, because GCD knows which work queues are assigned to which threads, it can remove locks used for passing messages between work queues if both queues are in the same threads.
In short, it's an N:M threading model with preemptive kernel threads and cooperative userspace threads. If you read an OS textbook, you'll see that this is, at least in theory, about the most efficient scheduling model possible.
Re:Thank goodness for the GPL (Score:4, Informative)