Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider) [LWN.net]

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 8:19 UTC (Mon) by njs (subscriber, #40338)
In reply to: Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider) by nix
Parent article: Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

I... still don't get it. Why would I want to system-wide run exactly as many CPU-bound threads as there are CPUs, assuming I have a half-decent kernel?

That article tries to justify it with nonsense like "if you have 8 cpus, 6 threads are running, and you start 4 threads, then those 4 threads have to spend all their time on the 2 remaining CPUs", but of course in reality all 10 threads would be scheduled across all 8 cpus, and our program with 4 threads would get a larger share of the total CPU than if it only spawned 2 threads.

If I have a big video transcode running in the background with one thread per cpu, and then I interactively apply a filter in Photoshop, I don't really want that interactive job to politely become sequential rather than step on the batch job's toes. And it's not like anything *bad* will happen if they each spawn 1 thread per CPU and then share.

Obviously if you have enough threads then at some point context switch overhead and cache effects will become overwhelming, but this is just a latency/throughput trade-off -- GCD only avoids context-switch slowdowns because it is willing to decide that some code can run now, and some will have to wait (how does it know which is which?). I already have a rich vocabulary for managing that trade-off (SCHED_IDLE/SCHED_BATCH/nice/cgroups/etc.) without reimplementing my scheduler in userspace...

to post comments

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 8:37 UTC (Mon) by dlang (guest, #313) [Link]

if you are running batch jobs that do not interact with anything then the most efficiant way to run them is also the most unfair, you pick one per core and run it to completion with no context switches at all.

now in the real world, nothing short of HPC clusters really doesn't interact with anything. even normal batch jobs need to get data from disk, at which point that thread must sit idle waiting for the disk and another thread could run instead.

don't think of this like you would a normal kernel scheduler. think of this like you would a userspace batch engine. it tries to maximize the total throughput at the expense of latency

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 12:20 UTC (Mon) by malor (guest, #2973) [Link] (3 responses)

Well, that isn't the only problem it appears to be trying to solve.

From what I can see, there seems to be four things in play here:

1. Systemic scheduling of threads for absolute maximum throughput, largely disregarding latency;
2. Thread re-use on a platform that finds them expensive to create;
3. Very, very easy integration of multicore processing into formerly single-threaded applications. This is a critical feature; with a few lines of special wrapping code, using blocks, programmers can do batch threading with little additional effort.
4. Very broad scalability. The whole concept of sharing CPUs may just go away as we keep adding more and more. At the rate things are going, we're going to have desktops with 256 cores within 10 years. If you have 256 full speed CPUs, why on earth would you even share most of them? The whole concept of a scheduler is probably going to need to be rethought soon, and GCD would appear to be one early attempt.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 20:56 UTC (Mon) by Tomislav (guest, #56442) [Link] (2 responses)

> At the rate things are going, we're going to have
> desktops with 256 cores within 10 years.

I wouldn't count on it. We are getting close to the physical boundaries in the photolithography technology so there would have to be a real revolution in the manufacturing process if this is to be. Clock speeds have remained around 2.5-3.5 GHz for a while now and it's doubtful that having more than 6-8 cores on the desktop is useful enough to offset the cost of such chips.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 23:31 UTC (Mon) by jzbiciak (guest, #5246) [Link] (1 responses)

Well, that's true if the core size stays the same and the cores stay homogeneous. GPUs already have 100s of simple cores, and stuff like OpenCL allows your multithreaded, vectorizable app to run on such a heterogeneous setup today. Technologies such as Larrabee blur this further, putting dozens of simple x86 ISA cores out there.

I think you're right that you won't see 256 i7-class CPUs in a computer. I think you're wrong that you won't see 256 application processors in a computer. You will probably have a couple beefy CPUs for the single-threaded portions, and lots of simpler processors to sop of the rest.

Apple Open Sources Snow Leopard's Grand Central Dispatch (Apple Insider)

Posted Sep 14, 2009 23:35 UTC (Mon) by jzbiciak (guest, #5246) [Link]

Errr... sop *up* the rest.