I wonder what asynchronous model you are referring to that has almost zero extra overhead? AFAIK most of the async models have considerable amount of context-switches, and sometimes even too much alexn.org/blog/2017/01/30/asynchro...
Perhaps the model with very few context-switch is the event loop. simple to use but hard to utilize computation resources machine have.
Hopefully in near future we can run real benchmarks and compare the result or these 2 programming models. I don't say Fibers would be the winner, however I doubt its overhead would be significantly more than asynchronous model.
Classic Reactor pattern has very few context switches. Multithreaded implementations of this pattern also exists (Vert.x, for example).
Thanks for the link, I'll take a look deeper, but at first look seems issues described there are mostly related to particular Scala implementations.
As for performance benchmarking. There is well established benchmark - techempower.com/benchmarks/ . Simplest approach is to implement fiber-based version of this benchmark. There are several other implementations available, so it shouldn't be hard to implement another one.
Implementations which utilize asynchronous processing are already present in benchmark and usually are at the top of the list. Note, that this is not so for Akka-based implementation which suggests that something is wrong with either particular implementation or with Akka itself.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I wonder what asynchronous model you are referring to that has almost zero extra overhead? AFAIK most of the async models have considerable amount of context-switches, and sometimes even too much
alexn.org/blog/2017/01/30/asynchro...
Perhaps the model with very few context-switch is the event loop. simple to use but hard to utilize computation resources machine have.
Hopefully in near future we can run real benchmarks and compare the result or these 2 programming models. I don't say Fibers would be the winner, however I doubt its overhead would be significantly more than asynchronous model.
Classic Reactor pattern has very few context switches. Multithreaded implementations of this pattern also exists (Vert.x, for example).
Thanks for the link, I'll take a look deeper, but at first look seems issues described there are mostly related to particular Scala implementations.
As for performance benchmarking. There is well established benchmark - techempower.com/benchmarks/ . Simplest approach is to implement fiber-based version of this benchmark. There are several other implementations available, so it shouldn't be hard to implement another one.
Implementations which utilize asynchronous processing are already present in benchmark and usually are at the top of the list. Note, that this is not so for Akka-based implementation which suggests that something is wrong with either particular implementation or with Akka itself.