Forgot your password?
typodupeerror
Software BSD Apple

Apple's Grand Central Dispatch Ported To FreeBSD 205

Posted by ScuttleMonkey
from the new-toys-to-play-with dept.
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.
This discussion has been archived. No new comments can be posted.

Apple's Grand Central Dispatch Ported To FreeBSD

Comments Filter:
  • Bad Apple (Score:5, Funny)

    by 93 Escort Wagon (326346) on Friday October 16, 2009 @05:52PM (#29773419)

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

  • by jpedlow (1154099) on Friday October 16, 2009 @05:59PM (#29773495)
    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.com] 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.
    • by moosesocks (264553) on Friday October 16, 2009 @06:37PM (#29773825) Homepage

      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.

  • Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?
    • by SuperKendall (25149) on Friday October 16, 2009 @06:15PM (#29773625)

      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.

      • by norton_I (64015) <hobbes@utrek.dhs.org> on Friday October 16, 2009 @07:32PM (#29774275)

        GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).

        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.

        • 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

          True enough, but it is the part that differentiates GCD from the other frameworks and thus deserved the most explanation.

          This is only useful because OS X has horrendous per-thread overhead.

          Actually it's useful because threads on all platforms have overhead, which is why the reuse of them by GCD to run these lightweight blocks matters. It's why it's being integrated into BS

    • by jhol13 (1087781)

      How about Java? (Concurrent maps are very "cute").

    • Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?

      One thing that comes to mind immediately is that GCD uses Apple's own extension to ISO C for closures (which, IIRC, they have already submitted for standardization - though how long this may take is an interesting question), which means that GCD is usable from a plain C application.

      Parallel Patterns Library (VC++2010 analog) is a strictly C++ library, where tasks and task groups are classes. Consequently, Microsoft also extended C++ with closures for that, but rather than build their own, they simply took l

  • by jipn4 (1367823)

    It's unclear that this buys you much over OpenMP 3.0. GCD gives you a little bit more flexibility, but that's not needed in many applications, and GCD is quite inconvenient without closures.

    • Re: (Score:3, Interesting)

      it seems like the ability to share work across machines, not just cores, would be a critical difference.

    • by GrahamCox (741991)
      GCD is quite inconvenient without closures

      Except that it does have closures, only Apple prefer to call them blocks. The Cocoa APIs have been extensively revved to include many block-based enhancements to existing APIs that previously used more awkward callbacks.
  • by diamondsw (685967) on Friday October 16, 2009 @06:27PM (#29773739)

    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).

    • by mwvdlee (775178)

      Do I understand it correctly if I oversimplify it as "centralized thread pool"?

      • by wootest (694923)

        It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.

  • Can someone explain how this is different from a normal OS with kernel level threads and not userland threads? What can this do that e.g. Windows threading, native posix threading (NPTL) in Linux, etc... Is this just apple "inventing" kernel level threads or is it something new?
    • Is this just apple "inventing" kernel level threads or is it something new?

      This is Apple making optimization of threading to multiple cores and GPU's easy for developers. This is a library to take work off the shoulders of developers for making faster, more efficient programs by letting developers chunk up their app and letting the OS (which has more information) make choices for the applications as to what becomes a thread. It is not a fundamental architecture change or anything new on the level you're talking about.

    • by ceoyoyo (59147)

      It's a system of centralized thread queues combined with a nice syntax for easily creating work units to feed to those threads. Yes, bits and pieces of GCD are available in other ways but, as is usual for Apple, they've taken a bunch of existing ideas and put them together into a really nice, integrated package.

  • Awesome! They have almost reinvented lexical closures, etc. In another ten years this will be as awesome as using continuations for UI navigation in a web framework, which was done yesterday.

  • by Anonymous Coward on Friday October 16, 2009 @07:19PM (#29774161)

    Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!

    Wait... what is that? Oh, nevermind then...

    • by petrus4 (213815)

      Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!

      Wait... what is that? Oh, nevermind then...

      I have mod points, and I could have just modded this up; however, I am committed to moderation with integrity, however much I might agree with the statement being expressed.

      I will, however, simply say this.

      BSD was here before you, Richard Stallman. It will be here after you.

When in doubt, mumble; when in trouble, delegate; when in charge, ponder. -- James H. Boren

Working...