github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
buggable 🎺🎺🎺 It's time for the monthly Accidental /win Lottery 😍😍😍 We have 1 ballots submitted by 1 users! DRUM ROLL PLEASE!... 00:00
And the winning number is 5! Congratulations to Ulti! You win a roll of duck tape!
ItchyPlant Hi, 08:00
By the suggestion of u/liztormato, I issued "make spectest" for Rakudo on AIX, after it successfully compiled. The results are uploaded here if you would like to investigate: gist.github.com/ItchyPlant/1900140...da3297c0d8 08:01
Also, I'm asking if these 6 failures are dead serious and I should avoid using Perl 6 on AIX. I could run any scripts on it so far, so looks working to me but there are these 6 failures... 08:10
timotimo looks like we're handling unsigned ints wrong on aix 09:16
does moar use its jit at all on aix? i.e. does anything change if you MVM_JIT_DISABLE=yes in the environment?
lizmat AIX non intel, so no JIT afaik 09:33
.oO( not looking forward to the day that the MBP will run on an A14 processor)
09:34
timotimo maybe we want to run ubsan on that to see if we're doing integer casting wrong or something 09:49
ItchyPlant do you have a script that I can run there? 09:51
timotimo you can run moarvm's Configure.pl with --ubsan 09:54
ItchyPlant Ok 09:55
ItchyPlant had to change laptop :) 10:08
is there a need to install extra RPM packages for libffi when using --ubsan? 10:11
just asking because I got this: gist.github.com/ItchyPlant/cde27e7...b94771422e
timotimo looks more like it just can't compile if ubsan is set 10:12
brrt \o 10:51
dogbert2_ hello brrt 12:14
timotimo: is there anything else I should test regarding the SEGV from yesterday? 12:18
nine By now I'm tempted to recommend always running raukdo with MVM_SPESH_LOG. It's just faster... 12:26
brrt ohai dogbert2_, nine 12:45
that is weird nine
we kind of need to figure out why the hell that is
I'm guessing that the spesh thread is blocked somehow otherwise 12:46
(but how????)
nine timotimo: is it possible that the profile only sees frames as JIT compiled if that compilation happened when the profiler was actually active? With --profile-stage there are several frames that get the JIT treatment before we even start profiling 13:59
nine And we haz performance parity! 14:55
lizmat nine++ 14:56
dogbert2_ nine++ 14:57
jnthn \o? 14:58
Speed parity and memory decrease, then? :) 14:59
[Coke] nine++ 15:03
nine Pretty sure about the memory decrease, but haven't measured it in quite a while 16:01
nine Looks like it uses 94 MiB less memory (1289 instead of 1383 MiB) 16:11
measured using /usr/bin/time -f "%M" 16:12
brrt \o 19:02
nine++
when will you merge it?
nine Need to fix compilation of nqp::xor first. That doesn't short-circuit anymore right now. Nothing difficult however. 19:50
timotimo sorry I was afk all day 20:39
whether a routine shows up as jit-called depends on which profile_enter variant is called
activating the profiler invalidates all code so far 20:40
I'm not entirely sure how that interacts, tbh. maybe it would require logging and speaking all over again 20:41
that is surely something we should investigate 20:42
Geth MoarVM: jstuder-gh++ created pull request #988:
Use arithmetic right shift in JIT of brshift_i
21:34
MoarVM: jstuder-gh++ created pull request #989:
Add exprjit integer multiplication op
21:45
timotimo a piece of perl6 code with SDL and tile-based simulation and such is now running pretty fast, or at least i think it is; i don't have the numbers from the last time i checked 23:29
jnthn Cool :) 23:30
I've no travel nor guests in November, so hoping to get some good progress in on EA and related things :)
timotimo i'm seeing something silly in Array.pm6's push method 23:40
it sets $!descriptor, then immediately reads it again (after set-ing registers around a bit) 23:41
looks like it guards on it
hm, this might be interesting 23:42
jnthn Yeah, well, that's why EA and SR :)
timotimo a sp_guard is followed right by a sp_guardjustconc
surely the second one was a guardconc that was redundant with the first guard and that's why it got turned into a guardjustconc?
jnthn Yeah, those could indeed merge into one
No, I think it's because spesh plugins let you guard type and then concreteness 23:43
And it spits out the guards as they are set
timotimo could very well be, yeah
jnthn Rather than perhaps emitting a single guard instruction
timotimo should the optimizer merge them after the fact, or should the spesh plugin code become smarter? 23:44
jnthn I'm almost certain it's that; I've pondered improving it before, but then realized after JIT it probably is a wash in terms of branch count
But otoh it probably bloats the code size
So it's wroth doing
The spesh plugin code-gen is already complex enough, I fear...though maybe there's a need way to "look ahead" or something
It's probably better to find a neat way to do it there than to do it after the fact, even if that code is getting a little involved. 23:45
timotimo too many cooks will spoil the wroth? :)
would it be all right to clean up unused spesh slots after optimization? 23:47
jnthn Hmmm
How expensive will it be? 23:48
timotimo this frame has 0 through 17, it uses 5, 7, 8, 3, 14, 13, 9, 15, 17
so a bit more than 50%
jnthn Unless we somehow track their usage as we go, it's going to be a bit costly
timotimo right, it'd have to live inside another pass
jnthn In that I think you'd have to do a pass to find usages, and then aother pass to update?
Of course you could collect the instructions that'd need updating in the first pass
timotimo re-naming, yeah
indeed 23:49
jnthn So maybe it's not so bad
timotimo will it have more benefits other than slightly less GC work and slightly less memory usage?
the spesh slots live only a single time per spesh candidate, don't they? 23:50
OK, cache locality for the spesh slots
smaller heap snapshots :D 23:51
(again, barely)
oh, don't we have some op that only mentions a single sslot, but actually also uses the spesh slot after that? 23:52
jnthn Yes, we do :)
Method caching
I think the gains would be hard to measure, honestly 23:53
timotimo that could also be kind of bad for "add spesh slot try reuse"
if the value accidentally is the same but the method cache changes at some point
and then the spesh slot expecting to have null or whatever in it ... suddenly has a method
jnthn We don't try and re-use a slot for NULL :) 23:55
Oh, and yeah, the method one would be an inlining issue 23:56
I think there's enough dragons here, and the win is too small, for it to be worth doing at this point.
timotimo right
but what do you mean "an inlining issue"?
would you want the facts list in the spesh log also show the debug_name of the known type and known deconted type? 23:57