Random Numbers and RNG

[Greyguy1948]

Are you interested in random numbers and random number generators?

http://www.realworldtech.com/forum/?threadid=122878&curpostid=122886

Do you remember Alfred Aburto and all benchmarks?
You one time could find them all over the net but not today.
Look att shuffle.c
You can see how bad the IBM PC regarding shuffling cards.
How much better is RDRAND?
I have no CPU yet with RDRAND but have just ordered an Athlon X4-845 (Excavator).
Has anyone tested Raspberry Pi regarding random numbers?
It should be better than IBM PC.

 

[SOFTengCOMPelec]

The RDRAND is not really a proper, completely random (hardware) instruction. It seeds itself with a 100% generated hardware random number, but does not create one for each call of RDSEED. Because it still uses pseudorandom functionality, to make the numbers.
The later (Intel and later others) instruction called 'RDSEED', is the one which creates fresh/new completely random (hardware) numbers. Each time it is called.

https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed

Summary:

RDRAND is fastest, and (hardware) sort of random but still pseudorandom based. But subsequent calls to it, use a pseudorandom technique. It only sometimes uses the full hardware random number generator, to reseed itself. For speed/performance reasons.

The slower RDSEED, always generates a fresh/new completely hardware (generated) random number each time. But as a result it can be slower.

Intel seem to prefer people to use the RDRAND instruction. But if you need 100% completely hardware generated random numbers. Then RDSEED seems better. Unless you need high/fastest speed/performance, and can accept a slight/partial potential loss in true randomness.

 

[Greyguy1948]

Thank you for your reply!

Very few tests are available on the net with RDRAND...why?
Here is one:
http://masm32.com/board/index.php?topic=2432.0

Will RDRAND+RDSEED make the error smaller in a Monte Carlo simulation?
RDSEED is interesting but only available in few CPUs yet.

How much better is the RNG in Raspberry Pi compared to the old one (1979...?) in IBM PC?

 

[SOFTengCOMPelec]

Thank you for your reply!

Very few tests are available on the net with RDRAND...why?
Here is one:
http://masm32.com/board/index.php?topic=2432.0

Will RDRAND+RDSEED make the error smaller in a Monte Carlo simulation?
RDSEED is interesting but only available in few CPUs yet.

How much better is the RNG in Raspberry Pi compared to the old one (1979...?) in IBM PC?

In general, there does not seem to be much interest (relatively) in things like RDRAND/RDSEED. Hence the relatively little information available about it, compared to other things. I bet many computer people have never heard of it, or even know what it is.

Most things will be fine, with pseudorandom number generators. So they will do fine with a decent, software pseudorandom generator or using the RDRAND instruction.

But a small number of things will benefit from a real hardware true random number generator (such as RDSEED or the one built into the raspberry pi boards hardware). Because of their pure/real mathematical properties. Especially where a huge number of iterations are involved.
I don't know if Monte Carlo simulations, would benefit or by how much, between a decent pseudorandom number generator, and a real (pure) hardware random number generator.
But suspect you might get at least a small improvement, by using a real hardware random number generator.

Because RDRAND regularly reseeds itself from a real hardware random number generator (and uses a pseudorandom, between those seed updates). It is at least "unpredictable", so can be used for computer security uses, such as encryption. Whereas a purely software based pseudorandom, would still need some method of obtaining "real" random numbers. From time to time, so that it can keep its seed, genuinly random.
Some pseudorandom number software generators do that by using the time in milliseconds (or microseconds) and mice movements and other stuff. To keep the random numbers, somewhat really random. Even though the "pseudorandom" nature of it. Still makes it partially non-random.

There are some tests available, such as "DieHard" random number checker and other, more recent ones.

https://en.wikipedia.org/wiki/Diehard_tests

As regards the original unmodified/upgraded IBM PC. I don't think it ever had a real hardware random number generator built into it. You might be referring to either purely software based pseudorandom number generators, or software which simulates a real hardware random number generator, by looking at the current time and things like mouse movements (earliest IBM PC's did not even have mice, usually, I think). To create an approximation of such a thing, but at an extremely slow data rate.
E.g. As done by some/all Unix and similar Kernels, to create entropy for random number generation.

This link explains about software pseudorandom generators:
https://en.wikipedia.org/wiki/Pseudorandom_number_generator

 

[Greyguy1948]

In general, there does not seem to be much interest (relatively) in things like RDRAND/RDSEED. Hence the relatively little information available about it, compared to other things. I bet many computer people have never heard of it, or even know what it is.

https://en.wikipedia.org/wiki/Diehard_tests

