in reply to Re: Is rand() really that slow or am I just using it wrong?
in thread Is rand() really that slow or am I just using it wrong?

Math::Random::MT is over an order of magnitude slower than the default rand function. Far superior, but much slower:

require Math::Random::MT;;

cmpthese -1,{a=>q[my $a; $a=rand() for 1..1e6],b=>q[my $a; $a=Math::Ra
+ndom::MT::rand() for 1..1e6] };;
            (warning: too few iterations for a reliable count)

  s/iter     b     a
b   1.58    --  -93%
a  0.105 1407%    --

[download]

And for picking 1 of 68 for random test data; the built-in is perfectly adequate.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^3: Is rand() really that slow or am I just using it wrong?
by mtmcc (Hermit) on Aug 08, 2013 at 23:10 UTC
    Fair point!

    My confusion came from a recent experience of using rand() to generate 50,000 unique random numbers over a range of 1 to ~3,000,000,000. It worked fine on osx and linux, but not when I tested it on windows xp, where it struggled to ~32000 unique numbers and gave up. I can see though that if the numbers don't need to be unique and are within a small range, this wouldn't be a problem.

    I still don't quite understand why this was only an issue on windows - will have to go and google it a bit more.

    In any case, thanks for the correction!

[reply]
      I still don't quite understand why this was only an issue on windows

      The default rand (from the MS CRT) only produces 15-bits of randomness. Ie. int( rand*2**15 ) produces: 0 .. 32767.

      If you multiply by a larger factor, there are gaps in the range of values produced. Eg. int( rand() * 65535 ) produces 32767 unique values: 0 .. 65535 step 2.

      Hence your problem. Used as is, it will never produce 50,000 unique values.

      It can be used to provide a greater range with a little ingenuity. This packs 8 random bytes and unpack as a quad to produce a reasonable 64-bit rand that is still quicker than the MT:

      sub myRand{ unpack('Q', pack'C8', map rand()*256, 1 ..8) / 2**64 }

undef%hash; say time; ++$hash{ int( 50000*myRand() ) } while keys %has
+h < 50000; say time;;
1376006416.04139
1376006418.40272

say ~~keys %hash;;
50000

print sum values %hash;;
543283

      [download]

      Why this sad state persists in the MS CRT is because it seen as better to keep a seriously deficient rand function for trivial purposes and thus force users to seek out/write a better one for their particular serious purposes.

      That if they added (say) the MT, then people would either fall foul of or complain that it wasn't good enough for cryptographic purposes. And if they added a cryptographically-secure PRNG, then people would decry it as too slow for Monte-Carlo simulation purposes. Etc.

      Take that as you may.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom