2 ms·

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

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

by far33d 17y ago

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.