github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:11 konvertex left 00:42 lucasb left 01:21 pamplemousse left 04:19 farcas1982regreg joined 04:32 sena_kun joined 04:37 sena_kun left 04:38 sena_kun joined 06:04 Altai-man_ joined 06:06 sena_kun left 07:42 farcas1982regreg left 07:49 MasterDuke left 08:04 MasterDuke joined 08:05 sena_kun joined 08:07 Altai-man_ left 08:09 zakharyas joined 08:17 konvertex joined 09:45 squashable6 left, squashable6 joined 10:04 Altai-man_ joined 10:07 sena_kun left, MasterDuke left 10:14 patrickb joined
Geth MoarVM: e4ff694954 | (Vittore F. Scolari)++ (committed using GitHub Web editor) | src/6model/reprs/CStruct.c
Setup inlined CStruct assigned during construction

Fixes github.com/rakudo/rakudo/issues/3687		 10:18
MoarVM: 3605efdbf9 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/6model/reprs/CStruct.c
Merge pull request #1285 from scovit/patch-1

Setup inlined CStruct bound during construction
lizmat argh... I thought this was a rakudo PR 10:19
lizmat promised jnthn to not do any significant MoarVM merges anymore
nine It's probably OK anyway. I did have a look, just didn't have the time to test myself
lizmat yeah, I was going by your approval 10:20
nwc10 lizmat: can you delegate drinking coffee to Wendy, and just sniff the fumes? :-)
lizmat that would not be good, as Wendy response to drinking coffee is unconsciousness and falling to the floor 10:21
for real
and I can't handle coffee anymore either, gives me the shakes
nwc10 Ooh oerk.
lizmat used to drink 1.5l of coffee before I went cold turkey 10:22
*a day
nwc10 that's a lot
lizmat yeah, I know, I used to have to drink a cuppa at 11pm, otherwise I couldn't sleep
go figure
11:18 zakharyas left 11:24 MasterDuke joined
jnthn So...back to the dispatch fun 11:49
11:49 patrickb left
lizmat ++jnthn 11:51
jnthn Something I've done has made a couple of segvs in `make test` in Rakudo. Hmm. 11:52
lizmat aren't those the easiest to fix ?
jnthn Not really :)
NQP ones are far more minimal :)
It's better than CORE.setting compilation blowing up, though 11:53
lizmat yeah, that *is* a pain /me knows from bitter experience
11:54 patrickb joined
jnthn ooh...I guess I know what it is after all 11:56
Disabling spesh fixes it, and yeah, I didn't update spesh yet to cope with the getlexstatic_o leftbehind case 11:57
nine Intresting that it even got so far then
jnthn Well, getlexstatic_o is normally eliminated by spesh
So this only comes up when we hit it *after* specialization 11:58
My work will actually make that case faster :)
(As well as the pre-spesh cases of it faster) 11:59
Guess I'll sort this out now, before I did into the big call stack changes.
Which I've realized doing anything else non-cheaty bottlenecks on.
MasterDuke anybody have any further comments/suggestions on github.com/MoarVM/MoarVM/pull/1281 or is it ready to merge? 12:05
tellable6 hey MasterDuke, you have a message: gist.github.com/e6d9e6fc41b40ae537...6461267cd8
12:05 sena_kun joined 12:07 Altai-man_ left
nine MasterDuke: I'd like jnthn's to weigh in on whether our assumptions are ok 12:07
MasterDuke ah yes, good idea
i'll also add github.com/MoarVM/MoarVM/pull/689 to the list for pinging about 12:08
12:10 patrickb left 12:31 samcv left, samcv joined 13:42 pamplemousse joined 13:44 MasterDuke left 13:52 MasterDuke joined
Geth MoarVM/new-disp: e9dc16fe7e | (Jonathan Worthington)++ | 17 files
Use inline cache for spesh of getlexstatic

Eliminating the logging approach that used to be used for this along the way. We now also introduce a specialized version of the op that can take advantage of the inline cache and is inlineable, meaning that unresolved getlexstatic_o instructions are no longer an inlining blocker, which may help code that would otherwise be possible to inline except for, for instance, an unused `die` path.		 13:54
jnthn And with that, Rakudo's make test is clean again 13:55
14:04 Altai-man_ joined 14:07 sena_kun left
Geth MoarVM/new-disp: b392f6fb25 | (Jonathan Worthington)++ | src/spesh/deopt.c
Tweak deopt to indicate a legacy callsite
 14:08
nwc10 jnthn: your beer fridge is locked and loaded? Or at least, loaded and not at risk of theft? :-)
jnthn Yes, though also at home :) 14:09
jnthn rebases his branches so he can get a spectest run that doesn't have failures 'cus his Rakudo is behind...
nwc10 mmm, I can't figure an alterantive POETS where the TS and imply beer. I can sort of manage Thirst, but S is beyond me. 14:10
grammar
my grammar, that is
jnthn
.oO( Thirsty Slacker )
 14:11
