Am 22.09.2017 um 09:45 schrieb Vadim Lopatin:
On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
It does. But Golang uses them, too. Goroutines.
Indeed. I'm reading about them right now, and they seem to be
"multiplexed". I wonder if Vibe.d does something similar.
The fact that you've observed lower CPU usage by the D version makes
me think some kind of scheduling or thread-priority issue is the cause.
Fibers are being switched by waiting for signals/events.
Waiting blocks thread.
Timer should affect only non-blocked threads switching IMHO.
What's was the last status? Could you observe any meaningful thread scaling?
I tested on a 32-core machine a while back and could observe the
performance rising almost linearly when increasing the number of cores
(as it should). The effect is obviously smaller on a dual-core system
where the benchmark application runs on the same system, but even there
it was well visible.
If the multi-threaded version doesn't show 100% CPU usage, that would
mean that some kind of thread-blocking is happening - GC collections or
lock contention would be the likely candidates for that. The latter
shouldn't happen anymore, as everything except for the logger should be
thread-local in the latest version.
BTW, I ran Daniel's version on my dual-core notebook against wrk (Linux)
and got 75kreq/s when using runWorkerTask and ~56kreq/s when using just
a single thread, which is about what I would expect, considering that
wrk ran on the same machine.
