Sure it is, you can't predict what it will be right? That's truly random.
Even the small procedure itself eats up 'n' number of CPU cycles.
Everything eats CPU cycles, even the most trivial things.
whether it is a Intel or a AMD the cycles eaten is different,
or if it's a Athlon or Phenom, the cycles are different,
different clock speeds, the cycles are different.
CPU throttling, the cycles are different,
different PB compiler/libs used, the cycles are different.
The only way to predict would be to "intercept" every single clock cycle on the CPU core being used, but that itself would eat a lot of cycles and would really slow things down, it would just be easier to either hack the program or write a virus or logger of sorts, the bit fetched may not always come from the same CPU core (the OS might have moved the thread/program to another core)
This is the complexity of a advanced computer system, reduced to a single unpredictable toggling of a bit being 1 or 0
I'm not saying this is perfect for security randomness, or maybe it is?
Except that even security software would only use the least significant bit,
the rest do have a increasing pattern of time, if you need more "random bits" then a soundcard could be a interesting source.
The whole gimmick about the procedure above is how fast it is, compared to anything else, and how unpredictable.
Those two numbers shown are all the ones and zeros measured,
the real number of cpu cycles is way higher than that,
We're basically picking the bit randomly (our timing is not guaranteed),
from a random indefinite stream of bits (CPU cycles never end and is unpredictable).
The tests I've shown here are facinating, I only managed to get a 50/50 perfect balance a single time so far, usually it's balance is 50% (+/- 1% to 2%) with bit sampling done over time,
picking millions of bit samples in a tight loop is not advised as caching may cause bias due to CPU optimization, it is "predictable" as it takes place x cycles after the last bit sampling
Taking bit samples at each VBLANK should also be ok, as there is no way to know how many cycles will actually happen between each VBLANK.
Just play around with the loop and you'll see how it works.
Of course, in theory as this is close to natural random as you can get (this easily at least),
there is always the chance that you might end up with almost only 1's rather than 0 over a period of time.
So my advise for a game where a NPC use RandomBits() to pick the left or right path to walk, it might be smart to swap the two so that =1 is not always the left path for example, use 0 sometimes.
Of and this RandomBits() is perfect to simulate a coin toss among other things, heads or tails? *laughs*
After all it would be silly if the npc went in circles wouldn't it (if it got a bunch of 1's in a row)
Then again, a single npc walking in a circle would be a random act in and of itself, I guess it depends on whether that behavior would fit the situation.
As to applications the opportunities are endless, although I haven't tested, the bit sampling should be pretty similar to white noise (or is it pink?)
Remember, when some of you think random you are actually thinking pseudo random, in that you do not want a bunch of 1's in a row, or do not want a bunch of 0's in a row, well sorry but this tiny procedure do not guarantee that, just like in real life you never know what you'll get