concurrency - 什么时候 "race"在Perl 6中值得？

Question

race 自动将可迭代的操作划分为多个线程。例如，

(Bool.roll xx 2000).race.sum

会自动将2000长数组的总和分为4个线程。但是， benchmarks show的速度比未使用 race的速度慢得多。这发生在 even if you make the array bigger上。
即使 non-autothreaded version gets faster and faster with each version也会发生这种情况。 ( Auto-threading also gets faster，但仍然是不使用它的速度的两倍。)

所以问题是:值得使用的原子操作的最小大小是多少？添加到顺序操作的开销是固定的还是可以某种方式减少？

更新:实际上， performance of hyper (similar to race, but with guaranteed ordered results) seems to be getting worse with time，至少对于小尺寸来说仍然是默认批处理大小(64)的整数倍。相同 happens with race

Answer 1

简短的答案:.sum不够聪明，无法批量计算总和。

因此，在此基准测试中，您实际上要做的是设置HyperSeq/RaceSeq，但不进行任何并行处理:

dd (Bool.roll xx 2000).race;
# RaceSeq.new(configuration => HyperConfiguration.new(batch => 64, degree => 4))

因此，您一直在测量 .hyper/ .race开销。您会看到，目前在 .map/ .grep上仅实现了 HyperSeq和 RaceSeq。如果您愿意做某事，例如:

# find the 1000th prime number in a single thread
$ time perl6 -e 'say (^Inf).grep( *.is-prime ).skip(999).head'
real    0m1.731s
user    0m1.780s
sys     0m0.043s

# find the 1000th prime number concurrently
$ time perl6 -e 'say (^Inf).hyper.grep( *.is-prime ).skip(999).head'
real    0m0.809s
user    0m2.048s
sys     0m0.060s

如您所见，在这个(较小的)示例中，并发版本的速度是非并发版本的2倍以上。但是会使用更多的CPU。

由于 .hyper和 .race可以正常工作，因此性能有所提高，如您所见 in this graph。

可以为 .sum/ .hyper实现其他功能，例如 .race。但是，我暂时暂不考虑这一点，因为我们需要对 .hyper和 .race的处理方式进行一些小的重构:目前，批处理无法与“主管”沟通完成工作的速度有多快。如果我们想让主管进行调整，例如，主管需要该信息。批处理大小(如果发现默认的批处理大小太小并且我们的开销太大)。