github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
brrt good * 06:25
nwc10 good *, brrt
brrt ohai nwc10 06:33
I'm... a little disoriented, as in, 'what's next'
now that the floating point thing is done :-) 06:34
brrt I can.... try to implement general register requirements 06:34
I could also continue on the tree-based optimizer. 06:35
But, I could also move forwards with the intended refactor to linear form
(the one thing that I haven't quite figured out just yet, is how to do cheap modification of a linear form 06:36
nwc10 which one makes it easiest for other people to help? which one delivers speed benefits earliest? which one helps *you* earliest? 06:38
and is the ranking different for each question? :-)
brrt nwc10: general register requirements is probably most functionally important, because it'd mean that we can increase the range of opcodes supported by the expr JIT 07:04
my goal here is still to deprecate the lego JIT in favor of the expr JIT 07:05
so... the more that *can* be done by the expr JIT, the better
the linearization will, I think, allow the JIT to handle whole routines, rather than just basic blocks. That in turn will simplify the rest of the JIT 07:06
timotimo brrt, i'd love optimizer / repr integration, and the ability to devirtualize in the expr jit 11:50
brrt timotimo: noted 12:19
timotimo so that going from template jit to expr jit doesn't potentially make things worse in that way :) 12:20
today i can go figure out why the F the sqlite files the profiler spits out suddenly have their unique constraints blown up 12:22
brrt would you prefer to use templates, or do you think it'd be reasonable to 'hand-write' trees? 12:33
timotimo depends entirely on what that entails :) 12:34
brrt well, building by hand means computing reference offsets, for one thing 12:43
timotimo that could be terrible, or it could be merely a little nuisance, depending on how you do that :) 12:44
brrt I find it not so difficult 13:07
but then again, I'm not representative
ohai pamplemousse 13:19
what's next :-)
pamplemousse Hi brrt :) 13:29
Right now I'm working on my simplified version of the eval function
brrt Cool... where do you want that functionality to be merged into? 13:30
pamplemousse The code to add the commandline option and eval could go either in rakudo/src/main.nqp or in nqp/src/HLL/Compiler.nqp. I'm currently doing them in the NQP repo and adding support for the MoarVM backend through the existing interfaces 13:40
timotimo oh, maybe now would be a good time to point you at App::MoarVM::Debug, which lets you step through nqp and perl6 code line by line - though the CLI is really a little strange 13:44
pamplemousse That looks like it will be really helpful, thanks 13:47
timotimo the commands for the shell it offers really need a rewrite 13:48
timotimo ok, this is upsetting 14:58
the same gc sequence number occurs multiple times in the profile
already at the moarvm level
consequently, the moarperf gc graph now has some *negative* numbers in the "time between GC runs" graph 14:59
jnthn Oops. 15:14
pamplemousse jnthn: I was wondering if you have a preference for whether I should add a command line option (--bytecode or -b) enabling the explicit execution of a bytecode file or whether perl6 should implicitly check for the magic number in the first few bytes of a file. 15:22
jnthn Hm, I sort of thought maybe you'd give bytecode to `moar`, but maybe that's not really feasible given the library paths and so on... 15:43
Maybe an option is better
pamplemousse I am still essentially giving the bytecode to moar, I just have to pass it through perl6 for the library path stuff. 15:59
Alrighty, option it is
lizmat is there a chance to get MoarVM to accept bytecode from any source, not just a file ? 16:13
but also e.g. a socket ? 16:14
jnthn There's an op that can load bytecode from a buf 16:25
So "yes, but write the server bit in Perl 6" :)
pamplemousse Ideally, I'd like anything that can map to an IO Handle to be able to be used, but I'm still not really sure how to get to there 16:29
jnthn: Where does that op live?
jnthn In MoarVM it's called loadbytecodebuffer 16:30
Seems it's mapped to nqp::loadbytecodebuffer
pamplemousse Thanks 16:31
pamplemousse I was wondering if anyone could explain what a compunit is? Is it bytecode, is it something else? I'm here: github.com/perl6/nqp/blob/master/s...r.nqp#L178 and tracked the definition of that function/op to here: github.com/MoarVM/MoarVM/blob/mast...rp.c#L3274 and am struggling a bit. 17:21
It's touched on in the Rakudo/NQP Internals course but I still don't really get what it is that is being handed to compunitmainline
timotimo pamplemousse: compunit is simply "one unit of compilation" 17:47
every time one compilation happens, one compunit falls out 17:48
compunitmainline lets you get the code "at the root" of the compunit so to speak
think of it as "frame 0" or something, where frames are individually invokable pieces of code with a name and set of lexicals and locals, as well as an "outer" frame 17:49
a compunit usually also comes with its own serialization context, but i'm not sure what the exact relation is. i think it's 1:1 17:50
pamplemousse So is the compilation unit that is generated when the source program is compiled bytecode? 17:53
And compunitmainline gets you to the instruction at "frame 0"?
timotimo i think the mast compiler writes out the bytecode file, and a bytecode file (which also includes the serialized blob, i.e. the serialization context) is that compunit 17:55
pamplemousse Okay, I think I follow. Thanks timotimo++ 18:01

Powered by Cro and the Raku® Programming Language.

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

Thank you!