Grand Central Dispatch aka libdispatch is now Open Source

Edit
Delete
Tags
Autopost

Grand Central Dispatch aka libdispatch is now Open Source

Apple released the source code of one of the core technologies in Snow Leopard: http://libdispatch.macosforge.org/

This is an interesting move, as discussed at http://www.macresearch.org/grand-central-now-open-all — it will be very interesting to see whether this will lead to a wider adoption of Grand Central Dispatch beyond Mac OS.

Posted

6 responses
Like
Comment

over 2 years ago Bjoern Knafla responded:

The code for the queue workers is (currently) missing - but its great to see the mainly lock-free code for the queue and the helper structures (semaphore, etc.)!

I don't know if adoption is Apple's primary target but to get people to play around with extensions and enhancements?

Cheers,
Bjoern

over 2 years ago Manuel Chakravarty responded:

I don't know what Apple's intentions are either, but the argument that there is a lack of good infrastructure for multicore programming on unix, and hence, an opportunity to define a standard does make sense.

over 2 years ago Bjoern Knafla responded:

The clean interface and philosophy of parallelism behind GCD would be great for a standard - but there is a lot unproven with GCD:
- With more and more cores per processor there will come one point where the global parallel queue becomes a contention point.
- For performance I want to control the context of block execution a bit stricter than currently possible - for example to run certain blocks only on worker threads that belong to the NUMA node the blocks data lives on.

Though I believe that the interface of GCD can be adapted to cover these points and am experimenting with possible extensions.

Cheers,
Bjoern

over 2 years ago Manuel Chakravarty responded:

IMHO any programming model where programmers explicitly have to manage tasks/threads/work-items is limited to a small to moderate number of cores. Larger scale parallelism requires a dataparallel programming model, or at least a less intrusive approach to specifying the potential for parallel execution.

I agree with the NUMA comment.

over 2 years ago Bjoern Knafla responded:

Good point!

What do you think, will a data parallel lib use different threads than a job pool / GCD (some set of threads for pool, most set of threads for data-parallel system) or will the one be implemented in means of the other?

Oh, and I think that there is a big difference between forcing a user to use raw OS threads in contrast to steer him to think and express parallelism in tasks/jobs and dependencies between them.

over 2 years ago Manuel Chakravarty responded:

Re data parallel lib, it may well be implemented on top of a conventional thread pool, but it may require extra scheduling policy (e.g., gang scheduling) to ensure that multiple threads executing one data-parallel computation progress together. In our data-parallel array library for Data Parallel Haskell, we e.g. use such an architecture (without special scheduling for now): http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html

However, if you look at the use of GPUs for data-parallel programming (as in CUDA or OpenCL), threads are handled in an entirely different way and one reason for this is the much higher numbers of threads in the system.

Just Testing

About Me

Grand Central Dispatch aka libdispatch is now Open Source