| IRC logs at
Set by AlexDaniel on 12 June 2018.
04:14 AlexDani` joined 04:18 AlexDaniel left 06:09 domidumont joined 06:57 robertle joined 07:38 zakharyas joined 08:33 AlexDani` left 08:34 AlexDani` joined 09:29 domidumont left 10:14 domidumont joined 10:27 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 11:31 zakharyas left 11:45 discord61 joined, discord61 left, discord61 joined 11:46 discord6 left 11:47 discord61 is now known as discord6 11:55 domidumont left 11:56 domidumont joined 12:01 brrt` joined
brrt` \o 12:36
12:36 brrt` is now known as brrt
brrt so I've decided I'm going to start a full rewrite of the JIT. 12:36
In Rust.
lizmat yet another Perl 6 Weekly hits the Net: 12:40
timotimo brrt: i might rewrite the debugger protocol to just be perl6 code that you have to evaluate to get the data structure composed 12:42
brrt .oO( Not sure if kidding ... ) 12:43
timotimo it's like JSONP 12:44
so ... JSONP6 i guess?
brrt lol 12:46
honestly though..... an interpreter that would be just a bit more tuned to the needs of the JIT... that'd be nice 12:47
fewer functions calls 12:48
nwc10 brrt: is MoarVM structured well enough that one could write the JIT in NQP? 12:49
timotimo then we'd have to port dynasm to nqp, too? 12:50
well, that or minilua in nqp
nwc10 thanks, that's an answer
brrt well, or output x86 bytecode in nqp 12:51
nwc10: it's a difficult question, actually 12:52
could it be made to work? surely
would it be reliable? probably not
nwc10 ah OK. that ("reliable") is an excellent reason
I was thinking "is it easier in the long run?" and it seems to be "no" (where "In the long run we are all dead")
brrt and the reason why is that (imo) MoarVM inherited too much.... perlishness, parroticness, or so 12:53
too much damn C code
and C is just a little too high level
so one of the advantages of the expr JIT, for instance, is that we can refer symbolically to field offsets and struct sizes
and the C compiler fixes them up for us 12:54
and at the same time, I have all sorts of little support hacks to be sure we don't trip up a GC invariant
If I had to design the VM today, with what I've learned, I'd probably make it so that at least a write barrier would be cheaper 12:55
and I"d probably do that with some form of pointer tagging
.... and, I'd design it so that regular function calls would be cheaper 12:56
which is hard to do
but nevertheless possible, because you can always JIT something for the match between a callsite and a callee 12:57
which is already kind of what we do 12:58
more importantly, I'd start by implementing measurements 13:00
timotimo measurements? what kind are you thinking of? 13:01
brrt (all of this, by the way, is not at all a critique of MoarVM..... it's more a what-would-I-do-with-infinite-time-and-resources)
jnthn Indeed; MoarVM has largely been "what can we afford to do". :)
brrt well, I'm assuming that a calling convention that reuses the C stack would perform better than our current implementation, which uses a heap-allocated stack 13:02
but I don't know that
jnthn Well, then you get into recursion depth limits and have more fun with continuations :)
Setting up our callframes is certainly too costly, though, and that's quite visible now many other things are fairly fast. 13:03
nwc10 it has been said (forget by whom) that one of the good bits of the Perl 5 (hence Perl 1) VM design was that Perl subroutine calls don't recurse on the C stack
timotimo inlining gives us a calling convention where data is partially passed in registers :)
13:03 zakharyas joined
nwc10 implication is that you can't bust the C stack (as a SEGV type "unfortunate surprise") from recursing deeply in the language 13:03
it does break the assumptions of dtrace
brrt sure. 13:04
on the other hand, C stacks are large these days
timotimo except when you create threads :D
brrt really?
timotimo on alpine, that is
brrt oh
timotimo we had that problem when spesh would crash 13:05
brrt weird
nwc10 large, but IIRC still no portable way to know when you've exhausted it
timotimo we were able to greatly reduce the size of frames that are left on the stack when spesh recurses
brrt nwc10: true, true 13:08
well, alternatively, you can go so far as allocate your own stack frames via mmap 13:09
not sure how far you should take such a thing
timotimo so brrt what did you mean by measurements? 13:11
brrt and the other question is... for whom is the perl6 VM?
timotimo: basically, detailed knowledge of how the internals perform 13:12
timotimo sounds like you want to put Tracy into moarvm
*hint hint* 13:13
brrt hehe
what's Tracy?
timotimo it's good, it's fast, it has a snazzy GUI 13:15
basically telemeh, except good, and maintained by someone else
brrt well, it is also a first name, so it's not really very googleable 13:17
timotimo hold on
brrt oh, and bloody *tests*. I'm kicking myself for not adding tests to the MoarVM JIT yet
timotimo aye 13:18
nwc10 ooh, runs on both kinds of CPU, x86 and ARM :-)
timotimo lol
brrt btw, there's been zero interest in the jit-testing proposal so far
so I'm going to probably do that in some weekend
.oO( Sure bitbucket, I care so much about your api's )
timotimo yeah
nwc10 off topic - best use of "bloody" seen recently:
timotimo that is a really annoying popup
brrt it is cool, yes 13:20
timotimo i wanted to look into putting tracy into moarvm last week but i'd have to do some build system changes, since it's a C++ project with an optional C API 13:21
and i've still got so much other stuff to do that i'd already started, some of which would be paid for :) 13:22
not trying to say "you have too much free time, you do it for me"
brrt I have too little free time :-( 13:24
timotimo ;(
brrt don't we all
14:10 domidumont1 joined 14:13 domidumont left 14:34 lucasb joined 15:24 robertle left 15:39 brrt left 15:59 zakharyas left 16:37 domidumont joined 16:40 domidumont1 left 17:11 robertle joined 17:25 domidumont left 19:32 AlexDaniel left 20:44 brrt joined 21:20 robertle left 21:24 lucasb left 21:47 brrt left 22:45 dogbert17 left 22:54 dogbert17 joined 23:56 samcv left 23:59 samcv joined