04:30 sourceable6 left, statisfiable6 left, coverable6 left, releasable6 left, unicodable6 left, linkable6 left, quotable6 left, shareable6 left, tellable6 left, greppable6 left, reportable6 left, bloatable6 left, committable6 left, notable6 left, evalable6 left, nativecallable6 left, bisectable6 left, squashable6 left, benchable6 left, notable6 joined, reportable6 joined 04:31 nativecallable6 joined, squashable6 joined 04:32 tellable6 joined, benchable6 joined, coverable6 joined, linkable6 joined, quotable6 joined, bloatable6 joined, sourceable6 joined, unicodable6 joined, committable6 joined, shareable6 joined, releasable6 joined 04:33 statisfiable6 joined, greppable6 joined, bisectable6 joined, evalable6 joined 05:45 squashable6 left 05:48 squashable6 joined
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 :-)
06:04 domidumont joined 06:31 domidumont left 06:51 domidumont joined 07:13 MasterDuke joined 07:37 brrt joined
nwc10 good *, brrt 07:38
brrt good * nwc10
timotimo ok! 07:46
07:54 Altai-man joined
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
11:41 domidumont left 11:42 domidumont joined
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
11:46 sena_kun joined
timotimo mhm 11:47
11:48 Altai-man left
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)
12:23 domidumont left 12:25 domidumont joined 12:45 squashable6 left
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
12:48 squashable6 joined
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
13:18 lizmat joined 13:48 brrt left 14:20 MasterDuke left
timotimo fork before doing something, kill child process on failure :) :) 14:41
15:18 brrt joined 15:27 brrt left 15:32 MasterDuke joined 15:45 Altai-man joined 15:48 sena_kun left 16:05 brrt joined 17:44 brrt left, vrurg left, Util left 17:46 vrurg joined, Util joined
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
18:51 domidumont left
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
19:46 sena_kun joined 19:47 Altai-man left 19:52 zakharyas joined 20:49 zakharyas left 21:52 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
[Coke] . 22:37
22:58 sena_kun left