nwc10 that works quite well, but it's more of an instruction to $other than a report on $self 14:12
but you're better at this than I am, it seems.
Geth MoarVM/new-disp: 15 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/b...3e9484ffd9
jnthn ^ rebase
I'm about to start breaking stuff again, but would like to know what I'm breaking. :) 14:13
ooh, make spectest is actually clean 14:16
MasterDuke nice
nwc10 "That's a very nice clean spectest. Shame if anything were to happen to it..." 14:17
jnthn What I've done so far is mostly plumbing for dispatch, but I moved getlexstatic to use the new inline cache mechanism and got it to spesh via. that.
Which lets me exercise a bunch of the code paths that are generic over that and the new dispatch op. 14:18
nwc10 was about to type soemthing like that as a question. You're faster than me.
did not remember the new dispatch op.
jnthn It's actually a slight improvement on what we had before for getlexstatic too; it caches the outcome even in the interpreted case 14:19
nwc10 it's faster? Ship it!
jnthn Yes, but other things might be slower, due to the transitional state of callsite/args handling. 14:20
Plus I know there's a memory leak in part of that
Altai-man_ .oO ( half ship it! )
jnthn Anyway, even without merging the stuff back, it's nice to have stable intermediate points.
nwc10 I doubt that half-ships are very water tight. 14:21
jnthn Hm, these callstack changes will be...fun... 14:23
I'll have to touch deopt
MasterDuke jnthn: setmethcache will go away completely after your work is done, right? 14:26
jnthn Yes, that's the idea
MasterDuke same with settypecache? 14:27
jnthn No, that one ain't being touched.
MasterDuke ah. they both cause a bunch of jit bails, but setmethcache more so, so glad to see it's going away
jnthn It's unrelated to dispatch, and also not anything like so much of a bother. 14:28
In so far as it's normally quite small and also serializes more compactly and uses less memory
But yeah, don't spend time jitting setmethcache :)
You can write a JIT of sp_getlexstatic_o if you like :) 14:29
(in my branch)
MasterDuke there are also a bunch of sp_get* that are missing templates. in general, think there's any reason those couldn't have templates
oh, and is prepargs getting touched? 14:32
nine yes 14:34
timotimo when building something like Grammar::Tracer, would it be reasonable to build a dispatcher plugin thingie for that, or is that the wrong hook to hang that off of?
jnthn MasterDuke: prepargs will probably go away
timotimo: I think dispatcher plugins are always going to be VM-specific, so I'd not do it that way. 14:35
MasterDuke nice. causes the most template bails by far (7k vs 2k for next most) when building rakudo
timotimo ah, fair
MasterDuke: well that's because the exprjit has no implementation of invocation at all 14:36
jnthn MasterDuke: Well, they might all move to being a template bail on the `dispatch` op in the immediate... :)
Because...what timotimo said, it's a symptom of something bigger
timotimo prepargs, arg_*, and *invoke* should be thought of as a single op
jnthn otoh, better to do that part once we have the dispatch op
timotimo: yes, which is what is happening :D 14:37
timotimo yep!
jnthn So it should hopefully be far easier to do the templating of
It's nice how many things the new design seems to be making easier, that I hadn't actually thought of it helping with up front :)
timotimo would not have thought var-arg opcodes would be simple 14:40
jnthn You don't actually need to JIT anything at all for the args
You just need a pointer to a piece of memory holding the indices
Well, and to make sure they're written into ->work 14:41
MasterDuke timotimo: is github.com/MoarVM/MoarVM/blob/mast...ent.c#L937 necessary? it's throwing a compiler warning about unused variable i
timotimo nah, all those commented-out lines as well as mark_call_graph_node can go 14:42
MasterDuke k 14:45
timotimo also the ones at the top with the node list functions 14:51
MasterDuke jnthn: on the new-disp branch, the interp.c implementation of getlexstatic_o and the emit.dasc implementation look quite a bit different (seems like emit.dasc is same as master) 14:52
Geth MoarVM/new-disp: b146ff4f2c | (Jonathan Worthington)++ | 3 files
Remove JIT of getlexstatic_o

