News for hackers. Stuff that matters.

A comment on Libaco: A fast and lightweight C asymmetric coroutine library. Parent comment

Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by dmytroi on Saturday July 14, 2018 @04:16AM (#17529373)
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.

[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by charliesome on Saturday July 14, 2018 @04:24AM (#17529392)
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.
[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by akvadrako on Saturday July 14, 2018 @05:35AM (#17529583)
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...

[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by srean on Saturday July 14, 2018 @05:44AM (#17529611)
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.

[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by AHTERIX5000 on Saturday July 14, 2018 @06:10AM (#17529677)
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.
[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by amelius on Saturday July 14, 2018 @05:42AM (#17529600)
> Coroutines are basically just user-space threads

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

[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by coldtea on Saturday July 14, 2018 @06:04AM (#17529658)
Whereas with threads you don't get latency issues?
[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by amelius on Saturday July 14, 2018 @06:16AM (#17529692)
With threads, latency problems are spread out more evenly by design.
[ Parent | on HN ]
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by blattimwind on Saturday July 14, 2018 @08:14AM (#17530008)
Ah well, experience tells us that scheduling latency under load with Linux is a difficult topic.
[ Parent | on HN ]