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 . 00:48
tellable6 2024-03-22T03:43:05Z #moarvm <japhb> MasterDuke: I very vaguely remember some NFA optimization work, but I can't remember by whom ... might have even been Larry
hey MasterDuke, you have a message: gist.github.com/e8be8ee9a4065e65c7...f50a13178b
hey MasterDuke, you have a message: gist.github.com/ed926e60fe1274788d...d27ac18534
hey MasterDuke, you have a message: gist.github.com/404f5d94709d7eab07...687d2179b9
hey MasterDuke, you have a message: gist.github.com/59767d38fcff73471c...0fbc307d11
hey MasterDuke, you have a message: gist.github.com/17dd4fedf321815c5f...f71f480663
MasterDuke nine: very nice. i did have a question about your commits. it looked like you were using `$*R` in a couple places where a `$RESOLVER` lexical was available. i assume that's just an oversight and those could be changed? 00:52
jnthn: yes, i was talking about the ones generated during an nfa run. fwiw, it looks like moarvm uses an array attached to the tc, but it's never cleared, just realloc'ed bigger if necessary (same with done, curst, and nextst). however, the jvm backend *does* clear them each time 00:58
it also looks like there may be an algorithmic difference. the code is really pretty similar, but github.com/MoarVM/MoarVM/commit/c6...cd2b797230 seems like maybe it has a performance improvement component, which i'll try to replicate 01:01
nine MasterDuke: ah, yes. I think the $RESOLVER thing came after I started work on this 09:37
jnthn MasterDuke: Probably MoarVM doesn't clear it because it's C so we have a length and the memory separately, and just reset the counter. But OK, not lack of clearing 19:16
MasterDuke it also looks like maybe the jvm version could just use `long[]` instead of ArrayList (though now we're using the more efficient IntArrayList in my branch maybe it isn't such a big deal) 20:02