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.
Nicholas Servus, #moarvm 06:53
nine Morgen! 07:00
Nicholas despite it (no longer) being "nice weather for ducks", there still *were* ducks: drive.google.com/file/d/1dF9OQtaL0...sp=sharing 07:04
MasterDuke Nicholas: heh, just came across a commit of yours on HN github.com/Perl/perl5/commit/24f4b7dabc8 08:14
Nicholas I remember a bunch of discussion on that from $others of "but $my language can do this, so why is this special. Silly attenion seekers". 08:16
and I thought "you missed the point" 08:17
sure, *any* language could do it, and many can
but most languages don't get the feature added specifically to process real space data
MasterDuke yeah, that part's pretty cool 08:20
news.ycombinator.com/item?id=31430170 HN link btw 08:21
MasterDuke hm, looks like we don't concatenate a newline onto something else quite as frequently as i thought we might 12:20
nine Finally! RAKUDO_RAKUAST=1 ./rakudo-m -Ilib t/12-rakuast/literals.t succeeds without precompiling anything first. 12:28
With this we're up to 416 spec test files passing and (to me) even more interesting: 290 spec test files pass without precompiling anything first! 12:29
jnthn Wow, very nice 12:33
MasterDuke would it be possible (and make sense) for github.com/MoarVM/MoarVM/blob/mast...#L155-L187 to mutually recursively call storage_type specific versions of itself when it hits a strand? then we don't have that switch in the loop body? 12:37
nine Everything needed for that is already pushed in case someone wants to try :)
Heredocs are a huge point that's missing. 13:07
jnthn I'll happily missing figuring that one out :P 13:09
nine There goes my hope of evading them... 13:09
MasterDuke (btw, my previous question does not in fact make sense, MVM_string_gi_get_grapheme returns a value, so can't trivially be converted to recursively call/switch to specific version of itself) 13:11
lizmat just found a module that will stop working in RakuAST 13:13
github.com/raku-community-modules/...chy.pm6#L4
I guess that actually goes for all uses of $*W 13:14
but I guess it's a reminder we need some HLL solution to activating a pragma in the importing scope 13:15
MasterDuke gist.github.com/Whateverable/13a3c...4e254bfc22
^^^ uses of $*W in the ecosystem as of several years ago 13:16
lizmat some false positives, but yeah :-) 13:22
afk for a few hours, cycling between showers (hopefully :-) 13:25
MasterDuke hm, i  wonder how terrible it would be to have a bunch of labels and jump between them instead...? 13:38
nine MasterDuke: the other question is if that would actually be faster. After all C compilers take your source code more as a humble suggestion that's wide open for interpretation. 15:30
sibble? babble? quibble? I guess I'm not in Kansas anymore 16:17
MasterDuke nine: true. but i am encouraged by how much faster the special case i added in/for MVM_string_utf8_encode_substr is 20:05
though i think in some other cases the compiler can much more easily see that a prior branch would perfectly predict the switch in MVM_string_gi_get_grapheme, so i wouldn't expect such wins everywhere 20:07
wow. i tried creating a function pointer and using a switch to assign the right codepoint iterator function (i.e., right now, my fast path one or the original one) to it, and then using that in the main loop in MVM_string_utf8_encode_substr 20:19
and it was much slower. 6.6s with function pointer vs 1.9s with the fast path hardcoded vs 3.9s on master 20:20
i assumed/hoped gcc would be able to magically make the cost of the function pointer go away
oh, currently the functions are marked as MVM_STATIC_INLINE, i guess accessing them through a function pointer prevents the inlining 20:23
japhb Yeah, plus poorly predicted branches kill performance all by themselves -- and mutable function pointers fall into that category. (Though you're probably right, lack of inlining would still swamp that.) 20:42
MasterDuke i am still somewhat surprised, i believe all the necessary information is still knowable at compile time, so i wouldn't have been surprised if it *hadn't* been slower 20:50
maybe even the known destinations of function pointers aren't allowed to be inlined?
vrurg When DESTROY is invoked by MoarVM, is it invoked directly? Or is there a thunk involved? Turns out I overlooked one more entry point for starting a new Raku call stack and need to setup $*STACK-ID for it somehow. 21:42
jnthn There's a callback (registered somewhere in BOOTSTRAP) that recieves a list of objects to destroy 22:07
It then calls DESTROY on them 22:08
vrurg jnthn: The core is in Metamodel::Finalization. And, luckily, it registers a list of routines to be invoked on the object. 22:50
vrurg So, I can just wrap them into a thunk. 22:52

Powered by Cro and the Raku® Programming Language.

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

Thank you!