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:05 sena_kun left 00:48 MasterDuke joined
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
04:13 Voldenet_ joined 04:14 Voldenet left, Voldenet_ is now known as Voldenet 05:14 Voldenet_ joined 05:15 Voldenet left, Voldenet_ is now known as Voldenet
nine MasterDuke: ah, yes. I think the $RESOLVER thing came after I started work on this 09:37
09:52 sena_kun joined 14:35 notna joined 15:12 notna left 19:13 [Coke] left 19:15 [Coke] joined
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
19:20 vrurg joined, vrurg_ left, [Coke]_ joined 19:21 [Coke] left
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
20:02 vrurg left 20:03 vrurg joined 21:18 [Coke]_ is now known as [Coke] 22:14 sena_kun left 22:48 [Coke]_ joined 22:49 [Coke] left