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.
00:09 reportable6 left 00:12 reportable6 joined 01:12 linkable6 left, evalable6 left, linkable6 joined 02:15 evalable6 joined 02:27 discord-raku-bot left, discord-raku-bot joined 03:27 shareable6 left, bloatable6 left, reportable6 left, statisfiable6 left, greppable6 left, nativecallable6 left, benchable6 left, unicodable6 left, committable6 left, quotable6 left, coverable6 left, linkable6 left, releasable6 left, notable6 left, squashable6 left, sourceable6 left, evalable6 left, tellable6 left, bisectable6 left 03:28 reportable6 joined, bisectable6 joined, greppable6 joined 03:29 sourceable6 joined 03:30 shareable6 joined, nativecallable6 joined 03:31 statisfiable6 joined, squashable6 joined 03:41 [Coke] left 03:44 [Coke] joined 04:28 quotable6 joined, releasable6 joined, benchable6 joined 04:29 notable6 joined 04:30 unicodable6 joined 04:54 squashable6 left 05:28 committable6 joined 05:29 coverable6 joined, bloatable6 joined, linkable6 joined 05:42 jnthnwrthngtn left, jnthnwrthngtn joined 06:08 reportable6 left 06:29 evalable6 joined, tellable6 joined 06:51 discord-raku-bot left 06:54 discord-raku-bot joined 06:56 squashable6 joined 08:48 sourceable6 left, coverable6 left, bisectable6 left, bloatable6 left, linkable6 left, shareable6 left, statisfiable6 left, nativecallable6 left, releasable6 left, evalable6 left, notable6 left, benchable6 left, unicodable6 left, tellable6 left, squashable6 left, quotable6 left, greppable6 left, committable6 left 08:49 notable6 joined, unicodable6 joined, coverable6 joined, tellable6 joined, squashable6 joined 08:50 statisfiable6 joined, sourceable6 joined, quotable6 joined, shareable6 joined 08:51 linkable6 joined, benchable6 joined 09:11 reportable6 joined 09:50 bloatable6 joined 09:51 nativecallable6 joined, evalable6 joined, releasable6 joined 10:49 greppable6 joined 10:50 committable6 joined 10:51 bisectable6 joined 11:03 ShaneC left 12:10 reportable6 left 12:12 reportable6 joined 12:56 crystalfrost[m] joined 14:28 evalable6 left, linkable6 left 14:57 MasterDuke joined
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
15:29 evalable6 joined
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
15:43 frost left
Geth MoarVM: usev6++ created pull request #1684:
Fix typo in comment
MoarVM: edb4ad12f8 | (Christian Bartolomäus)++ | src/core/frame.c
Fix typo in comment
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
16:43 evalable6 left 16:46 evalable6 joined 17:30 linkable6 joined 18:09 reportable6 left 18:28 cognominal left 18:37 Util joined 18:54 sena_kun left 18:55 sena_kun joined 19:16 linkable6 left 19:17 linkable6 joined 19:45 ShaneC joined
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
20:10 reportable6 joined 20:14 sena_kun left 20:15 sena_kun joined
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
22:02 squashable6 left 22:49 ShaneC left 23:04 squashable6 joined
Geth MoarVM: MasterDuke17++ created pull request #1685:
Use JFS64 instead of TinyMT64 as our PRNG