Why is Random(255) some 529x slower compared to Delphi 7?

classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
Hi,

I'm busy working on some of the remaining unit tests for the tiOPF
project that doesn't run 100% to my satisfaction yet under FPC
(compared to Delphi 7). One of the tests is for a Simple Encryption
algorithm implemented in tiOPF, that runs extremely slow under FPC
2.4.x (and 2.6.0-rc), and near instant under Delphi 7. I'm trying to
figure out why.

Below is a snippet of code I tracked down which contains the slowdown.
The problem under FPC lies with line 08, and more specifically the
call to Random(255). Simply replacing the Random(255) call with a
variable speeds up the loop by some 529 times!

I did a simple GetTickCount() timing around this loop. Delphi executes
the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks!!!! The outer
loop runs 200400 iterations. The types for BitValue, ByteValue and
RandSeed is of type Byte.

01  for Index := 1 to Length(Source) do
02  begin
03    OrdValue := Ord(Source[Index]);
04    for BitCount := 0 to 7 do
05    begin
06      BitValue := Byte(OrdValue and (1 shl BitCount) = 1 shl BitCount);
07      RandSeed := ByteValue;
08      ByteValue := (((Random(255) + 1) div 2) * 2) + BitValue;
09      Result[(Index - 1) * 8 + BitCount + 1] := AnsiChar(ByteValue);
10    end;
11  end;

