Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 8/28/84; site lll-crg.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!gymble!lll-crg!brooks
From: brooks@lll-crg.ARPA (Eugene D. Brooks III)
Newsgroups: net.crypt
Subject: Re: Re: Re: Why no hardware random numbers?
Message-ID: <502@lll-crg.ARPA>
Date: Sat, 6-Apr-85 02:48:25 EST
Article-I.D.: lll-crg.502
Posted: Sat Apr  6 02:48:25 1985
Date-Received: Mon, 8-Apr-85 00:25:46 EST
References: <868@utcsri.UUCP> <464@lll-crg.ARPA> <442@x.UUCP> <483@lll-crg.ARPA> <458@x.UUCP>
Distribution: net
Organization: Lawrence Livermore Labs, CRG group
Lines: 15

> Thanks to the `huge' buffer I use (20Kb on my 68000), it turns out that this
> program runs marginally faster using the disk table than when using the
> "rand()" function directly.  OBVIOUSLY, your mileage may vary, but if your

Obviously, you don't have the correct perspective on this problem.

First, I don't use a 68000 to do my Monte Carlo calculations, I use a Cray.
Hence there is very large differnce between the subroutine call used for
a 32 bit integer multiply on the 68000 and the multiply that happens every
clock on the Cray.  Then there is always the clock speed itself to account
for.  Adding up these orders of magnitude,  there are quite a few of them,
you have to consider just how long this Monte Carlo runs on the Cray.  Take
10 cpu hours for a reasonable run.  Now thats a lot of random numbers....
The disk falls quite short in throughput, the CRC table analogy is quite
appropriate, and it doesn't have enough space to hold them all anyway.