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:03 Kaipei left, Kaipei joined 00:06 reportable6 left, kjp left 00:07 reportable6 joined 01:11 frost joined 02:12 greppable6 left, nativecallable6 left, sourceable6 left, unicodable6 left, notable6 left, shareable6 left, coverable6 left, quotable6 left, linkable6 left, benchable6 left, reportable6 left, statisfiable6 left, tellable6 left, bloatable6 left, evalable6 left, committable6 left, releasable6 left, bisectable6 left, evalable6 joined, shareable6 joined, reportable6 joined 02:13 releasable6 joined, bisectable6 joined, benchable6 joined, greppable6 joined, linkable6 joined, unicodable6 joined, quotable6 joined 02:14 nativecallable6 joined, bloatable6 joined, statisfiable6 joined, sourceable6 joined, committable6 joined 02:15 coverable6 joined, notable6 joined, tellable6 joined 03:15 linkable6 left, evalable6 left, linkable6 joined 03:17 evalable6 joined 04:32 kjp joined 05:32 quotable6 left, statisfiable6 left, bisectable6 left, unicodable6 left, coverable6 left, shareable6 left, notable6 left, linkable6 left, releasable6 left, evalable6 left, sourceable6 left, tellable6 left, nativecallable6 left, committable6 left, greppable6 left, reportable6 left, bloatable6 left, benchable6 left, unicodable6 joined, sourceable6 joined, evalable6 joined 05:33 coverable6 joined, shareable6 joined, quotable6 joined 05:34 statisfiable6 joined, greppable6 joined, linkable6 joined, bloatable6 joined, nativecallable6 joined, committable6 joined, reportable6 joined, bisectable6 joined, releasable6 joined, notable6 joined 05:35 benchable6 joined, tellable6 joined
Nicholas [* GOOD *] 05:38
japhb o/ 05:40
06:07 reportable6 left 06:08 reportable6 joined
nine \o 06:22
08:02 unicodable6 left, statisfiable6 left, linkable6 left, quotable6 left, nativecallable6 left, releasable6 left, shareable6 left, committable6 left, bloatable6 left, tellable6 left, sourceable6 left, notable6 left, greppable6 left, coverable6 left, reportable6 left, bisectable6 left, evalable6 left, benchable6 left 08:03 benchable6 joined, sourceable6 joined, bloatable6 joined 08:04 releasable6 joined, greppable6 joined, notable6 joined, linkable6 joined, statisfiable6 joined, tellable6 joined, committable6 joined, nativecallable6 joined, reportable6 joined, quotable6 joined 08:05 bisectable6 joined, unicodable6 joined, shareable6 joined, coverable6 joined, evalable6 joined 10:01 frost left 10:22 lizmat_ joined 10:26 lizmat_ is now known as lizmat 10:56 frost joined 11:10 discord-raku-bot left, discord-raku-bot joined 11:58 discord-raku-bot left, discord-raku-bot joined 12:05 discord-raku-bot left, dogbert17 left, discord-raku-bot joined 12:07 reportable6 left 12:10 reportable6 joined
Geth MoarVM/disp-bytecode-size: b1109f043b | (Elizabeth Mattijsen)++ | src/disp/syscall.c
Use MasterDuke's suggestion
 12:11
12:12 dogbert17 joined
Geth MoarVM: cc49dcf935 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/disp/syscall.c
Attempt at implementing a "bytecode-size" dispatch