I'm using 64bit Ubuntu Linux 10.04.3 with 64-bit FPC 2.6.0-rc2.
Anybody have any ideas why the code under FPC runs so slowly? Is it
maybe some type conversion problem in FPC? I noticed that Random()
returns a Int64 on my Linux system. I'm not sure what it returns under
Delphi 7 (the docs don't say, and I can see the implementation of it).


If you wanted to test this, I attached a fully working program code
(snippets from the original tiOPF code) to demonstrate the problem.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

speedtest.pas (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

michael.vancanneyt


On Wed, 7 Dec 2011, Graeme Geldenhuys wrote:

> Hi,
>
> I'm busy working on some of the remaining unit tests for the tiOPF
> project that doesn't run 100% to my satisfaction yet under FPC
> (compared to Delphi 7). One of the tests is for a Simple Encryption
> algorithm implemented in tiOPF, that runs extremely slow under FPC
> 2.4.x (and 2.6.0-rc), and near instant under Delphi 7. I'm trying to
> figure out why.
>
> Below is a snippet of code I tracked down which contains the slowdown.
> The problem under FPC lies with line 08, and more specifically the
> call to Random(255). Simply replacing the Random(255) call with a
> variable speeds up the loop by some 529 times!
>
> I did a simple GetTickCount() timing around this loop. Delphi executes
> the loop in 20 ticks. FPC 2.6.0-rc2 takes 10585 ticks!!!! The outer
> loop runs 200400 iterations. The types for BitValue, ByteValue and
> RandSeed is of type Byte.
>
> 01  for Index := 1 to Length(Source) do
> 02  begin
> 03    OrdValue := Ord(Source[Index]);
> 04    for BitCount := 0 to 7 do
> 05    begin
> 06      BitValue := Byte(OrdValue and (1 shl BitCount) = 1 shl BitCount);
> 07      RandSeed := ByteValue;
> 08      ByteValue := (((Random(255) + 1) div 2) * 2) + BitValue;
> 09      Result[(Index - 1) * 8 + BitCount + 1] := AnsiChar(ByteValue);
> 10    end;
> 11  end;
>
> I'm using 64bit Ubuntu Linux 10.04.3 with 64-bit FPC 2.6.0-rc2.
> Anybody have any ideas why the code under FPC runs so slowly? Is it
> maybe some type conversion problem in FPC? I noticed that Random()
> returns a Int64 on my Linux system. I'm not sure what it returns under
> Delphi 7 (the docs don't say, and I can see the implementation of it).

I think the random() algorithm is simply much more complicated in FPC.
It tries very hard to get an evenly distributed random number, more so
than Delphi, probably.

Jonas Maebe implemented it, I think, he can probably shed some more light on
this.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Jonas Maebe-2

On 07 Dec 2011, at 13:51, [hidden email] wrote:

> I think the random() algorithm is simply much more complicated in FPC.

That's correct. We use the mersenne twister, Delphi probably a linear  
congruential generator. The mersenne twister has a much larger period.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
On 7 December 2011 14:54, Jonas Maebe  wrote:
>
> That's correct. We use the mersenne twister, Delphi probably a linear
> congruential generator. The mersenne twister has a much larger period.

OK thanks for the info. This is a serious performance hit, but I
understand that the FPC implementation is different. Does FPC have a
faster (comparable to Delphi) version of Random() too?

@Michael,
Should the FPC docs maybe mention the fact that the FPC version is
considerably slower that Delphi (with an explanation why of course) -
purely for the purpose of informing those porting code from Delphi to
FPC. The original code in tiOPF is so slow, I almost thought the
program froze - thus making that code really unusable in an
application. Luckily that code will normally not be used in a real app
though. Delphi developers wanting to move to FPC should really be
warned about this, and use Random() sparingly.

--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

michael.vancanneyt


On Wed, 7 Dec 2011, Graeme Geldenhuys wrote:

> On 7 December 2011 14:54, Jonas Maebe  wrote:
>>
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
>
> OK thanks for the info. This is a serious performance hit, but I
> understand that the FPC implementation is different. Does FPC have a
> faster (comparable to Delphi) version of Random() too?
>
> @Michael,
> Should the FPC docs maybe mention the fact that the FPC version is
> considerably slower that Delphi (with an explanation why of course) -
> purely for the purpose of informing those porting code from Delphi to
> FPC. The original code in tiOPF is so slow, I almost thought the
> program froze - thus making that code really unusable in an
> application. Luckily that code will normally not be used in a real app
> though. Delphi developers wanting to move to FPC should really be
> warned about this, and use Random() sparingly.

A good point.

Please add an entry in the bug tracker, or it is likely I will forget :/

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

John Lee
In reply to this post by Graeme Geldenhuys-2
Why not use the previous fpc version - I guess similar to that in delphi- I can remember an email when Jonas changed it quite a few years ago  - Jonas must have older version -  but can't really remember the fpc version - v1.0? My guess it could be found in either svn or more likely the older cvs fpc archive. 

John   

On 7 December 2011 13:10, Graeme Geldenhuys <[hidden email]> wrote:
On 7 December 2011 14:54, Jonas Maebe  wrote:
>
> That's correct. We use the mersenne twister, Delphi probably a linear
> congruential generator. The mersenne twister has a much larger period.

OK thanks for the info. This is a serious performance hit, but I
understand that the FPC implementation is different. Does FPC have a
faster (comparable to Delphi) version of Random() too?

@Michael,
Should the FPC docs maybe mention the fact that the FPC version is
considerably slower that Delphi (with an explanation why of course) -
purely for the purpose of informing those porting code from Delphi to
FPC. The original code in tiOPF is so slow, I almost thought the
program froze - thus making that code really unusable in an
application. Luckily that code will normally not be used in a real app
though. Delphi developers wanting to move to FPC should really be
warned about this, and use Random() sparingly.

--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
In reply to this post by michael.vancanneyt
On 7 December 2011 15:40,  <michael.vancanneyt@.....> wrote:
>
> A good point.
>
> Please add an entry in the bug tracker, or it is likely I will forget :/

  http://bugs.freepascal.org/view.php?id=20834

Report created with a patch. Tweak the text as you see fit.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Peter
In reply to this post by Graeme Geldenhuys-2
Graeme,

I would recommend using Marsaglia's XORShift.
Blisteringly fast, high quality statistically, and very easy to implement.

http://en.wikipedia.org/wiki/Xorshift


Regards,
Peter


On 07/12/11 13:10, Graeme Geldenhuys wrote:

> On 7 December 2011 14:54, Jonas Maebe  wrote:
>    
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
>>      
> OK thanks for the info. This is a serious performance hit, but I
> understand that the FPC implementation is different. Does FPC have a
> faster (comparable to Delphi) version of Random() too?
>
> @Michael,
> Should the FPC docs maybe mention the fact that the FPC version is
> considerably slower that Delphi (with an explanation why of course) -
> purely for the purpose of informing those porting code from Delphi to
> FPC. The original code in tiOPF is so slow, I almost thought the
> program froze - thus making that code really unusable in an
> application. Luckily that code will normally not be used in a real app
> though. Delphi developers wanting to move to FPC should really be
> warned about this, and use Random() sparingly.
>
>    

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Inoussa OUEDRAOGO
2011/12/7 Peter <[hidden email]>:
> Graeme,
>
> I would recommend using Marsaglia's XORShift.
> Blisteringly fast, high quality statistically, and very easy to implement.
>
> http://en.wikipedia.org/wiki/Xorshift

For those who want to test it here is an Object Pascal implementation.

--
Inoussa O.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

hrandom.pas (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

John Lee
How does it compare re 'randomness' cf current fpc version? The wikipedia reference doesn't make this clear. Or the original fpc/delphi versions? Jonas? 
John

On 7 December 2011 14:08, Inoussa OUEDRAOGO <[hidden email]> wrote:
2011/12/7 Peter <[hidden email]>:
> Graeme,
>
> I would recommend using Marsaglia's XORShift.
> Blisteringly fast, high quality statistically, and very easy to implement.
>
> http://en.wikipedia.org/wiki/Xorshift

For those who want to test it here is an Object Pascal implementation.

--
Inoussa O.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
In reply to this post by Peter
On 7 December 2011 15:54, Peter <peter@.....> wrote:
>
> I would recommend using Marsaglia's XORShift.
> Blisteringly fast, high quality statistically, and very easy to implement.

Thanks for the info. Like I said, the original code in tiOPF is just
an extra [sample / simple] encryption implementation. There already
exists more secure encryption implementations in tiOPF, based on DES &
Blowfish. The latter two will be used in real-world applications, and
the simple encryption not.

Either way, I'll add this to my todo list, to improve the simple
encryption - but it's a low priority item at the moment.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
In reply to this post by Jonas Maebe-2
On 7 December 2011 14:54, Jonas Maebe <jonas.maebe@....> wrote:
>
> That's correct. We use the mersenne twister, Delphi probably a linear
> congruential generator. The mersenne twister has a much larger period.

I was reading a bit more about this.  The Mersenne Twister (MT)
generator has a massive period of 2^19937−1, compared to the XorShift
generator, which in turn has a period of 2^128-1.

Most text I read mentions that MT is great for statistical purposes,
and performs well in its class.

So wouldn't it maybe make more sense to let the standard (read more
common) Random() call use a higher performance random number
generator, with a much lower period. Then add the MT generator as a
call to the Maths unit - where more statistical functions are located?

Most applications are not statistical apps, they just want a random
number here or there, so such high period low performance generator is
normally not required. Having it in the Maths unit still makes in
available when needed though - for those specialised apps.

Just a thought...

--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://fpgui.sourceforge.net
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Florian Klaempfl
Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:

> On 7 December 2011 14:54, Jonas Maebe <jonas.maebe@....> wrote:
>>
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
>
> I was reading a bit more about this.  The Mersenne Twister (MT)
> generator has a massive period of 2^19937−1, compared to the XorShift
> generator, which in turn has a period of 2^128-1.
>
> Most text I read mentions that MT is great for statistical purposes,
> and performs well in its class.
>
> So wouldn't it maybe make more sense to let the standard (read more
> common) Random() call use a higher performance random number
> generator, with a much lower period.

Well, once we thought we try to do things better than Delphi ;) Some
people, I think John Lee, asked for a better random in FPC years ago so
Jonas implemented a MT.

> Then add the MT generator as a
> call to the Maths unit - where more statistical functions are located?
>
> Most applications are not statistical apps, they just want a random
> number here or there, so such high period low performance generator is
> normally not required. Having it in the Maths unit still makes in
> available when needed though - for those specialised apps.
>
> Just a thought...
>

FPC uses MT at least for 10 years and nobody complained about
performance yet. So I suspect the cases might be very rare when random
performance matters and having good random numbers is always a good
thing ... I prefer not to change it but it's fine for me for delphi
compatibility's sake ;)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Jorge Aldo G. de F. Junior
Maybe implementing something other :

"The main advantages of the MWC method are that it invokes simple
computer integer arithmetic and leads to very fast generation of
sequences of random numbers with immense periods, ranging from around
260 to 22000000."

http://en.wikipedia.org/wiki/Multiply-with-carry

2011/12/7 Florian Klaempfl <[hidden email]>:

> Am 07.12.2011 16:03, schrieb Graeme Geldenhuys:
>> On 7 December 2011 14:54, Jonas Maebe <jonas.maebe@....> wrote:
>>>
>>> That's correct. We use the mersenne twister, Delphi probably a linear
>>> congruential generator. The mersenne twister has a much larger period.
>>
>> I was reading a bit more about this.  The Mersenne Twister (MT)
>> generator has a massive period of 2^19937-1, compared to the XorShift
>> generator, which in turn has a period of 2^128-1.
>>
>> Most text I read mentions that MT is great for statistical purposes,
>> and performs well in its class.
>>
>> So wouldn't it maybe make more sense to let the standard (read more
>> common) Random() call use a higher performance random number
>> generator, with a much lower period.
>
> Well, once we thought we try to do things better than Delphi ;) Some
> people, I think John Lee, asked for a better random in FPC years ago so
> Jonas implemented a MT.
>
>> Then add the MT generator as a
>> call to the Maths unit - where more statistical functions are located?
>>
>> Most applications are not statistical apps, they just want a random
>> number here or there, so such high period low performance generator is
>> normally not required. Having it in the Maths unit still makes in
>> available when needed though - for those specialised apps.
>>
>> Just a thought...
>>
>
> FPC uses MT at least for 10 years and nobody complained about
> performance yet. So I suspect the cases might be very rare when random
> performance matters and having good random numbers is always a good
> thing ... I prefer not to change it but it's fine for me for delphi
> compatibility's sake ;)
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Andreas Berger
In reply to this post by Florian Klaempfl
> FPC uses MT at least for 10 years and nobody complained about
> performance yet. So I suspect the cases might be very rare when random
> performance matters and having good random numbers is always a good
> thing ... I prefer not to change it but it's fine for me for delphi
> compatibility's sake ;)
Or maybe it's because no one had anything to compare it to. I have a
program that sends encrypted data every night to our data base. The
encryption part (which I wrote with random numbers) is VERY slow. I
never gave it much thought since it is running at a time where not much
else is happening. But I will look into it now.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

