github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo lizmat: i wonder what you mean in the weekly by "looking forward to when this hits master" 01:21
Geth_ MoarVM/informative_deopt_profile: d188b7a22f | (Timo Paulssen)++ | 12 files
WIP on storing more data about deopts
 02:10
Geth_ MoarVM/pea: 15 commits pushed by (Jonathan Worthington)++, (Carl Masak)++
review: github.com/MoarVM/MoarVM/compare/d...51f33e5a6d		 15:22
jnthn Rebase, to keep atop of master :)
Geth_ MoarVM/pea: 8e85c3947e | (Jonathan Worthington)++ | 4 files
Add an envvar to turn PEA on/off
 15:44
jnthn Anyone seen a "MoarVM oops: Spesh: failed to fix up inline 4 (last) 902 -1" lately? 15:49
timotimo only with --profile, and very rarely 15:50
jnthn After rebase of pea atop of master, and my lexical => local lowering atop of Rakudo master, I suddenly have some new cases of this (probably all the same root cause)
All in spectest
lizmat fwiw, not seen those in a long time
jnthn Disabling PEA doesn't help, so it can't just be that
It's in Spesh of '' (cuid: 12163, file: SETTING::src/core/operators.pm6:177) 15:51
Which is part of SEQUENCE 15:52
timotimo i, for one, would love to know how a b0rked object enters an object register purely by virtue of having had my prof_guard* ops substituted in for the regular guard_* ops; it happens after profiling has ended, but moar no longer tries to change code back when it hits the end of the profile
jnthn Goodness this thing has big PHIs...
timotimo .o( i like big BBs and i cannot PHI )
jnthn :P 15:53
Yeah, the Inline End annotation really has gone amiss
lizmat jnthn: permission to refactor SEQUENCE ? 15:54
:-)
timotimo the current SEQUENCE will have served its purpose once this code gen / optimization bug has been fixed ;)
lizmat okidoki
jnthn lizmat: I think it was TimToady++ who wrote most of it 15:55
timotimo (not serious)
lizmat yeah, before we had modern day iterators
timotimo those were simpler times
lizmat (and slower times) 15:56
m: dd a => 42 <<+>> b => 666 # what should that give ? 16:01
camelia Cannot modify an immutable Pair (Nil => Nil)
in block <unit> at <tmp> line 1
Geth_ MoarVM/pea: d1d6fbe0d9 | (Jonathan Worthington)++ | src/spesh/dead_bb_elimination.c
Fix inline end annotation motion on BB deletion