As suggested by jnthn: irclogs.raku.org/moarvm/2022-06-12.html#11:30		 12:24
jnthn lizmat++ 12:57
lizmat I was wondering if I should generalize that dispatch into a more general frame introspection mechanism?
nine jnthn: I've come across a bit of an issue in RakuAST. my $native_trait := multi trait_mod:<is>(Routine $r, :$native!) { ... } will actually bind the proto instead of the multi candidate, because in github.com/rakudo/rakudo/blob/raku...umod#L1037 we generate a lexical lookup instead of a closure clone. Why do we do that there? Apparently we can't decide that on the scope alone, 13:00
lizmat I was specifically thinking about cuuid name outer
nine but how else?
lizmat I wouldn't be surprised if that code was a first approximation to get things working? 13:01
jnthn lizmat: I'd probably do individual calls for the different things rather than building up a data structure of multiple pieces, since it will be hard to EA away stuff created inside of syscalls 13:04
lizmat jnthn: I was more thinking along an extra parameter indicating what stuff you'd want 13:05
jnthn And syscalls in the MoarVM sense - unlike those in the OS sense - are cheap. Spesh can even lift the type/repr check out if there is a sequence of calls that validate that.
lizmat ok, so multiple calls it is then
jnthn lizmat: I think that's still harder opt wise
nine Cheap to call and also cheap to implement
lizmat okidoki, just more code, but I can live with that :-) 13:06
jnthn nine: Why is IMPL-EXPR-QAST involved in traits at all?
Oh, sorry, misread 13:07
I'm not sure why it's not just always self.IMPL-CLOSURE-QAST($context)
Try it and see, I guess 13:09
nine Ha! Indeed. Now that was easy :) 13:19
13:25 lizmat_ joined 13:27 lizmat left 13:32 lizmat_ is now known as lizmat
lizmat hmmm.. it appears bytecode-size is constant, even if stuff gets inlined into it? 14:04
14:07 frost left
nine Yes, you are reading the _static_ frame's bytecode size 14:11
lizmat I guess the actual size is not kept anywhere ? 14:16
also: why is cuuid a string, when it only has numeric values afaics
nine The actual size of what exactly?
lizmat of the bytecode after it has inlined stuff 14:17
in it
I mean, that's the purpose of inlining, isn't it ?
nine The bytecode of what?
lizmat of the frame 14:18
m: sub a() { }; dd &a.bytecode-size
camelia 20
nine That would be the static frame
lizmat ah... ok, I think it's starting to click... optimizations only work on clones of the static frame ? 14:19
nine Inlining happens during specialization, the result of which is specialized bytecode. For every static frame there can be an arbitrary number of specialized bytecodes which are picked at runtime.
So the only question that makes sense to ask that would touch size after inlining is "what's the bytecode size of a given frame _on the callstack_?" 14:21
lizmat ack... 14:22
going to think about that over some cycling&
japhb nine: I'm not sure that's the only useful question. For example, you might want to get the collection of specialized bytecodes for a given static frame, and do some analysis across the set. (The value of that of course increasing the more you can inspect about each bytecode) 14:31
nine That's a "yes, but". I'm not sure, we'd want to expose so much about internals. Spesh is an implementation detail after all 14:33
14:36 Kaipii joined
japhb Well, fair enough. And I certainly wouldn't make it a Raku feature ... or even Rakudo or NQP. But it seems like the kind of thing that someone optimizing for MoarVM might reasonably want to know, so being able to introspect it on some debugging interface at least seems useful. (Whether that be the literal debug server, or via syscalls that are explicitly for low-level work only.) 14:37
14:39 Kaipei left 14:41 Kaipii left, Kaipii joined 16:14 Kaipii left, Kaipii joined 16:33 vrurg_ joined, vrurg left
nine When invoking 37 'parameterize', provided outer frame 0x32c22b0 (1329 'IMPL-STUB-CODE') does not match expected static frame 0x3d6c160 (45 '') 17:27
Ah, of course!
[Coke] Glad we could help! ;) 17:56
18:06 reportable6 left 18:07 reportable6 joined
lizmat so I'm thinking about how one would be able to find out the language level with which a given Callable (well, technically a Code) was compiled 20:06
I've gotten as far as this: MVMString *language_level = ((MVMCode *)obj)->body.sf->body.cu->body.mainline_frame 20:08
only thing needed is to look up CORE-SETTING-REV in that stash, right?
I guess something like ...mainline_frame->body.lexical_names_list somehow? 20:10
nine There's a lexical_names hashmap and a lexical_names_list array 20:13
I do wonder though: what do you need this information for?
lizmat well... I guess it can be very handy to know when you get a Callable at which language level it was compiled 20:17
and decide on things to do after that ?
and being able to dispatch on language level would also be very helpful, I think?
nine But the VM doesn't care about such things? It rarely even distinguishes between NQP and Raku 20:18
lizmat are you implying there would be an easier way to find out the language level of a given Callable / Code object ? 20:20
nine No, I just don't understand why you'd need that inside MoarVM 20:21
lizmat well, I would create a Code.language-level method that would do the correct nqp::dispatch
agree we don't need it inside MoarVM... but outside? 20:22
nine That's a different question :) And one that doesn't involve the VM 20:23
lizmat please enlighten me :-) 20:24
nine "Language version" is a concept that the VM does not know at all. That's handled completely in high level code and it should be kept that way. Luckily dispatch is also done purely by high level code. So you don't have to change the VM in any way to achieve language version dependent dispatching. 20:26
lizmat except for being able to find out the language version of a given Callable ? 20:27
because until I grokked the syscall functionality, I didn't see a way for that 20:28
20:29 linkable6 left, evalable6 left 20:31 evalable6 joined, linkable6 joined
nine Wouldn't that just require adding an attribute to Code and setting the appropriate value at compile time? 20:32
lizmat wouldn't that add a lot of overhead? 20:33
but an interesting idea
or perhaps add it @!compstuff 20:34
*to
nine @!compstuff is cleared after compilation
lizmat so is that a yes or no for adding it after compilation? 20:35
nine Compared to how much data is in a Signature, which every Code object has, a single attribute doesn't sound like much
lizmat ok, fair enough... will sleep over it... afk&
nine You can't use @!compstuff
21:24 Kaipii left
jnthn Please don't use @!compstuff, it'll either be repurposed or hopefully tossed out by the RakuAST-based compiler frontend. 21:46
If there's a $!flags field it may be possible to `+|` them onto that, but then it'd be a pain for guarding potentially 21:47
lizmat I will not use @!compstuff 21:55
:-)
22:04 patrickb_ joined, Techcable_ joined 22:07 leedo_ joined, patrickb left, Techcable left, leedo left, patrickb_ is now known as patrickb, Techcable_ is now known as Techcable

Powered by Cro and the Raku® Programming Language.

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

Thank you!