4 ms·

Can someone give a quick non-marketing-speak version of what Grand Central Dispatch really does?

by far33d 17y ago

cubicle67 17y ago
something to do with phonecalls I think... Actually (and I'll hide my lack of knowledge by being vague) it's a means of making it easier for developers to create robust multicore capable software. I think.
Hoff 17y ago
GCD is an updated and up-rated scheduler for Mac OS X. The following does contain marketeering, but also has some decent technical details: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf http://images.apple.com/macosx/technology/docs/GrandCentral_...
- scott_s 17y ago
  While I'm sure the scheduler had to be changed to accommodate it, it's not primarily a new scheduler. It's really a sophisticated thread pool system implemented in the kernel and exposed to programmers through language extensions. See http://en.wikipedia.org/wiki/Thread_pool_pattern http://en.wikipedia.org/wiki/Thread_pool_pattern for the basics on the idea - which has been around for a long time.
  - far33d 17y ago
    Thanks - this makes more sense. Just a scheduler wouldn't explain how "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."
    - ajross 17y ago
      Yeah, that sounds about right. It's a thread API that relies on applications providing "blocks" of work to the OS, and transferring their arguments and results around in message queues. So if you have five applications running, each of which has 8 threads to handle the needed parallelism on a Nehalem box, you don't need 40 separate threads and their stacks. The OS just spawns 8 threads. That sounds OK, if kinda unexciting. I'd like to see some benchmarks vs. traditional threading before I commit to liking it. History is littered with cute new IPC mechanisms that didn't turn out to have the benefits promised. This sounds a lot like a combination of sysv message queues and solaris doors, neither of which managed to drive much real innovation.
      - scott_s 17y ago
        The thread pool approach allows you to exploit much finer grain parallelism than explicitly fork/joining your own threads. So, an application that makes good use of this would probably have hundreds, if not thousands, of discrete work tasks (which I normally call "units of work," but Apple calls "blocks.") What a thread pool infrastructure buys us is the separation of tasks (the bundle of information passed around the queues) from their execution context (in this case, a kernel thread). It puts a level of abstraction between what is executed and how that's executed. At the risk of belaboring a point, this is an old idea - this is traditional multithreading. Java has a library for doing it, as does C++ (in Boost). A library for this kind of parallelism was, in fact, the first C++ library, written by Stroustrup. Even the Linux kernel uses this technique internally (by which I mean it's not exposed to applications at the user level). Cilk (the MIT project that spawned the company Cilk Arts which was recently acquired by Intel) is probably the best known example of providing language-level abstractions for this technique. (I reccomend their paper "The Implemention of the Cilk-5 Multithreaded Language": http://supertech.csail.mit.edu/papers/cilk5.pdf http://supertech.csail.mit.edu/papers/cilk5.pdf) By pointing out that this is an old idea, I don't mean to denigrate what Apple has done. Execution matters, and from the looks of it, they've executed this well - they've got something working at the language and kernel level, which is non-trivial.

Can someone give a quick non-marketing-speak version of what Grand Central Dispatch really does?

by far33d 17y ago

Can someone give a quick non-marketing-speak version of what Grand Central Dispatch really does?

something to do with phonecalls I think... Actually (and I'll hide my lack of knowledge by being vague) it's a means of making it easier for developers to create robust multicore capable software. I think.

Hoff 17y ago

GCD is an updated and up-rated scheduler for Mac OS X. The following does contain marketeering, but also has some decent technical details: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf http://images.apple.com/macosx/technology/docs/GrandCentral_...

scott_s 17y ago
While I'm sure the scheduler had to be changed to accommodate it, it's not primarily a new scheduler. It's really a sophisticated thread pool system implemented in the kernel and exposed to programmers through language extensions. See http://en.wikipedia.org/wiki/Thread_pool_pattern http://en.wikipedia.org/wiki/Thread_pool_pattern for the basics on the idea - which has been around for a long time.
- far33d 17y ago
  Thanks - this makes more sense. Just a scheduler wouldn't explain how "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."
  - ajross 17y ago
    Yeah, that sounds about right. It's a thread API that relies on applications providing "blocks" of work to the OS, and transferring their arguments and results around in message queues. So if you have five applications running, each of which has 8 threads to handle the needed parallelism on a Nehalem box, you don't need 40 separate threads and their stacks. The OS just spawns 8 threads. That sounds OK, if kinda unexciting. I'd like to see some benchmarks vs. traditional threading before I commit to liking it. History is littered with cute new IPC mechanisms that didn't turn out to have the benefits promised. This sounds a lot like a combination of sysv message queues and solaris doors, neither of which managed to drive much real innovation.
    - scott_s 17y ago
      The thread pool approach allows you to exploit much finer grain parallelism than explicitly fork/joining your own threads. So, an application that makes good use of this would probably have hundreds, if not thousands, of discrete work tasks (which I normally call "units of work," but Apple calls "blocks.") What a thread pool infrastructure buys us is the separation of tasks (the bundle of information passed around the queues) from their execution context (in this case, a kernel thread). It puts a level of abstraction between what is executed and how that's executed. At the risk of belaboring a point, this is an old idea - this is traditional multithreading. Java has a library for doing it, as does C++ (in Boost). A library for this kind of parallelism was, in fact, the first C++ library, written by Stroustrup. Even the Linux kernel uses this technique internally (by which I mean it's not exposed to applications at the user level). Cilk (the MIT project that spawned the company Cilk Arts which was recently acquired by Intel) is probably the best known example of providing language-level abstractions for this technique. (I reccomend their paper "The Implemention of the Cilk-5 Multithreaded Language": http://supertech.csail.mit.edu/papers/cilk5.pdf http://supertech.csail.mit.edu/papers/cilk5.pdf) By pointing out that this is an old idea, I don't mean to denigrate what Apple has done. Execution matters, and from the looks of it, they've executed this well - they've got something working at the language and kernel level, which is non-trivial.