5 ms·

John got me incredibly excited about Grand Central Dispatch. I'm almost tempted to start tinkering with Macruby to see if I can't get that functionality without

John got me incredibly excited about Grand Central Dispatch. I'm almost tempted to start tinkering with Macruby to see if I can't get that functionality without having to relearn C.

cubicle67 17y ago
agreed. best explanation I've seen by a very long shot http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a... and http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a... Edit: you've gotta get excited when you see examples like this before: for (i = 0; i < count; i++) { results[i] = do_work(data, i); } total = summarize(results, count); after: dispatch_apply(count, dispatch_get_global_queue(0, 0), ^(size_t i) { results[i] = do_work(data, i); }); total = summarize(results, count); And there you have it: a for loop replaced with a concurrency-enabled equivalent with one line of code. No preparation, no additional variables, no impossible decisions about the optimal number of threads, no extra work required to wait for all the independent tests to complete. (The dispatch_apply() call will not return until all the tasks it has dispatched have completed.) Stunning.
- dagw 17y ago
  How does this really differ from what we've been able to do for a good while now with openMP #pragma statements?
  - Keyframe 17y ago
    It doesn't. It, hopefully, alleviates you from counting on explicit thread numbers and threadpool mamagement - offsetting those to the OS, which presumably knows better since it has a larger scope picture of what is going on in the system. Basically a threadpool as any other, but managed by the OS - not you.
- masklinn 17y ago
  <puts on nazi hat> then again, it's always been utterly trivial to do that in Erlang, just replace Results = lists:map(DoWork, data) by Results = pmap(DoWork, data) with `pmap` being implemented with 15 lines of Erlang.
  - tjogin 17y ago
    The whole point of GCD is that it is a central entity that knows how much work the entire system is doing on each individual processor core, and can adjust the number of threads accordingly. Does your Erlang example take into account the overall work the entire OS is doing on each individual processor core, adjusting the number of threads as the amount of overall work changes — or does it just take the Erlang-program's own work into account?
    - masklinn 17y ago
      > The whole point of GCD is that it is a central entity that knows how much work the entire system is doing on each individual processor core, and can adjust the number of threads accordingly. No. That's a side effect and benefit. The whole point of GCD is that it's trivial to use, therefore making it easy to benefit from multicore machines. > Does your Erlang example take into account the overall work the entire OS is doing on each individual processor core, adjusting the number of threads as the amount of overall work changes — or does it just take the Erlang-program's own work into account? In the erlang view of the world, the erlang runtime is the OS. And within that context, Erlang takes in account the overall work of itself (in fact, it more precisely doesn't give a damn: it spawns a scheduler thread per logical core -- or more or less if you ask it to -- and then dynamically maps Erlang processes on these OS threads the way GCD dispatches queued tasks to its threadpool).
      - tjogin 17y ago
        The first two letters stand for Grand Central. That's not a side-effect, it's a core purpose, without which it would not do half of what it does, nor do it half as well. While Erlangers may view the Erlang environment as the universe, it decidedly isn't, as it runs on an OS that does other things as well. Your Erlang example, while I'm sure it's really great for you and other Erlangers, simply doesn't do what GCD does.
agazso 17y ago
This is what excited me most too. It is a very similar approach than what we did in a project when we had to add multithreading later on, namely to use tasks and hierarchical queues. But with GCD, it has the knowledge of the number of cores and running threads and processes so it can allocate the whole system's resources much better. The other thing I like is how well it is integrated with other new features like blocks, OpenCL and Clang. I expect to see something similar on Linux soon, or (wishful thinking) if the GCD interface was ported to other unices so we could write portable multicore application in a sane way.
jballanc 17y ago
Since it doesn't seem anybody addressed your original suggestion of tinkering with MacRuby, it's worth noting that the MacRuby API for GCD landed on trunk 2 days ago. Happy hacking!

John got me incredibly excited about Grand Central Dispatch. I'm almost tempted to start tinkering with Macruby to see if I can't get that functionality without having to relearn C.

cubicle67 17y ago

agreed. best explanation I've seen by a very long shot http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a... and http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/13 http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a... Edit: you've gotta get excited when you see examples like this before: for (i = 0; i < count; i++) { results[i] = do_work(data, i); } total = summarize(results, count); after: dispatch_apply(count, dispatch_get_global_queue(0, 0), ^(size_t i) { results[i] = do_work(data, i); }); total = summarize(results, count); And there you have it: a for loop replaced with a concurrency-enabled equivalent with one line of code. No preparation, no additional variables, no impossible decisions about the optimal number of threads, no extra work required to wait for all the independent tests to complete. (The dispatch_apply() call will not return until all the tasks it has dispatched have completed.) Stunning.

dagw 17y ago
How does this really differ from what we've been able to do for a good while now with openMP #pragma statements?
- Keyframe 17y ago
  It doesn't. It, hopefully, alleviates you from counting on explicit thread numbers and threadpool mamagement - offsetting those to the OS, which presumably knows better since it has a larger scope picture of what is going on in the system. Basically a threadpool as any other, but managed by the OS - not you.
masklinn 17y ago
<puts on nazi hat> then again, it's always been utterly trivial to do that in Erlang, just replace Results = lists:map(DoWork, data) by Results = pmap(DoWork, data) with `pmap` being implemented with 15 lines of Erlang.
- tjogin 17y ago
  The whole point of GCD is that it is a central entity that knows how much work the entire system is doing on each individual processor core, and can adjust the number of threads accordingly. Does your Erlang example take into account the overall work the entire OS is doing on each individual processor core, adjusting the number of threads as the amount of overall work changes — or does it just take the Erlang-program's own work into account?
  - masklinn 17y ago
    > The whole point of GCD is that it is a central entity that knows how much work the entire system is doing on each individual processor core, and can adjust the number of threads accordingly. No. That's a side effect and benefit. The whole point of GCD is that it's trivial to use, therefore making it easy to benefit from multicore machines. > Does your Erlang example take into account the overall work the entire OS is doing on each individual processor core, adjusting the number of threads as the amount of overall work changes — or does it just take the Erlang-program's own work into account? In the erlang view of the world, the erlang runtime is the OS. And within that context, Erlang takes in account the overall work of itself (in fact, it more precisely doesn't give a damn: it spawns a scheduler thread per logical core -- or more or less if you ask it to -- and then dynamically maps Erlang processes on these OS threads the way GCD dispatches queued tasks to its threadpool).
    - tjogin 17y ago
      The first two letters stand for Grand Central. That's not a side-effect, it's a core purpose, without which it would not do half of what it does, nor do it half as well. While Erlangers may view the Erlang environment as the universe, it decidedly isn't, as it runs on an OS that does other things as well. Your Erlang example, while I'm sure it's really great for you and other Erlangers, simply doesn't do what GCD does.

agazso 17y ago

This is what excited me most too. It is a very similar approach than what we did in a project when we had to add multithreading later on, namely to use tasks and hierarchical queues. But with GCD, it has the knowledge of the number of cores and running threads and processes so it can allocate the whole system's resources much better. The other thing I like is how well it is integrated with other new features like blocks, OpenCL and Clang. I expect to see something similar on Linux soon, or (wishful thinking) if the GCD interface was ported to other unices so we could write portable multicore application in a sane way.

jballanc 17y ago

Since it doesn't seem anybody addressed your original suggestion of tinkering with MacRuby, it's worth noting that the MacRuby API for GCD landed on trunk 2 days ago. Happy hacking!