4 ms·

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/2

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.
      - masklinn 17y ago
        > Your Erlang example, while I'm sure it's really great for you and other Erlangers, simply doesn't do what GCD does. That's very debatable, but thank goodness it wasn't my point in the first place. My point was simply to do what cubicle67's example demonstrates, namely (in his words) > 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. That's very precisely what the Erlang example does.

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.
    - masklinn 17y ago
      > Your Erlang example, while I'm sure it's really great for you and other Erlangers, simply doesn't do what GCD does. That's very debatable, but thank goodness it wasn't my point in the first place. My point was simply to do what cubicle67's example demonstrates, namely (in his words) > 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. That's very precisely what the Erlang example does.