On Wed, Nov 11, 2009 at 10:22:23AM +0000, Tim Bunce wrote:
> The next version of NYTProf supports profiling some 'slow' perl opcodes.
> I've included the rand opcode for exactly this reason.

I meant srand (though rand is also included, just in case).

Though having just looked at the Configure code and relevant man pages I
realise I was misguided. You can't (easily) configure perl to use a
random function that uses /dev/random.

Tim.

> Tim.
> 
> On Tue, Nov 10, 2009 at 07:01:38PM -0800, cr...@animalhead.com wrote:
> > Many of you know that the random number generator /dev/random
> > is subject to delays when it has "not accumulated enough entropy",
> > which is to say randomness.  These delays are said to be longer
> > on Linux /dev/random that on some other Unices.  They occur
> > particularly after a system is booted, which I hear is a regular
> > occurrence on some smoke-test systems.
> >
> > But I bet many of you will be surprised by the magnitude of the
> > delays that can occur.
> >
> > Recently one perl tester's Linux system tested my module IPC::MMA
> > version 0.58, which used /dev/random to drive testing, to produce
> > report 5888084.  It took 22320 wallclock seconds to complete the
> > tests: 6.2 hours.
> >
> > A few days later the same system tested version 0.58001, which
> > differs from 0.58 mainly in using /dev/urandom which is not subject
> > to "entropy delays".  Report 5889682 shows that it took 5 wallclock
> > seconds.
> >
> > Anyway, I found it interesting,
> > Craig MacKenna
> >

Reply via email to