github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo the new compiler on the other hand can walk the QAST tree, turning what used to be multiple MAST objects into a single buffer, often using one buffer for long runs of operations 00:00
not only does total memory usage shrink from that, but the memory that is used is now mostly memory ignored by the GC; buffers of 8 bit integers instead of the MAST objects with references forming a (very flat) tree 00:01
so GC runs will also be a little bit faster
samcv timotimo, ok thanks :) 01:41
Geth MoarVM: c5391ecb10 | (Samantha McVey)++ | docs/ChangeLog
Changelog: Improve desc. on MAST changes and remove duplicate entries
08:30
MoarVM/refs/tags/2018.11: 86c41e3698 | (Samantha McVey)++ | VERSION
Update VERSION for release 2018.11
08:42
MoarVM: 86c41e3698 | (Samantha McVey)++ | VERSION
Update VERSION for release 2018.11
dogbert11 lizmat: what scores do you get when running [Tux] tests. Do you also see deteriorating numbers? 13:26
lizmat no, I haven't seen anything consistently slower since the MoarVM bumo 13:27
*bump
afk for a few hours&
dogbert11 jnthn: will there be any cool merges after 2018.11 is out 15:06
timotimo releasable6: status 15:07
releasable6 timotimo, Next release will happen when it's ready. 0 blockers. 188 out of 189 commits logged
timotimo, Details: gist.github.com/695315d507a1fbf280...8a92c90be6
timotimo oh, rakudo isn't released yet i guess
but it isn't terribly long until the next release
dogbert11 not sure if AlexDaniel has woken up properly yet :)
timotimo i'm not sure what's left for pea to become mergeable
i do know there's a lot it doesn't do yet 15:08
dogbert11 what's missing?
timotimo do you know what pea is about? 15:09
asking to see how much i should explain :)
dogbert11 isn't it about allocating stuff on the stack if certain conditions are met 15:10
that locals doesn't escape from a routine
timotimo right
well, that's escape analysis in general
partial escape analysis can be used in more cases 15:11
dogbert11 aha
what does 'partial' mean then
timotimo the trick behind it is that if the code path by which an object may escape is very rare, like when an exception is thrown that contains the object in question, but it only happens once every hundred thousand calls
then it can put a "deopt" mechanism in 15:12
that restores the actual object from all attributes that it would have had at that point if it had been allocated on the heap immediately
dogbert11 so it caters to cases where the general case wouldn't work then
timotimo aye 15:13
dogbert11 cool
timotimo with the idea being that this pattern is overwhelmingly common in perl6 code, i guess
dogbert11 what kind of speedups are we talking about in general, a couple of percent?
timotimo potentially all of the speedup forever 15:14
:P
but i really can't tell for sure
we'll probably be getting around a whole lot of Scalar allocations
dogbert11 sounds promising
timotimo and throwing out allocations has knock-on effects, of course 15:15
dogbert11 on GC I guess
timotimo having fewer useless allocations means that objects that die "early but not extremely early" have a better chance of getting thrown out before reaching gen2 15:15
and not having to gc as often in general is, of course, also a win 15:16
but just from gut feeling, those effects would be in the 0% - 1% range on typical code
dogbert11 every little bit counts 15:17
do you know if the pea work is in MoarVM only or have changes been made in nqp as well?
timotimo it's in moarvm only 15:18
dogbert11 so I should be able to take it for a spin
timotimo the mechanism will get almost all of its wins post-inline, which only spesh can really do 15:18
dogbert11 it builds, running a spectest to see how it looks 15:21
timotimo pea currently doesn't dare to do a whole lot 15:23
the mechanism that recreates the objects when necessary is currently only sketched out, not active 15:24
dogbert11 aha 15:27
spectest was clean FWIW
jnthn I've started building out the deopt bits for pea. It's tricky. :) 15:47
AlexDaniel dogbert11, jnthn: you can already merge stuff 16:23
AlexDaniel rakudo/nqp are released from release branches, so once moar release is out there's no reason to hold your stuff :) 16:23
I'm awake but a bit busy right now, rakudo will be release a bit later today I think 16:24
depending on your timezone :P
jnthn Mine ain't quite mergeable yet, alas 16:33
samcv morning 18:55
timotimo ohai 20:03
samcv nice. just got my plane ticket by email. starting my new job at booking jan 7th 20:05
[Coke] congrats! 20:15
you moving too? big changes.
tadzik nice, congrats :) 20:22
samcv yeah moving :) 20:27
lizmat samcv: so did you find a place in Amsterdam yet ? 20:35
samcv no 20:37
i have temp housing for 4 weeks so i can look when i get there
moving across the ocean is a lot of work though. many things i have left to do 20:38
lizmat 4 weeks isn't a lot to find a place in Amsterdam :-(
samcv well i can always stay in temp housing as well. i just have to pay after 4 weeks 20:39
lizmat aah... ok, so that's not too bad then 20:47
timotimo woohoo i found an optimization opportunity in Match's !MATCH ... though it is an extraordinarily tiny one 21:20
lizmat any tiny ones there will help all regexes and stuff that use regexes under the hood, right ? 21:22
timotimo would you look at that. !MATCH doesn't get jitted because coerce_sI isn't jitted 21:24
lizmat not because of its size /
?
timotimo we jit frames of pretty much any size 21:25
it's getting stuff inlined that can be prevented by size
lizmat ah, yes, :-)
timotimo if you want to know my tremendous optimization idea: 21:27
github.com/rakudo/rakudo/blob/mast...ch.pm6#L48
move the line $onlyname = $name if nqp::iseq_i($namecount, 1);
after the block it's currently in
lizmat timotimo: why not before ? 21:30
timotimo because by that time $name isn't set yet
lizmat ah, yeah
timotimo then the nqp::shift($iter) would have to be moved, too
perhaps it's worth it, but i went with the smallest change first
frame size of !MATCH went from 1212 bytes (28 from inlines) down to 1100 bytes (14 from inlines) 21:31
^- one sink call less
because, believe it or not, the assignment was causing a string to be boxed just so it could be sunk
which is ... sadface
lizmat so, turning that into NQP code with have inhibited the boxing ? 21:32
because it would then not be sunk ?
timotimo the frame used to need 34 registers and 23 spesh slots, now it only needs 26 registers and 19 spesh slots
not sure, actually
perhaps that's an opportunity that can be found in many more places, though 21:33
lizmat yeah, I was thinking that all of the postfix "if"s should be checked for that
m: sub foo(Str $a) { }; my Int $b = 42; foo($b) # wow, didn't know this was actually also a compile time error 21:40
camelia ===SORRY!=== Error while compiling <tmp>
Calling foo(Int) will never work with declared signature (Str $a)
at <tmp>:1
------> sub foo(Str $a) { }; my Int $b = 42; ⏏foo($b) # wow, didn't know this was actu
timotimo interesting, that fromstr_I there immediately turns into a decont_I, i.e. the bigint that gets created immediately gets truncated back to a 64bit integer
yeah, the compile-time dispatch/evaluation analyzer part of the optimizer does that 21:41
lizmat m: my Int $b = "foo" # then why isn't this a compile time error ?
camelia Type check failed in assignment to $b; expected Int but got Str ("foo")
in block <unit> at <tmp> line 1
timotimo not sure 21:42
lizmat it codegens as a WVal(Str) 21:43
I guess it's a NYI
timotimo hooray, the coerce_sI now gets a p6oget_bi instead of a generic decont_i
we might perhaps want to have nqp::clone($empty_list) instead of [] in there, since it gets code-genned as a full call to &circumfix:<[ ]> 21:45
lizmat but then it wouldn't be an Array when it gets HLLized ? 21:47
lizmat timotimo: perhaps a nqp::create(Array) would be more appropriate ? 21:48
timotimo $empty_list has to have the right thing in it of course
timotimo true. whatever's right there, really %) 21:48
lizmat fwiw, I think that whole piece of code could use a refactor 21:49
but I won't have time for that until next week
lizmat busy writing blog posts, PM meetings + visiting people and having people visiting :-) 21:49
timotimo OK! 21:50
do you know of a way to force that block to be invoked in void context? because right now it's returning a string object some of the time, which it wouldn't have to, IMO 21:51
lizmat you mean the if block ? 21:53
timotimo yes
with an nqp::if perhaps?
lizmat yup, that would do it afaik
or perhaps a --> Nil in the signature ?
timotimo i'll try that first 21:54
lizmat -> --> Nil actually :-) 21:56
timotimo aye 21:57
it's 1166 bytes big now for some reason :( 21:58
lizmat ok, nqp::if it is then :-) 21:59
timotimo it's actually doing a return_o of Nil now
and it's doing invoke_v of the sink method it expects on $name
so maybe if i turn the ?? !! into an nqp::if it won't try to sink $name
lizmat goes off for some early sleep& 22:02
timotimo good night and rest well :)
replacing the ?? !! didn't do it, alas 22:08
Geth MoarVM: c2952f9e24 | (Timo Paulssen)++ | src/jit/graph.c
JIT Compile coerce_sI Op
22:18
MoarVM: c2640e1dc6 | (Timo Paulssen)++ | src/spesh/facts.c
Discover Type Facts of coerce_sI Op