You're damn right here. First of all, I must admit that I've misinterpreted the
benchmark results (guilty). Yet, anyway, I think I know what's really happening
here. To make things really clear I ran the benchmark for all number of workers
from 1 to 9. Here is a cleaned up output:
Timing
OK... going back to the hypothesis in the OP
> The plateau is seemingly defined by the number of cores or, more correctly,
> by the number of supported threads.
This suggests that the benchmark is CPU-bound, which is supported by
your more recent observation "100% load for a single one"
Also,
Is it possible that OS caching is having an effect on the performance?
It's sometimes necessary to run the same code several times before it
settles down to consistent results.
On 12/7/18, Vadim Belman wrote:
> There is not need for filling in the channel prior to starting workers.
> First of