It *always* gets rewritten by spesh now, either into a spesh slot access or into sp_getlexstatic_o.		 14:54
jnthn Thanks. That should never reach the JIT (or specialized code, in fact)
15:10 zakharyas joined
MasterDuke how do i do `(*ptr)->func()` in emit.dasc? 15:45
jnthn the deref is probably a mov, probably into the FUNCTION register, iirc 15:55
And then you're ready to call it 15:56
I guess mov FUNCTION, ptr[0] does it (where ptr is actually the register you've got the pointer in) 15:58
I'm guessing you're doing the MVM_disp_inline_cache_get_spesh function in assembly do, since it's probably just a few instructions (and so shorter than a function call sequence) 15:59
*too
MasterDuke hadn't realized that, so was doing a call. i'll change it 16:00
16:05 sena_kun joined 16:07 Altai-man_ left
nine I just realized that new-disp will probably reduce the need for extops by half. And the other half of p6 extops look fairly pretty non-raku specific to me 16:18
jnthn Yup :)
And I already moved the Rakudo scalar container spec into MoarVM. So... 16:19
[Coke] would removing extops support (not just removing rakudo's ext ops) help performance? 16:24
jnthn Probably not a lot, though it would simplify some code 16:41
And save perhaps a tiny bit of memory
[Coke] Is it a goal to remove it from MoarVM? Or just the usage from rakudo? 16:42
jnthn May as well have the simplification 16:44
[Coke] jnthn++
jnthn Realized that I can probably make continuations a bit cheaper as part of this also 16:46
Home time...still a few more bits to do tomorrow to get back to "MoarVM compiles", and hopefully not too much debugging until "and it builds NQP also" 17:05
18:04 Altai-man_ joined 18:06 sena_kun left 18:28 pamplemousse left
nine How does a closure's static frame usually and up in the serialization context? 18:43
18:50 vrurg joined
jnthn nine: uh...that broke my parser 18:51
nwc10 jnthn: fix it with beer? (and I thought that the sentence made sense, but I don't know any implementation context to know why it's a strange thing to ask) 18:52
jnthn oh, s/and/end/ !
nwc10 aha
nine Well I'm running into "missing static code ref for closure ''" issues for seemingly random (but reproducible) closures triggered by compiling stuff at BEGIN time
nwc10 I failed to even spot the typo
nine oh, yes, end :)
nwc10 I slack!
jnthn nine: static code ref != static frame, but rather an MVMCode that points to the static frame. For those, typically the compiler does, iirc, freshcoderef, and marks it as a static code ref and adds it to the serialization context 18:53
freshcoderef produces a fresh static frame 18:54
This object stands in for the code ref we'll eventually produce
That's in the compilation case. 18:56
nine That would bring me back to finish_code_object (or NQP's create_code).
jnthn Yes.
When we are a precomp, then the code refs are the "real" ones
But also, in a non-precomp case, the code refs are not the real thing 18:57
Which we eventually produce
So we also need to deal with closure clones of those
I wonder if some update of the closures is not happening
nine At first I thought that maybe mast_frames get overwritten (via conflicting cuids between the outer and inner compilation) but I can rule that out now 18:58
jnthn github.com/rakudo/rakudo/blob/mast....nqp#L2654 maybe 18:59
dinner, bbiab 19:00
nine The thing is, it's complaining about this closure: github.com/rakudo/rakudo/blob/mast....nqp#L3363
The { $obj.HOW.compose($obj, :$compiler_services) } in Perl6::World::pkg_compose 19:01
MasterDuke is there a particular reason these are named `*_ui*` here github.com/MoarVM/MoarVM/blob/mast...aph.h#L219 instead of `*_u*`? 19:14
that looks to be the only place we use `ui` instead of just `u` 19:16
gist.github.com/MasterDuke17/c505c...53c47f048c is what i have so far, but gcc errors that `‘*0’ is a pointer; did you mean to use ‘->’?` (and also warns that `slot` is unused) 19:27
www.erlang-solutions.com/blog/opti...hines.html people might find this interesting 19:29
nine MasterDuke: I think it should be MVMDispInlineCacheEntry not MVMDispInlineCacheEntry* 19:36
MasterDuke hm, i had some reason i thought it should be *, but it looks like whatever it was was incorrect 19:40
doh, still getting bails, but forgot to add a case for it to add_primitive 19:42
heh, and now segvs... 19:44
nine
.oO(the usual progression)
MasterDuke in MVM_jit_emit_primitive, that's a new one for me 19:46
lizmat
.oO( primal scream )
 19:51
20:05 sena_kun joined 20:06 Altai-man_ left
MasterDuke oh, and we have `GET_UI32` instead of `GET_U32` 20:13
shouldn't it be `mov FUNCTION, [ARG2];`? still get a segv though... 20:28
nine If you do lea ARG2, MVMDISPINLINECACHEENTRYPTR:TMP2->entries[slot]; mov FUNCTION, [ARG2]; you may as well do mov ARG2, MVMDISPINLINECACHEENTRYPTR:TMP2->entries[slot]; mov FUNCTION, ARG2; instead 20:32
Or mov FUNCTION, MVMDISPINLINECACHEENTRYPTR:TMP2->entries[slot];
And I wonder if that couldn't be mov FUNCTION, STATICFRAME:TMP1->body.inline_cache->entries[slot]; 20:34
Oh, no, because that'd be 2 dereferences
20:38 Altai-man_ joined 20:40 sena_kun left 20:41 MasterDuke left 21:16 zakharyas left 22:08 MasterDuke joined 22:11 Altai-man_ left
MasterDuke nine: github.com/MoarVM/MoarVM/commit/b7...R123-R5997 is what i'm trying to implement. so i want ARG2 to have the `MVMDispInlineCacheEntry **ice_ptr`, but FUNCTION to have the `(*ice_ptr)->run_getlexstatic` 22:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!