On 7 December 2011 19:31, Jürgen Hestermann <juergen.hestermann@...> wrote:
> compression. There is no need to have a *real* random number in this case. I
> always wondered, why this program reported slightly faster network transfer
> in Delphi than in Lazarus/FPC but now I now why. Here it is a bad thing that
I just found another slow-down case in my code too. I have a data
generator that uses Random() for various things. I generate a few
million records of data to stress test our application. I always
thought the slowness was due to the data being stored on a RDBMS, but
some testing revealed that a large portion of the time taken to
complete the task is actually the numerous calls to Random(), not
solely the data storage as I always suspected.
Apparently XorShift can generate 125 million random numbers per second
[see url and page 5] - that's if I understood the technical paper
correctly, and not sure what machine they used for the test.
--- http://www.jstatsoft.org/v08/i14/paper
> A completely different thing is statistics. Then you realy need a good
> random() function. In this case the quality of the numbers is much more
> important than speed.
Exactly. There are multiple cases for using random numbers. The
average Joe does care too much about the quality of the numbers.
Allowing FPC to have multiple random number generators - via two or
more different functions, or a plugable generator - does seem like a
good solution. I would suggest the default Random() call uses a higher
speed performance generator though, and not the MT one.
--
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
