6 ms·

Possibly ironically, here was the comment above the previous implementation https://chromium.googlesource.com/v8/v8/+/2755c5a1b1cf7fc4c5c614378e5231636e6dcff5%

Possibly ironically, here was the comment above the previous implementation https://chromium.googlesource.com/v8/v8/+/2755c5a1b1cf7fc4c5c614378e5231636e6dcff5%5E%21/#F1 https://chromium.googlesource.com/v8/v8/+/2755c5a1b1cf7fc4c5... // // This class is used to generate a stream of pseudorandom numbers. The class // uses a 48-bit seed, which is modified using a linear congruential formula. // (See Donald Knuth, The Art of Computer Programming, Volume 3, Section 3.2.1.) It's still not entirely clear why this particular algorithm was chosen (it'd been cool if some explanation had been given in this blog post). I suspect the reason was related to the fact that, in javascript, you can only multiply two 16 bit numbers without fear of loss of precision (without doing a fair amount of gymnastics), and they wanted something they could easily port into pure javascript to be used as a optimizer test. As partial support for that theory, the new code has now been put back almost entirely into the C++ layer. Then again, the author might be looking at that commit and wondering "Why did we pick that algorithm?" :)

magicalist 11y ago
> here was the comment above the previous implementation That's about a different RNG than the one that Mike Malone's article was about. The one you're pointing to was used on the C++ side of the world (and so doesn't have the concerns of JS numbers), the one the article was about was pure JS. Part of the V8 update was to unify the RNGs (see the patch history), so now both use the same (better) RNG. On the JS side, the new C++ RNG is now used to fill a buffer of random numbers to amortize the cost of calling into C++ code from JS. As for why these implementations were chosen: Mike Malone covers the commit history and probable source of the JS implementation fairly well (which is probably all you'll really get since it's been 6 years or so now). The old C++ implementation is relatively recent, with some hints to its choosing here: https://github.com/v8/v8/commit/eb381b9444c6b1ec78414d1c9375f67c320cae74 https://github.com/v8/v8/commit/eb381b9444c6b1ec78414d1c9375...
deleted 11y ago
[deleted]
TazeTSchnitzel 11y ago
> you can only multiply two 16 bit numbers without fear of loss of precision (without doing a fair amount of gymnastics) You can do signed and unsigned 32-bit integer multiplication, but there's modulo/overflow there.
- Franciscouzo 11y ago
  You can use 26 bits integers for multiplication without fear of overflowing with IEEE 754 doubles.

magicalist 11y ago

> here was the comment above the previous implementation That's about a different RNG than the one that Mike Malone's article was about. The one you're pointing to was used on the C++ side of the world (and so doesn't have the concerns of JS numbers), the one the article was about was pure JS. Part of the V8 update was to unify the RNGs (see the patch history), so now both use the same (better) RNG. On the JS side, the new C++ RNG is now used to fill a buffer of random numbers to amortize the cost of calling into C++ code from JS. As for why these implementations were chosen: Mike Malone covers the commit history and probable source of the JS implementation fairly well (which is probably all you'll really get since it's been 6 years or so now). The old C++ implementation is relatively recent, with some hints to its choosing here: https://github.com/v8/v8/commit/eb381b9444c6b1ec78414d1c9375f67c320cae74 https://github.com/v8/v8/commit/eb381b9444c6b1ec78414d1c9375...

deleted 11y ago

[deleted]

TazeTSchnitzel 11y ago

> you can only multiply two 16 bit numbers without fear of loss of precision (without doing a fair amount of gymnastics) You can do signed and unsigned 32-bit integer multiplication, but there's modulo/overflow there.

Franciscouzo 11y ago
You can use 26 bits integers for multiplication without fear of overflowing with IEEE 754 doubles.