Hacker News Reader

Comment by dmytroi | Hacker News Reader

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.

View on HN

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.

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...

> Coroutines are basically just user-space threads

Except you don't have preemption, so you may get e.g. latency issues.

Whereas with threads you don't get latency issues?

With threads, latency problems are spread out more evenly by design.

Ah well, experience tells us that scheduling latency under load with Linux is a difficult topic.

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.

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.

Reply on news.ycombinator.com