http://www.perlmonks.org?node_id=1214439


in reply to Re^3: RFC: 100 PDL Exercises (ported from numpy)
in thread RFC: 100 PDL Exercises (ported from numpy)

Regarding the time difference when running with and without "use threads", I have discovered that avg() is the culprit.

Hm-m, it's not what I'm observing here. Setting $m = 30_000 and replacing avg with at(0), these are results of 3 runs without thread and in a thread:

14.9562268257141 14.9582891464233 14.8853561878204 11.9686307907104 12.0527169704437 12.0850310325623

And then replacing all 3 lines of loop block with just simple

my $y = $x-> index( sequence $n )-> at( 0 );

7.74871516227722 7.80155396461487 7.71721601486206 4.92977499961853 4.87044596672058 4.87968802452087

So I'd say it's something strange with index going on. I'm not appealing to anyone for investigation :), observable speed difference may depend very much on hardware, let it be a murky PDL mystery.

And another entertaining (but dangerous, maybe) bit of PDL trivia: above I sketched a parallelization solution with threads and random. Except, if there were more than 1 worker thread, it won't work as expected. The random documentation says Perl's srand can be used to seed, and one may assume that random relies on Perl's RNG, including it (automatically) seeds in each thread that's started. Consider:

use strict; use warnings; use feature 'say'; use threads; use PDL; PDL::no_clone_skip_warning; srand; async sub{ say random( 1 )-> at( 0 )} for 1 .. 5; $_-> join for threads-> list; say rand; __END__ 0.851411183904023 0.851411183904023 0.851411183904023 0.851411183904023 0.851411183904023 0.851411183904023

That's some randomness. Try to say rand instead. So, one must to explicitly call srand at the start of a thread, if using threads and PDL's random.