ik-6
In reply to this post by Florian Klaempfl
On Wed, Dec 7, 2011 at 18:35, Florian Klaempfl <[hidden email]> wrote:

FPC uses MT at least for 10 years and nobody complained about
performance yet. So I suspect the cases might be very rare when random
performance matters and having good random numbers is always a good
thing ... I prefer not to change it but it's fine for me for delphi
compatibility's sake ;)

I have a better idea.

Today FPC allow me to register different memory allocation implementation that GetMem etc will use.
The same for string and widechar etc...

Why not to add such support for randomness as well ? Allow me to register different random functions. Also might change the randomize procedure.

That way, we can use many random types according to how we wish to have it. So in one unit I can use the Delphi's version, on the other the FPC's version, and on the 3rd, something else.

On Delphi mode btw you can use by default the Delphi equivalent, and also allow compiler directive and cli tags to active/inactive such algorithms.

What do you think ?

Ido

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Peter
In reply to this post by Graeme Geldenhuys-2
I have noticed the following code in Tstrings, in the quicksort;

" Pivot := L + Random(R - L); // they say random is best "



On 07/12/11 13:10, Graeme Geldenhuys wrote:

> On 7 December 2011 14:54, Jonas Maebe  wrote:
>    
>> That's correct. We use the mersenne twister, Delphi probably a linear
>> congruential generator. The mersenne twister has a much larger period.
>>      
> OK thanks for the info. This is a serious performance hit, but I
> understand that the FPC implementation is different. Does FPC have a
> faster (comparable to Delphi) version of Random() too?
>
> @Michael,
> Should the FPC docs maybe mention the fact that the FPC version is
> considerably slower that Delphi (with an explanation why of course) -
> purely for the purpose of informing those porting code from Delphi to
> FPC. The original code in tiOPF is so slow, I almost thought the
> program froze - thus making that code really unusable in an
> application. Luckily that code will normally not be used in a real app
> though. Delphi developers wanting to move to FPC should really be
> warned about this, and use Random() sparingly.
>
>    

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Jürgen Hestermann
In reply to this post by Florian Klaempfl
Florian Klaempfl schrieb:
 > Well, once we thought we try to do things better than Delphi ;) Some
 > people, I think John Lee, asked for a better random in FPC years ago so
 > Jonas implemented a MT.

