3 ms·

Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that wan

Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.

kbenson 9y ago
I was referring two your second paragraph but had missed your reference to the OP, which makes it obvious what you are trying to say.
- joosters 9y ago
  Sorry if I wasn't very clear. I'm kind of arguing against one side of M:N language automation, and for the other side of it.
raiph 9y ago
i.e. SIMD i.e. something like: @array = 1, 2 ... 1,000,000 ; @array>>++ ; where the `>>++` operation increments each of a million integers with the workload distributed across multiple real CPUs?
- joosters 9y ago
  Yes, or perhaps more generally, any loop where the compiler/runtime can infer that each iteration of the loop is independent of the others, and so they could theoretically run on multiple cores. It's SIMD, exactly as you say, but potentially on much larger blocks of code than single arithmetic operations. A compiler that can pick where to use SIMD is doing the same kind of analysis. The difficulty in doing it at compile time is knowing whether or not it will be worth the cost. In your example, the compiler could see that the array has a million entries and so spreading the work across threads might be a win. But in general, the compiler probably can't tell roughly how many iterations a loop is going to have, so it doesn't know where to thread and where not to.
  - raiph 9y ago
    Right. In P6 (potential) parallelism is explicit. You have to use an explicit construct such as the `<<` or `>>` meta operators. I used a simple arithmetic operation but it can be any code. Of course, it had better be parallel safe. The code-gen at compile time makes an AOT call on whether to attempt parallelization. If the JIT thinks that's not working out during a particular run it may decide to de-optimize. > more generally, any loop where ... each iteration of the loop is independent of the others Right. The `<<` and `>>` meta operators aren't the only relevant features. For example there's a `.race` method that not only (potentially) parallelizes a map, grep or whatever, but provides further explicit control such as batching size.

Not really - no :N (green threads/co-operative multitasking) needed here. It's one task that wants to use multiple real CPUs, instead of multiple tasks that want to use one CPU.

kbenson 9y ago

I was referring two your second paragraph but had missed your reference to the OP, which makes it obvious what you are trying to say.

joosters 9y ago
Sorry if I wasn't very clear. I'm kind of arguing against one side of M:N language automation, and for the other side of it.

raiph 9y ago

i.e. SIMD i.e. something like: @array = 1, 2 ... 1,000,000 ; @array>>++ ; where the `>>++` operation increments each of a million integers with the workload distributed across multiple real CPUs?

joosters 9y ago
Yes, or perhaps more generally, any loop where the compiler/runtime can infer that each iteration of the loop is independent of the others, and so they could theoretically run on multiple cores. It's SIMD, exactly as you say, but potentially on much larger blocks of code than single arithmetic operations. A compiler that can pick where to use SIMD is doing the same kind of analysis. The difficulty in doing it at compile time is knowing whether or not it will be worth the cost. In your example, the compiler could see that the array has a million entries and so spreading the work across threads might be a win. But in general, the compiler probably can't tell roughly how many iterations a loop is going to have, so it doesn't know where to thread and where not to.
- raiph 9y ago
  Right. In P6 (potential) parallelism is explicit. You have to use an explicit construct such as the `<<` or `>>` meta operators. I used a simple arithmetic operation but it can be any code. Of course, it had better be parallel safe. The code-gen at compile time makes an AOT call on whether to attempt parallelization. If the JIT thinks that's not working out during a particular run it may decide to de-optimize. > more generally, any loop where ... each iteration of the loop is independent of the others Right. The `<<` and `>>` meta operators aren't the only relevant features. For example there's a `.race` method that not only (potentially) parallelizes a map, grep or whatever, but provides further explicit control such as batching size.