3 ms·

I agree that they can be too heavyweight for short-lived work. e.g. a program needs to sort a small(ish) amount of data, it would be great if the language could

I agree that they can be too heavyweight for short-lived work. e.g. a program needs to sort a small(ish) amount of data, it would be great if the language could make the sort utilise all the available cores on the machine, without the base program needing to do any kind of multi-process or multi-threading. Spinning up threads to do this kind of thing could be too slow to be of any benefit, but you could use thread pools to save on the startup costs. This is the kind of problem that OpenMP tries to solve. But for long-lived workloads, or lots & lots of tiny requests, (the OP talks about 'web-scale', whatever that is), you would be creating the processes and threads once, at startup, and then they just all keep busy with little overhead.

kbenson 9y ago
You just described M:N threading, and what's being touted in this article as good about Perl 6.
- joosters 9y ago
  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.
anonacct37 9y ago
> it would be great if the language could make the sort utilise all the available cores on the machine. I'm not sure how I feel about this, because a single program doesn't own the machine. I don't necessarily want a language to automatically use all the cores any more than I want the language to automatically use all my memory or bandwidth. I think the GOMAXPROCS approach kind of makes sense. You can spin up as many serial independent tasks as you want, and go will use up to GOMAXPROCS threads.

kbenson 9y ago

You just described M:N threading, and what's being touted in this article as good about Perl 6.

joosters 9y ago
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.

anonacct37 9y ago

> it would be great if the language could make the sort utilise all the available cores on the machine. I'm not sure how I feel about this, because a single program doesn't own the machine. I don't necessarily want a language to automatically use all the cores any more than I want the language to automatically use all my memory or bandwidth. I think the GOMAXPROCS approach kind of makes sense. You can spin up as many serial independent tasks as you want, and go will use up to GOMAXPROCS threads.