I think there are two very different approaches. I wrote a small tool
for testing network performance that simply generates a file with random
numbers. I used random() for the data because I wanted to avoid any
possible 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 the calculation of the random numbers impacts the
speed calculation. IMO the generation of numbers should be much faster
than 100 MB/s but it already delays the whole process.

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.

But now we have a fast random() function in Delphi and a statistical
good one in FPC but none of them has both.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Dimitri Smits-2
In reply to this post by Graeme Geldenhuys-2

----- "Jürgen Hestermann" <[hidden email]> schreef:


> But now we have a fast random() function in Delphi and a statistical
> good one in FPC but none of them has both.


just my 2cts, but...


The Delphi 7 help states about "function System.Random [ ( Range: Integer) ];" the following
--
In Delphi code, Random returns a random number within the range 0 <= X < Range. If Range is not specified, the result is a real-type random number within the range

0 <= X < 1.

To initialize the random number generator, add a single call Randomize or assign a value to the RandSeed variable before making any calls to Random.

Note: Because the implementation of the Random function may change between compiler versions, we do not recommend using Random for encryption or other purposes that require reproducible sequences of pseudo-random numbers.
--


I would argue that:
- using Random for encryption always was a bad idea
- you have largely incompatible implementations and expectations when you want to make code fpc+delphi7 compilable

As for other Random functions, Delphi7 also has Math.RandG (gaussian distribution around a mean) and Math.RandomRange. I would suggest the Math.RandomMT and a simpler, faster random method + good documenting.

The above Delphi-help snippet also discourages explicitly the use for encryption and other purposes. A "See also" could be used to get some statistically better distributed random numbers.

OR, what was suggested with the "pluggable" Random number generatorcall like the memorymanagers.

like I said, just my 2cts...

kind regards,
Dimitri Smits
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Why is Random(255) some 529x slower compared to Delphi 7?

Graeme Geldenhuys-2
In reply to this post by Jürgen Hestermann
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
1234