On FreeBASIC's random number generators.

Post your FreeBASIC tips and tricks here. Please don’t post your code without including an explanation.
Provoni
Posts: 393
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: On FreeBASIC's random number generators.

Postby Provoni » Feb 28, 2017 14:58

Tyvm deltarho[1859] for your kickass implementation, it is working now.

In my program, speedwise it is on par with FreeBASIC's option 1, 2 and 4. The quality of the randomness does not seem to matter much for my program, so I'm looking for something that is even faster (if possible).
deltarho[1859]
Posts: 2748
Joined: Jan 02, 2017 0:34
Location: UK

Re: On FreeBASIC's random number generators.

Postby deltarho[1859] » Feb 28, 2017 15:35

In my program, speedwise it is on par with FreeBASIC's option 1, 2 and 4.

That surprises me - in tests that I have done options 1, 2 and 4 have been left standing.

I wonder if your number crunching statements are very complex.

Suppose a statement took 98% of the time crunching and 2% of the time getting random numbers. If we then used a random number generator that was twice as fast then we would get 98% of the time crunching and 1% of the time getting random numbers. The time taken for the statement is now down to 99% of what it was.

Suppose now that getting random numbers was done at infinite speed. We now get the time taken for the statement down to 98% of what it was.

The difference in speed with options 1, 2, 3 and 4 when going 'flat out' is about 37% between the fastest and slowest. With your program the difference in speed is about 12%. So, your program is reducing the difference indicating complex statements.

It is possible then that a random number generator ten times faster than mine would not make very much difference to your program.

There is an analogy with reading a file to do some work on it and developing a method to do the work faster and then finding out that the 'whole' job did not improve much speed-wise; the reason being the disk read is dominant. AES128 is faster than AES256, on paper, but when encrypting a file AES128 loses it's edge.
deltarho[1859]
Posts: 2748
Joined: Jan 02, 2017 0:34
Location: UK

Re: On FreeBASIC's random number generators.

Postby deltarho[1859] » Feb 28, 2017 17:00

It is worth mentioning that once my buffers have been filled, getting a random ULong is simply a matter of reading it from RAM and is, therefore, the fastest way of getting a random ULong; unlike PRNGs which get involved in all sorts of weird and wonderful ways of generating a random ULong.

If we used a PRNG to populate a buffer then getting at it's random ULongs would also be from RAM. However, the buffer would be filled one ULong at a time requiring a call to the PRNG for each of them. Once a buffer is exhausted we could probably have a nap waiting for the next buffer to get populated. With the Windows generators they are not designed for returning one ULong at time but are designed for filling up buffers.
Provoni
Posts: 393
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: On FreeBASIC's random number generators.

Postby Provoni » Mar 01, 2017 17:02

deltarho[1859],

My program needs to call the rnd or cryptos function millions of times per second and I just figured out that the calling of the function itself seems to be causing the slowdown especially while multithreaded.

I currently have set up a weak pseudo random generated from internal values. And this increased the number of iterations my program does from 20 million to 35 million per second on a dual CPU Xeon system (24 threads).

While compiling this message popped up when using your code.

Code: Select all

AZdecrypt.asm: Assembler messages:
AZdecrypt.asm:70708: Error: incorrect register `eax' used with `q' suffix
deltarho[1859]
Posts: 2748
Joined: Jan 02, 2017 0:34
Location: UK

Re: On FreeBASIC's random number generators.

Postby deltarho[1859] » Mar 01, 2017 18:23

While compiling this message popped up when using your code.

Tell me about it.<smile>

I started a thread about that yesterday. It looks like it has manifested itself dependent upon Windows versions and FreeBASIC versions. I have been getting some very strange behaviour. My logic took a battering and I found myself in a turmoil of contradiction.

The good news is that the matter has now been resolved.

With regard 64 bit mode I am now getting, when running flat out, about 175 million random numbers per second compared with 63, 232, 149 and 232 for options 1 to 4. So, faster than option 3 but not as fast as option 2 and 4.

With regard 32 bit mode I am getting, when running flat out, about 185 million random numbers per second compared with 65, 97, 78 and 91 for options 1 to 4. In 32 bit mode then the FreeBASIC options are left standing.

In 64 bit mode, when running flat out, if I use the gcc back-end with optimization level 1 I am getting about 290 million random numbers per second making it faster than any of the FreeBASIC options. However, I need to take advice on this as I may be asking for trouble. Thanks to srvvaldez for tips on gcc and options.

I shall publish the new version of CryptoRndBuffer.bas in the next day or so.
deltarho[1859]
Posts: 2748
Joined: Jan 02, 2017 0:34
Location: UK

Re: On FreeBASIC's random number generators.

Postby deltarho[1859] » Mar 02, 2017 0:42

@Provoni

New version published - you'll find it in the same place - no stinkin' assembler error messages now.

It works fine in 64 bit mode without any additional compiler options but you may like to try -gen gcc -Wc -O1 without defining ALGO.

Have fun.

Return to “Tips and Tricks”

Who is online

Users browsing this forum: No registered users and 4 guests