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:06 reportable6 left 00:08 reportable6 joined 01:05 frost joined 02:54 Kaiepi left 04:13 [Coke] joined 04:17 [Coke] left 04:19 [Coke] joined 04:29 [Coke] left 04:31 [Coke] joined 04:38 Kaiepi joined 05:02 [Coke] left 05:03 [Coke] joined 05:08 [Coke] left 06:06 reportable6 left 06:09 reportable6 joined
Nicholas Servus, #moarvm 06:53
nine Morgen! 07:00
07:01 [Coke] joined
Nicholas despite it (no longer) being "nice weather for ducks", there still *were* ducks: drive.google.com/file/d/1dF9OQtaL0...sp=sharing 07:04
07:07 [Coke] left 07:18 [Coke] joined 07:31 [Coke] left 07:32 [Coke] joined 07:41 [Coke] left 07:57 [Coke] joined 08:10 [Coke] left
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
09:11 [Coke] joined 09:23 [Coke] left 09:24 [Coke] joined 09:32 TempIRCLogger left 09:35 TempIRCLogger joined 09:48 [Coke] left 09:50 [Coke] joined 10:01 [Coke] left 10:15 sena_kun left 10:24 sena_kun joined 10:56 linkable6 left 10:58 linkable6 joined 11:04 [Coke] joined 11:22 [Coke] left 12:06 reportable6 left 12:08 reportable6 joined
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
13:09 Kaiepi left
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
15:09 frost left
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
18:07 reportable6 left, reportable6 joined 19:29 rypervenche_ left
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
20:26 linkable6 left 20:28 linkable6 joined
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?
20:52 [Coke] joined 21:24 Kaiepi joined
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
22:18 discord-raku-bot left 22:19 discord-raku-bot joined
vrurg jnthn: The core is in Metamodel::Finalization. And, luckily, it registers a list of routines to be invoked on the object. 22:50
22:50 Kaiepi left
vrurg So, I can just wrap them into a thunk. 22:52
22:54 Kaiepi joined 23:55 Kaiepi left

Powered by Cro and the Raku® Programming Language.

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

Thank you!