Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
MasterDuke . 15:01
tellable6 2022-03-11T06:21:11Z #moarvm <Nicholas> MasterDuke www.pcg-random.org/posts/bob-jenki...trand.html -- is "that" good enough for us?
2022-03-11T07:33:31Z #moarvm <Nicholas> MasterDuke if you want to try it, you might find it easiest to adapt it from this commit github.com/nwc10/perl5/commit/16ff...035640b27f
MasterDuke Nicholas: seems to be *slightly* slower than xoshiro266++, but not really enough to make a big difference i think. still faster than tinymt64 15:36
Geth MoarVM: usev6++ created pull request #1684:
Fix typo in comment		 16:06
MoarVM: edb4ad12f8 | (Christian Bartolomäus)++ | src/core/frame.c
Fix typo in comment
 16:15
MoarVM: 00eef67b68 | niner++ (committed using GitHub Web editor) | src/core/frame.c
Merge pull request #1684 from usev6/frame.c_typo

Fix typo in comment
japhb FWIW, regarding all the PRNG stuff. I'm perfectly happy offering *additional* PRNGs, tuned for different things. In fact, I think an API for allowing multiple PRNGs (and multiple instances of each) without sacrificing steady state performance would be a great idea. But I'm not terribly comfortable changing out a decently good PRNG for one that is weaker just to gain some extra speed. 19:49
And PRNGs are a lot like crypto systems in that anyone can make a new PRNG that they themselves are not able to see the flaws of, so I tend to have a pretty dim view of people's claims that their own custom PRNG is just the bee's knees. 19:50
(And yes, in many cases I care about, Mersenne Twister is not the optimum choice. I just don't want to weaken our default without really good cause.) 19:51
BTW, the comment above about not "sacrificing steady state performance" meant that I'm willing to pay a (small) performance hit at the time of instancing a particular PRNG, as long as it's not slower to just extract the next value after it's already running. 19:53
MasterDuke fwiw, i haven't been considering or testing any that i believe are weaker. aiui, they're both faster and stronger 20:42
japhb MasterDuke: Good to hear. I guess I'm saying "Don't trust the author of the algorithm to assess its quality". :-) Well reviewed by the experts in the community, that I can get behind. 21:27
The reason one of the above algorithms triggered my worry is that the author described it as combining multiple weaker things to make a stronger thing -- which is a known trap in the crypto world, where combining multiple weaker things can have zero effect or even make an even *weaker* thing. 21:29
And FWIW, none of this is intended to be discouraging, and if it is I apologize. Just urging caution, and thinking about how this could be an opportunity to get away from the "one hard-coded PRNG with a single process-wide instance and no tunables" model 21:35
MasterDuke no worries. though i'm currently not up for that large of a change. swapping current algorithms isn't that complicated, but creating an API for multiple PRNGs (which i would support) is more than i want to do right now 21:37
japhb Or even thread-bound instances, because we have no idea on which threads our Rakudo tasks will be scheduled on, and thus without getting rather deep into scheduler control, no easy way to separate out random streams
That's fair.
MasterDuke could be in the future, but i have enough large unfinished projects (e.g., removing the fsa, switching to gmp, removing spesh candidates, converting vmarray to use the fsa) i don't want to start a new one 21:39
japhb This I *understand*.
japhb chuckles that the first and last goals seem in conflict in exactly the way most people's collections of projects often do 21:41
MasterDuke heh, yeah. i guess a better description of the last is converting vmarray to use a single piece of memory for metadata and storage, that it would currently use the fsa is sort of an implementation detail 21:42
japhb OOC, what's the expected benefit of that one? Less pointer chasing? 21:44
MasterDuke mainly that concurrent modification can be detected and MVM_panic instead of segfault. same as Nicholas++ did for hashes (along with the switch to the robin hood) 21:45
japhb Ah, gotcha. 21:47
Geth MoarVM: MasterDuke17++ created pull request #1685:
Use JFS64 instead of TinyMT64 as our PRNG		 23:11

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!