|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
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
|
|||