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 1
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, y
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 all
There is not need for filling in the channel prior to starting workers. First
of all, 100 repetitions of SHA256 per worker makes takes ~0.7sec on my system.
I didn't do benchmarking of the generator thread, but considering that even
your timing gives 0.054sec/per string – I will most definitely
