github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *able6, #moarvm 05:52
said optimisation (there was one, IIRC) has already been backed out. 05:53
The tests fail if you don't :-)
nwc10 good *, brrt 07:38
brrt good * nwc10
timotimo ok! 07:46
jnthn good * 08:59
September already? Gosh, it'll be Christmas soon...
brrt september :-o 09:09
timotimo queues up that Green Day song
jnthn Today is the optimal point for maximizing sleep if planning to spend the month that way... :) 09:28
nwc10 That last sentance scans gramatically, but makes no sense to me 09:32
jnthn If you don't get the song reference, you won't get the follow-up... :) 09:33
nwc10 aha 09:34
jnthn If you do then I'm confused :)
nwc10 no, I dont' get the song reference
timotimo it's "wake me up when september ends" 09:35
nwc10 aha 09:36
nine re 10:23
brrt I wonder how hard it'd be to have a yacc grammar for NQP 10:24
and just write the compiler for NQP in C 10:25
nine Is it me or have we become a bit segfaulty lately? 10:26
brrt: why would you want to go through that pain? 10:33
brrt so as to avoid the whole bootstrapping thing 10:35
timotimo i'm not aware of more segfaults than usual 10:40
jnthn But C compilers are bootstrapped, so it just moves the bootstrapping a level down the stack, no? 10:42
Altai-man But they are still present and pop here and there, so more hunting is hardly harmful.
brrt jnthn: C compilers are apt-get or dnf-installed :-P 10:46
also, yacc is fun
maybe that's the real motivation :-D 10:47
actually, no, now that I think about it, my real, real motivation is, I want to write JIT compiler testcases
so I wanted to write a utility that'd take a bit of MoarVM code and compiled it, but this would either require me to write a whole new language 10:48
or, it'd require me to somehow hook into the NQP compiler 10:49
hence the idea
timotimo we do already have "write bytecode and bytecode files" in nqp 10:54
brrt we don't have a 'compile this to JIT', which is really the component that is missing 11:01
timotimo ah 11:10
shouldn't be hard, though? to just put an op in, or even register a "dispatcher" for the new "syscall" functionality
the vmevent/vmsubscribe/vmeventsubscribe/thingie mechanism ought to let you react to the jitting be finished 11:16
brrt hmmm 11:22
ok, I'm out of touch for sure
I had no idea these things existe
*existed
timotimo hah 11:23
well, the syscall thing isn't actually merged yet
that's part of the dispatch chain thing that is going to replace spesh plugins
there's already replacements for all spesh plugins that rakudo has 11:24
just not merged to master
brrt I see.... I know you've mentioned the 'dispatch chain thing' ... and that you even pointed to a paper but I forgot
timotimo no problem :)
jitting something mostly depends upon data having been recorded in the spesh log, so as long as you're fine with that being missing, causing a piece of code to be jitted shouldn't be much coding work 11:38
brrt well, I meant this to work on fairly small pieces of code, small enough to provide the spesh 'facts' by hand, so to speak 11:40
timotimo ok, so we may want to have "direct" access to the spesh log or something 11:41
brrt well, consider; the real point of this is to provide confidence that a specific JIT compilation strategy works 11:44
so all I really need is to build a piece of code, annotate it with 'facts', run it through the spesh/jit combination, and finally assert some features 11:45
currently I think that confidence is lacking, because I find out about JIT failures by running the rakudo core setting
or worse, by failures in the ecosystem 11:46
timotimo mhm 11:47
timotimo one thing is that spesh facts are based on the SSA form of the bytecode, while you'd normally only have the linear form as it is written to preecomp files and such 11:48
so you can't exactly say "version 5 of register $blah is known concrete" without having looked at the way spesh handles the code
i'd assume you'll also want control over the spesh optimization, i.e. turn it off sometimes 11:49
oh, also: something something inlining and deopt 11:50
perhaps a bit fiddly to set that up for this mode 11:51
hmm
nativecall into libmoar.so? :D
brrt lol. I think I did something like that, way back when parrot was a thing 11:54
but I'd rather not if I can avoid it
as an open-source language/vm project we should really aim to keep the cost of fixing bugs as low as possible 11:55
nine FWIW I'd like to see spesh moved from MoarVM into nqp/Raku code. That would make developing and testing it so much easier. 11:56
jnthn The new dispatch thing is heading in that kind of direction: it removes knowledge of a bunch of things from the VM and into NQP code. 12:00
brrt I think the JIT is going to be C code for the foreseeable future though... 12:03
(truth be told I'm not particularly attached to that, but I think the mechanics of it are easier that way)
MasterDuke my impression is that in recent years there's been a trend away from yacc/bison/etc 12:47
since the parsers they generate don't allow for great error messages
MasterDuke and people usually end up changing what they generate so much that it's considered less effort to make something custom that's well suited to whatever the problem is at hand 12:49
brrt hmm, my impression is that I'm surrounded by generated parsers and parser generators everywhere. 12:56
but yeah, I hear this too, I haven't seen it though
nwc10 getting bison not to leak memory on failure is a bit of a pain 13:11
timotimo fork before doing something, kill child process on failure :) :) 14:41
timotimo i think i'll merge mildly-faster-startup 18:32
it's mostly non-invasive changes to how stuff is created after being deserialized
Geth MoarVM/master: 10 commits pushed by (Timo Paulssen)++
review: github.com/MoarVM/MoarVM/compare/5...aec0fcada9		 18:42
timotimo that's the rebase and merge 18:43
paste.centos.org/view/337addf0 18:45
every int array that's deserialized when rakudo starts up
MasterDuke what are all those 1,1s? 18:47
and why are some zero-length? 18:48
timotimo well, some objects have t have an array attribute or something, but they're also empty 18:51
MasterDuke is it much work deserializing those? or, what is the best ROI to reduce? 18:52
timotimo return on investment you mean? 18:53
i'm most interested in the array at the very start, the one that's all very small numbers
u.setxkbmap.de/#QmiXucgxZSeNhftXXYgdFQ 18:54
this has strings, too
MasterDuke yeah, is it better to remove unneeded arrays entirely somehow? or make existing ones smaller? etc
timotimo i'd say hopefully reduce the amount of stuff in general that gets touched during startup 18:55
[Coke] . 22:37

Powered by Cro and the Raku® Programming Language.

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

Thank you!