So that the end annotation does not get lost. This can happen if the last block(s) of an inline become unreachable.		 16:11
jnthn That fixes it. Maybe it'll eliminate timotimo++'s cases of seeing that bug too. :) 16:13
And now I'm back to the one test failure in my lexical to local lowering branch that I've no clue how I'm going to fix :)
nwc10 jnthn: master is somewhat in a state of sin currently 16:15
(re-running
timotimo don't forget to cherry-pick it into moarvm/master
jnthn nwc10: How so? 16:16
nwc10 t/nqp/033-init.t t/nqp/081-radix.t t/nqp/101-lexpad-stuff.t fail 16:17
MoarVM panic: Register types do not match between value and node
jnthn timotimo: My branch did a change to fix succ fixup after the optimization of a throw into a goto
nwc10 MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
#define MVM_ARRAY_CONC_DEBUG 1 16:18
#define FSA_SIZE_DEBUG 1
jnthn timotimo: I don't believe the thing I just fixed could possibly have happened before I fixed that, since the BB won't have been considered dead.
nwc10 #define MVM_SPESH_CHECK_DU 1
(and ASAN, but ASAN does not comment_
and I need to go eat, I'm told
timotimo in that case i don't know how fixing it only in pea would get rid of my cases of seeing that bug :)
or i might misunderstand just in general
today is not a "brain is working" day
nwc10 jnthn: I don't know how to be more helpful in further diagnosis or attempting to locate the root cause 16:19
(and I need to be afk)
jnthn timotimo: Ho, good point. Unless there's something in the profiler that could trigger a similar case? Dunno. 16:20
jnthn releasable6: status 17:12
releasable6 jnthn, Next release in ≈4 days and ≈1 hour. 3 blockers. 0 out of 125 commits logged
jnthn, Details: gist.github.com/68a9fc75f164aaad4d...75b843fc1a
dogbert17 .seen brrt 18:50
yoleaux I saw brrt 8 Nov 2018 19:58Z in #moarvm: <brrt> \o
timotimo a random piece of code i'm looking at: 19:11
the code is ((Bool.pick ?? Tree !! Empty) xx $!width) xx $!height
or so
pro: the &infix:<xx> call actually inlines the (Bool.pick ?? Tree !! Empty) inside itself
that's pretty cool
but a missed opportunity is that Tree and Empty are set in two branches, then PHI-merged 19:12
but the register it gets merged into doesn't have any facts on it, and so it has a sp_guardconc following it
which could completely go if we had propagated merged flags from the phi 19:13
well, just a itsy-bitsy tiny-whiny thing i stumbled upon
timotimo i'm not quite sure why the After: section has so many empty BBs still left 19:25
jnthn timotimo: I'm not sure what facts those two would have in common? 19:40
timotimo type and concreteness
jnthn Tree and Empty are of different types, no?
timotimo oh
not in this program :)
jnthn m: say Empty.DEFINITE
camelia True
timotimo m: enum <Empty Tree Heating Burning>; say Empty.^mro 19:41
camelia (() (Int) (Cool) (Any) (Mu))
jnthn Is Tree also .DEFINITE?
Oh...not *that* Empty :)
Yeah, OK, then I dunno why it doesn't merge
timotimo yes, it is
could be an order-of-operations problem again
as always :)
append @foo: 1, 2; is sloooowww. if @foo is an int16 array it's 1/6th faster. if you push twice instead it's like 100x faster, maybe more 19:42
it's hard to measure that because you have a list that grows a whole bunch, and gc could become a big part of your run time
and assigning Empty over and over must not become a major time sink either 19:43
lizmat: wanna investigate if appending a couple of elements into an array could be made a bunch faster? :) 19:45
lizmat like Array.push ?
timotimo specifically @foo.append: 1, 2
versus @foo.push: 1; @foo.push: 2; 19:46
lizmat ok, tell me
timotimo m: my int16 @foo; for ^1_000 { @foo = Empty; for ^1_000 { append @foo: 1, 2; } }; say now - ENTER now
camelia 4.58774029
timotimo m: my int16 @foo; for ^1_000 { @foo = Empty; for ^1_000 { push @foo: 1; push @foo: 2; } }; say now - ENTER now
camelia 0.08808437
timotimo m: my int16 @foo; for ^1_000 { @foo = Empty; for ^1_000 { append @foo, 1, 2; } }; say now - ENTER now 19:47
^- much worse
camelia 12.9074396 19:47
timotimo that's the sub form, instead of the method form
so perhaps you're in the mood for a commit with "make append 100x faster" in it ):
timotimo if not, maybe i'll have a look 19:48
lizmat is looking 19:49
timotimo: also, if you're timing with for loops, add -> int $_ 19:50
that will remove the noise of the Int's being made for $_ on each iterationn
timotimo ah
m: my int16 @foo; for ^1_000 -> int $_ { @foo = Empty; for ^1_000 -> int $_ { append @foo, 1, 2; } }; say now - ENTER now
camelia 13.1483053
timotimo m: my int16 @foo; for ^1_000 -> int $ { @foo = Empty; for ^1_000 -> int $ { append @foo, 1, 2; } }; say now - ENTER now 19:51
camelia 13.33780948
timotimo not in this case apparently?
lizmat int $_
timotimo that's what i tried first
lizmat m: for ^10_000_000 { }; say now - ENTER now 19:52
camelia 0.2908868
lizmat m: for ^10_000_000 -> int $_ { }; say now - ENTER now
camelia 1.37746726
timotimo whoops! 19:53
lizmat huh?
m: for ^10_000_000 -> int $_ { }; say now - ENTER now
camelia 1.36683639
lizmat $ 6 'for ^10_000_000 { }; say now - ENTER now'
0.299314
$ 6 'for ^10_000_000 -> int $_ { }; say now - ENTER now'
0.0917367
m: for ^10_000_000 -> int $_ { }; say now - ENTER now
camelia 1.333836
lizmat m: for ^10_000_000 { }; say now - ENTER now
camelia 0.2944897
lizmat weird
timotimo anyway, the append i have in this code, which is rc-forest-fire, spends a bunch of its time in Array's append-list (Array.pm6:750), and another chunk in from-slurpy 19:54
and a tiny sliver in is-lazy
lizmat well, I'm about to go afk for a double helping of Fantastic Beasts
timotimo but the program itself spends only a miniscule amount actually appending double-values anyway
so it won't be a big help for performance in this case
lizmat so it'll be tomorrow for me 19:55
timotimo no problem 19:56
enjoy the movies! :)
lizmat I will!
timotimo oh, merge_bbs is commented out, probably only in the pea branch 23:29

Powered by Cro and the Raku® Programming Language.

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

Thank you!