[erlang-questions] Fastest pseudo-random number-generator: erlang:statistics(io) ?

[Jayson Vantuyl]

Is it too slow to run the result through erlang:phash/2?

This has the added bonus that phash2/2 (not hash or phash, but phash2) has a range argument, so you wouldn't have to scale the number down to list size.  It also wouldn't be a problem on a system doing very little I/O, as long as it has done some IO.  Of course, you could always toss a counter from the process dictionary (and maybe the PID) into a tuple with it, and poof "unique hash".  I haven't benchmarked it, but I'd imagine it shouldn't be too much slower, right?

For that matter, what about erlang:process_info(self(),reductions)?  Maybe it would be faster since it's only process-local data?

On Nov 24, 2009, at 7:20 AM, Dave Smith wrote:

> On Tue, Nov 24, 2009 at 8:00 AM, Thijs <thijsterlouw@REDACTED> wrote:
> 
>> benchmark results :
>> 
>> erlang:now()    288.090
>> erlang:statistics(io)   2.730.853
>> erlang:statistics(wall_clock)   280.396
>> erlang:statistics(runtime)      510.765
>> erlang:statistics(reductions)   471.688
>> erlang:statistics(context_switches)     493.851
>> random:uniform()        870.261
> 
> Off the top of my head, I have to wonder if using statistics(io) is
> going to yield sufficient pseudo-randomness for load distribution
> purposes. If you consider that most IO is likely to be a block size
> modulo 8 (for efficiency) it seems like you might get a skewed
> distribution. A simpler (and perhaps faster) approach would be to just
> maintain a counter that gets atomically incremented on each call -- a
> port driver or ETS table would suffice and have similar amounts of
> contention as the call to statistics.
> 
> My $0.02...and you know how weak the dollar has been these days. :)
> 
> D.
> 
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
> 



-- 
Jayson Vantuyl
kagato@REDACTED