5 ms·

You can easily have 1 million coroutines in-flight (my humble testing was showing that PyPy Stacklet on i4980hq has speed around 10-20 million switches/per seco

You can easily have 1 million coroutines in-flight (my humble testing was showing that PyPy Stacklet on i4980hq has speed around 10-20 million switches/per second/per core). While with native threads I think it's in ballpark of hundred running threads, maybe single digit thousands. After that it looks like performance degrades too much. But it all depends on an usecase, spawning a thread per user in a webserver would be slower than thread per core.

charliesome 8y ago
Hundreds of thousands of OS threads is viable on Linux. There's a couple of gotchas - you need to tweak the max pid and max memory map limits, but otherwise this is an approach that works just fine.
akvadrako 8y ago
This is wrong. 1 million threads is doable, though 4 million is the max Linux supports. Coroutines are basically just user-space threads, so they scale the same way. You need to keep around a stack for each and swap it in and out of cache. See for example: https://stackoverflow.com/questions/1900165/how-long-does-it-take-to-create-1-million-threads-in-haskell https://stackoverflow.com/questions/1900165/how-long-does-it...
- amelius 8y ago
  > Coroutines are basically just user-space threads Except you don't have preemption, so you may get e.g. latency issues.
  - coldtea 8y ago
    Whereas with threads you don't get latency issues?
    - amelius 8y ago
      With threads, latency problems are spread out more evenly by design.
      - blattimwind 8y ago
        Ah well, experience tells us that scheduling latency under load with Linux is a difficult topic.
        deleted 8y ago
        [deleted]
- srean 8y ago
  Its possible now, with current hardware and address space size. With coroutines you could to that 15 years ago on 32 bit machines. > so they scale the same way The difference is the within user space context switch vs kernel space/user space context switch.
- AHTERIX5000 8y ago
  Just microbenchmarking thread creation is different case, the issue is usually letting OS scheduler to decide what to run and when while coroutines give you explicit access. Coroutines are quite a different thing than OS-level schedulable entities.

charliesome 8y ago

Hundreds of thousands of OS threads is viable on Linux. There's a couple of gotchas - you need to tweak the max pid and max memory map limits, but otherwise this is an approach that works just fine.

akvadrako 8y ago

This is wrong. 1 million threads is doable, though 4 million is the max Linux supports. Coroutines are basically just user-space threads, so they scale the same way. You need to keep around a stack for each and swap it in and out of cache. See for example: https://stackoverflow.com/questions/1900165/how-long-does-it-take-to-create-1-million-threads-in-haskell https://stackoverflow.com/questions/1900165/how-long-does-it...

amelius 8y ago
> Coroutines are basically just user-space threads Except you don't have preemption, so you may get e.g. latency issues.
- coldtea 8y ago
  Whereas with threads you don't get latency issues?
  - amelius 8y ago
    With threads, latency problems are spread out more evenly by design.
    - blattimwind 8y ago
      Ah well, experience tells us that scheduling latency under load with Linux is a difficult topic.
      - deleted 8y ago
        [deleted]
srean 8y ago
Its possible now, with current hardware and address space size. With coroutines you could to that 15 years ago on 32 bit machines. > so they scale the same way The difference is the within user space context switch vs kernel space/user space context switch.
AHTERIX5000 8y ago
Just microbenchmarking thread creation is different case, the issue is usually letting OS scheduler to decide what to run and when while coroutines give you explicit access. Coroutines are quite a different thing than OS-level schedulable entities.