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.
Multicore Enhancements!! :) (Score:5, Interesting)
Re:Multicore Enhancements!! :) (Score:1, Interesting)
That sounds like marketing-speak. That's the whole point of preemptively scheduled native threads.
GCD-enabled programs can automatically distribute their work across all available cores
Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just
and away you go. In fact, I spent an hour one day writing some C to automatically multi-thread those embarrassingly parallel array operations.
man 3 pthread_create - the world is your lobster.
Re:OpenMP (Score:3, Interesting)
it seems like the ability to share work across machines, not just cores, would be a critical difference.
Re:No because they are different (Score:4, Interesting)
This is what most people talk about, and what is most obvious from the name, but it is not the interesting part of GCD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads. This is only useful because OS X has horrendous per-thread overhead. On Linux, for instance, the correct answer is usually to create as many threads as you have parallel tasks and let the OS scheduler sort it out. Other operating systems (Solaris, Windows) have caught up to Linux on this front, but apparently not OS X. If you can get the overhead of OS threads down to an acceptable level, it is always better to avoid multiple layers of scheduling.
Re:No. Really? (Score:2, Interesting)
So any modifications to ZFS that they included in their shipped product had to be distributed? GEEE THANKS FOR THAT APPLE and isnt webkit based on khtml?
Re:They should use clang instead of GCC (Score:3, Interesting)
why won't gcc take the patches?
They are not mini-stallmans. They are Apple Haters (Score:5, Interesting)
It's a win/win, but the mini-Stallmans will never see it that way.
To the contrary: I am a huge fan of Stallman's philosophy and see Apple's work as win/win.
The people that are complaining are the looney Apple Haters, who try and find any point possible by which to attack Apple - never realizing until it is to late the latest position they are attacking from makes no sense.
Please do not taint all those of us who respect the GPL with the same brush the Haters paint themselves in corners with.
Comment removed (Score:4, Interesting)
Re:Multicore Enhancements!! :) (Score:1, Interesting)
It is not the context switch that is the bottleneck for the performance. Dependencies are. I give you an easy example. Assume you have 2 Cores and 4 tasks. Two tasks, lets call them A and B, are trivially parallel. They don't depend on anything and they are no requirement for anything. And then there is task D that depends on task C. Assume all tasks need the same time t and context switches are for free.
You would just throw A, B and C at the processor at the same time, because you say number of threads doesn't cost much. Because D depends on C you will start this after C is finished (probably in the same thread, but that is not important here). Because there are only 2 cores the 3 starting tasks are finished after 3/2 t. After that D is started and needs another t. So the sum of time is:
5/2 t
Now we make a slightly smarter aproach. We use a central manager and we tell him all the tasks at the beginning and we tell him about the dependencies. The manager also knows about the number of cores. Let's assume we have implemented a quite trivial heuristic: the priority of a task equals the number of tasks that depend on it (higher priority means it is scheduled earlier).
So the manager would schedule task C first, and because another core is available he schedules task A and doesn't schedule B because there is no capacity for it (w.l.o.g.). After time t C and A are finished and the manager schedules B and D. Their computation takes another t. So the total processing time is:
2 t < 2.5 t
Re:They should use clang instead of GCC (Score:3, Interesting)
It goes further and deeper(and uglier) than that. Remember when Apple released the G5's? Apple actually submitted patches to GCC, but they were declined, with GCC's official stance being "It would reduce GCC's portability". However, a few weeks later, IBM submitted some patches for GCC, that were summarily accepted. IBM's patch package contained many of Apple's patches for GCC.