@antiHUMANDesigns

It would be nice to see a follow-up video explaining how the hardware produces truly random numbers.

@jlp1528

I never knew that x86 processors had this functionality built in. It might be slow, but if you absolutely need just a few truly random numbers, it sure beats a wall of lava lamps, a "chaotic pendulum", or a radioactive check source next to a Geiger counter. Long term fans of this channel might get the reference. ;)

@danfg7215

I came for random numbers, I stayed for the strong accent

@Capeau

Seed numbers generating the same sequence of pseudo randomness is very usefull in thinks like VFX for example, when you need to rerender certain effects but dont want to do everything back from 0... So using the same seeds assures you it will still fit togetter with everything else... For example when calculating particles, wind, fluid sims, etc... but even the noise from monte carlo raytracers.

@Liqtor

Eve Online was seeded on the number "42". Just have to love that.

@antiHUMANDesigns

The standard C++ library <random> can use a "true random" engine automatically if available in the hardware, so it's really easy to use in modern C++.

Also, as you mentioned, it is recommended to use it mainly for randomizing the seed.

@JeffBilkins

Would be interesting to hear how the computer collects and uses entropy.

@pelegsap

An Italian science researcher in a room completely empty apart of a computer and an espresso machine? Yeap, checks out 😛

@PurpleBaldGuy

True random numbers were friends we made along the way

@matiasm.3124

Well in linux you have /dev/random and urandom that gets entropy from hardware cpu, hard disk, user inputs etc. That can say that are "real" random numbers

@jeromethiel4323

Pseudo random number generation and seeds were used in computer games all the way back into the 80's.  One of the best "adventure" type games was Akalabeth, and the only way you got the same dungeons and overland maps was to use the same "seed."

Which is why when i was writing games back then, i would just very rapidly (machine coding) generate PR number after PR number while waiting for the player to input.  Player input is about as random a factor as you can get.  Nobody is going to be able to repeatably respond within milliseconds every time.

One of my favorite tricks was to use the refresh register in a Z80 as the seed.  Because it was constantly incrementing, and i could use that to tweak the randomness of the numbers i was generating, again using the player as the randomizing element.  Mainly because the refresh register was a zero cost (in programming terms) high speed moving target.

@jlp1528

It's also nice to have the same seed create the same random numbers in for example Minecraft so I can play in the same world shared by a friend or website and spawn in the same place like next to a village. I imagine some other games operate on the same principle in a great variety of implementations, and that many others at least theoretically could.

@blucat4

Hey Valerio, the whole point of the video was for you to explain how hardware could generate a truly random seed, and you didn't even mention that at all. Either in general or in the case of the x86. For anyone who didn't already know, it was all gobbledegoop. The only clue was when the questioner asked if you knew what the source of entropy was within the chip, and you said you didn't know. Anyway wikipedia says it's "thermal noise within the silicon". Cheers.  🙂

@davidjohnston4240

The real utility difference between RdRand and RdSeed is that numbers from RdRand can be concatenated to make larger random numbers up to 256 bits and still maintain O(2^256) security. 128 bits for older chips. RdSeed you can concatenate the outputs to make as large a number as you like. So 512 bit keys or 1024 bit keys or 10 million bit keys will support a security strength that large. RdRand offers computational prediction resistance and O(2^256)+O(2^256) = O(2^257), not O(2^512). This is sometimes referred to as the additive vs multiplicative prediction resistance of RdRand vs RdSeed.

@MattGodbolt

Overjoyed to see Compiler Explorer being used to show how these things work under the hood!

@davidjohnston4240

The 800Mhz clock was the clock speed of the uncore logic in the Ivy Bridge CPU in 2011, which is the first CPU to have RdRand. That's just the clock that was available in that area of the chip. Since then there have been hundreds of products with many different clock speeds. The Intel DRNG is run from 100MHz to 2GHz depending on the chip and the power goals for the chip. Those low power SoCs are usually 200Mhz. The high end xeons are currently 2GHz because the Xeons have hard performance requirements to meet.

@EstebanGrasso

Another situation where is useful to set a seed is for teaching programming or data analysis, so everyone can replicate the expected results and easily verify they did the assignments correct.

@klutterkicker

An interesting followup would be to plot the distribution of the random numbers over a few different tests and compare it to pseudorandom numbers.

@lanatrzczka

A few years ago I coded my own version of Breakout. To my great surprise, the game played EXACTLY the same way (provided you didn't miss the ball) each time. Same bricks hit, same scores, basically like watching a replay of the previous game. Upon debug, I realized that always starting the ball from the same position was a contributor to this flaw. Also, the game needed some RND when the ball hit the paddle. All in all, I realized that it is VERY complicated to allow a player to learn a strategy in video games. If you allow too much predictability, the game is ruined because the player can end up in a loop.

@BanterEdits

This video is an amazing showcase of speaking with an accent without hindering the understandability of the spoken content whatsoever. I'm astonished by the way he's articulating the sentences in a way that seemingly highlights the premise on its own. Great stuff.