Ask HN: Do we have evidence that green threading is faster than OS threads?

I understand that green threads and fibers are much cheaper to spawn and probably make context-switching cheaper. But how much impact do they have in practice?

Let's take backend web dev as an example. The Redbean project[0] claims to be able to do 1 million requests per second using good old fork. That number is huge! That's an order of magnitude more than the number of google searches per second. Of course that only works when you're not doing any actual work, but that would mean the overhead for forking on every request is very low.

But I have no idea if the cost of context switching actually matters when you are processing a lot of threads.

AFAIK, for running web backend handling HTTP requests, the options are: - running it all sequentially - fork() - multiple OS processes - One native thread per connection - A pool of native threads - fibers and single threaded async/await - green threads

So my question is: Does anyone actually have benchmarks of an apples-to-apples comparison?

I'm aware of the recent .Net experiment, replacing the current async/await over System.Threading.Tasks with green threads[1]. In that test, green threads are slightly slower.

The Wikipedia article[2] is hilariously out of date, using benchmarks from Linux kernel 2.2. It was flagged as out of date in 2014.

I found an old HN discussion[3], but by now that's also probably out of date. It also doesn't have realistic benchmarks.

The answer is probably "it depends", but I'd still like to know if there is any good general data to guide the development of new programming languages, virtual machines, and concurrency libraries.

[0] https://redbean.dev/ [1] https://github.com/dotnet/runtimelab/issues/2398 [2] https://en.m.wikipedia.org/wiki/Green_thread#Performance [3] https://news.ycombinator.com/item?id=10229704