Not sure if your test is measuring what you expect- the setup of
generating 50 x 1k strings is taking 2.7sec on my laptop, and that's
reducing the apparent effect of parllelism.
$ perl6
To exit type 'exit' or '^D'
> my $c = Channel.new;
Channel.new
> { for 1..50 {$c.send((1..1024).map( { (' '..'Z').pick } ).join);}; say now -
> ENTER now; }
2.7289092
I'd move the setup outside the "cmpthese" and try again, re-think the
new results.
On 12/6/18, Vadim Belman <vr...@lflat.org> wrote:
> Hi everybody!
>
> I have recently played a bit with somewhat intense computations and tried to
> parallelize them among a couple of threaded workers. The results were
> somewhat... eh... discouraging. To sum up my findings I wrote a simple demo
> benchmark:
>
> use Digest::SHA;
> use Bench;
>
> sub worker ( Str:D $str ) {
> my $digest = $str;
>
> for 1..100 {
> $digest = sha256 $digest;
> }
> }
>
> sub run ( Int $workers ) {
> my $c = Channel.new;
>
> my @w;
> @w.push: start {
> for 1..50 {
> $c.send(
> (1..1024).map( { (' '..'Z').pick } ).join
> );
> }
> LEAVE $c.close;
> }
>
> for 1..$workers {
> @w.push: start {
> react {
> whenever $c -> $str {
> worker( $str );
> }
> }
> }
> }
>
> await @w;
> }
>
> my $b = Bench.new;
> $b.cmpthese(
> 1,
> {
> workers1 => sub { run( 1 ) },
> workers5 => sub { run( 5 ) },
> workers10 => sub { run( 10 ) },
> workers15 => sub { run( 15 ) },
> }
> );
>
> I tried this code with a macOS installation of Rakudo and with a Linux in a
> VM box. Here is macOS results (6 CPU cores):
>
> Timing 1 iterations of workers1, workers10, workers15, workers5...
> workers1: 27.176 wallclock secs (28.858 usr 0.348 sys 29.206 cpu) @
> 0.037/s (n=1)
> (warning: too few iterations for a reliable count)
> workers10: 7.504 wallclock secs (56.903 usr 10.127 sys 67.030 cpu) @
> 0.133/s (n=1)
> (warning: too few iterations for a reliable count)
> workers15: 7.938 wallclock secs (63.357 usr 9.483 sys 72.840 cpu) @ 0.126/s
> (n=1)
> (warning: too few iterations for a reliable count)
> workers5: 9.452 wallclock secs (40.185 usr 4.807 sys 44.992 cpu) @ 0.106/s
> (n=1)
> (warning: too few iterations for a reliable count)
> O-----------O----------O----------O-----------O-----------O----------O
> | | s/iter | workers1 | workers10 | workers15 | workers5 |
> O===========O==========O==========O===========O===========O==========O
> | workers1 | 27176370 | -- | -72% | -71% | -65% |
> | workers10 | 7503726 | 262% | -- | 6% | 26% |
> | workers15 | 7938428 | 242% | -5% | -- | 19% |
> | workers5 | 9452421 | 188% | -21% | -16% | -- |
> ----------------------------------------------------------------------
>
> And Linux (4 virtual cores):
>
> Timing 1 iterations of workers1, workers10, workers15, workers5...
> workers1: 27.240 wallclock secs (29.143 usr 0.129 sys 29.272 cpu) @
> 0.037/s (n=1)
> (warning: too few iterations for a reliable count)
> workers10: 10.339 wallclock secs (37.964 usr 0.611 sys 38.575 cpu) @
> 0.097/s (n=1)
> (warning: too few iterations for a reliable count)
> workers15: 10.221 wallclock secs (35.452 usr 1.432 sys 36.883 cpu) @
> 0.098/s (n=1)
> (warning: too few iterations for a reliable count)
> workers5: 10.663 wallclock secs (36.983 usr 0.848 sys 37.831 cpu) @
> 0.094/s (n=1)
> (warning: too few iterations for a reliable count)
> O-----------O----------O----------O----------O-----------O-----------O
> | | s/iter | workers5 | workers1 | workers15 | workers10 |
> O===========O==========O==========O==========O===========O===========O
> | workers5 | 10663102 | -- | 155% | -4% | -3% |
> | workers1 | 27240221 | -61% | -- | -62% | -62% |
> | workers15 | 10220862 | 4% | 167% | -- | 1% |
> | workers10 | 10338829 | 3% | 163% | -1% | -- |
> ----------------------------------------------------------------------
>
> Am I missing something here? Do I do something wrong? Because it just
> doesn't fit into my mind...
>
> As a side done: by playing with 1-2-3 workers I see that each new thread
> gradually adds atop of the total run time until a plato is reached. The
> plato is seemingly defined by the number of cores or, more correctly, by the
> number of supported threads. Proving this hypothesis wold require more time
> than I have on my hands right now. And not even sure if such proof ever
> makes sense.
>
> Best regards,
> Vadim Belman
>
>
--
-y
