[erlang-questions] Fastest pseudo-random number-generator: erlang:statistics(io) ?
Tue Nov 24 19:59:49 CET 2009
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 <> 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. :)
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
More information about the erlang-questions