|
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 |
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 |
|||
|
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 |
23:11 | |