As regards the original unmodified/upgraded IBM PC. I don't think it ever had a real hardware random number generator built into it. You might be referring to either purely software based pseudorandom number generators, or software which simulates a real hardware random number generator, by looking at the current time and things like mouse movements (earliest IBM PC's did not even have mice, usually, I think). To create an approximation of such a thing, but at an extremely slow data rate.
E.g. As done by some/all Unix and similar Kernels, to create entropy for random number generation.

This link explains about software pseudorandom generators:
https://en.wikipedia.org/wiki/Pseudorandom_number_generator

Interesting indead!
I do believe they have an analog source. To read RND is a very slow process compared to all other improvement we see from IBM 4.77 MHz to the CPUs of today. But of course an ADC from 1979 was slow and had low resolution (like 4 or 8 bits). Today ADCs are fast and have high resolution. Today they often need analog sources for other needs like temperature control.

 

[Greyguy1948]

Sorry I was wrong. I cannot find any analog source in IBM PC.
The card shuffle program is using 32 bit numbers but in PCs of today 128 bit should be better.

This is interesting:
https://en.wikipedia.org/wiki/Trusted_Platform_Module
TPM modules are used on many new motherboards for example by AMD.

 

[SOFTengCOMPelec]

Sorry I was wrong. I cannot find any analog source in IBM PC.
The card shuffle program is using 32 bit numbers but in PCs of today 128 bit should be better.

This is interesting:
https://en.wikipedia.org/wiki/Trusted_Platform_Module
TPM modules are used on many new motherboards for example by AMD.

Maybe you meant 64 bit. Because up to 64 bits, can be processed extremely quickly on modern Intel/Amd cus. But 128 bits takes significantly longer, as it is no longer such a quick action. I.e. 128 bits needs a number of operations, because they can't directly process 128 bits (except using SIMD and similar instructions, which treat it as multiple lower bit numbers, in large bit sets, such as 128 or 256 bits at a time. But the numbers are still <= 64 bits, each. E.g. 4 x 64 bit numbers(SIMD) = 256 bits total length for all 4 numbers, which can be processed in one go).

tl;dr
64 bits is the max usable for a single (non-floating point, Integer number). As far as know.
But there are new instructions for handling numbers bigger than 64 bits (but they use multiple cpu cycles to work).

There have already been past cpus (X86) and motherboard chip sets, which can do full hardware random number generation. But it is only, recently when RDRAND and especially RDSEED is becoming a standard instruction, on at least some of the X86 processors from Intel and Amd.
Maybe at some point it will be standard for all, even on atom, cpus.

 

[Greyguy1948]

First of all:
Merry Xmas to all of you!

I have tested the pseudo-random generator in Excel (32bit) with 13 000 card and here is my result:
Aces=1012
2=1039
3=1032
4=968
5=955
6=987
7=976
8=1009
9=944
10=1024
jacks=1024
queens=1039
kings=991

I don't know if 64bit Excel is available. Anyhow better (more like random) should be possible!

 

[Greyguy1948]

More about TPM:
https://arxiv.org/ftp/arxiv/papers/1008/1008.2223.pdf

 

[Ken g6]

First of all:
Merry Xmas to all of you!

I have tested the pseudo-random generator in Excel (32bit) with 13 000 card and here is my result:
Aces=1012
2=1039
3=1032
4=968
5=955
6=987
7=976
8=1009
9=944
10=1024
jacks=1024
queens=1039
kings=991

I don't know if 64bit Excel is available. Anyhow better (more like random) should be possible!

Looks quite random to me. There's no reason the count for all of them should be equal; that would even be an indication of a bad PRNG. https://en.wikipedia.org/wiki/Gambler's_fallacy

 

[Greyguy1948]

No one is expecting 1000 on all cards but you have a structure here not far from what you can see in the other shuffle.c result.

 

[Greyguy1948]

More about random in Excel up to 39 000 cards with Standard Deviation:

999 1006 1033 1000 1032 979 986 1027 1024 1012 1006 961 935 1000 28
1035 1022 974 1029 958 1007 1005 1024 1023 926 973 1031 993 1000 32
998 1034 953 953 991 1024 1025 1029 1014 1009 978 984 1008 1000 26

3032 3062 2960 2982 2981 3010 3016 3080 3061 2947 2957 2976 2936 3000 46
Still SD is above 1% of AVE

 

[Greyguy1948]

Here you have plenty of info:
http://instlatx64.atw.hu/
I have found RDRAND in two AMD CPUs but it is very slow. The test we have in MASM32 running around 15 sec on an Ivy Bridge will need around 1 hour in Excavator......