Apple's Grand Central Dispatch Ported To FreeBSD

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.

Comments

Bad Apple

[93 Escort Wagon]

Always taking from the open source community, and never giving back!

Multicore Enhancements!! :)

[jpedlow]

My first question was "So...what does this do?" Apparently it is a more efficient way of scheduling threads on multi-core systems http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090903.pdf apple's site says this: "Grand Central Dispatch (GCD) in Mac OS X Snow Leopard addresses this pressing need. It’s a set of first-of-their-kind technologies that makes it much easier for developers to squeeze every last drop of power from multicore systems. With GCD, threads are handled by the operating system, not by individual applications. GCD-enabled programs can automatically distribute their work across all available cores, resulting in the best possible performance whether they’re running on a dual-core Mac mini, an 8-core Mac Pro, or anything in between. Once developers start using GCD for their applications, you’ll start noticing significant improvements in performance. " So this seems good then.

Re:Multicore Enhancements!! :)

[moosesocks]

Ars Technica has a great overview 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:Multicore Enhancements!! :)

[wootest]

GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.

For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.

The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.

Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.

So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.

Re:Multicore Enhancements!! :)

[Stratoukos]

Maybe someday we can actually have a modern desktop as responsive as BeOS was...

BeOS was indeed very responsive, but it was also notoriously difficult to program for. Apple seems to have done a great job at creating a powerful framework, while keeping it easy enough to be actually used by the developers.

Re:Multicore Enhancements!! :)

[Just Some Guy]

Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just

#include <pthread.h>

and away you go.

Piece of cake! Of course, you have no idea how many other processes are tossing threads at their workload and so have no idea if this is a great time to spawn another 8 to really load out the CPU or whether you should just spawn 2 and let some other processes have their time. That's what GCD buys you.

GCD is not multithreading, it's thread management

[diamondsw]

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:In other news...

[wootest]

Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.

Re:No. Really?

[beelsebob]

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.