github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:41 Kaiepi left
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
02:53 Kaiepi joined 02:54 p6bannerbot sets mode: +v Kaiepi 06:08 Kaiepi left 06:20 lizmat left 06:24 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 07:08 domidumont joined 07:09 p6bannerbot sets mode: +v domidumont 07:36 robertle joined 07:37 p6bannerbot sets mode: +v robertle 10:45 Kaypie joined, Kaiepi left 10:46 p6bannerbot sets mode: +v Kaypie 10:57 zakharyas joined 10:58 p6bannerbot sets mode: +v zakharyas 11:00 lizmat joined, p6bannerbot sets mode: +v lizmat 11:41 zakharyas left 11:46 zakharyas joined, p6bannerbot sets mode: +v zakharyas 12:27 nebuchadnezzar left, nebuchadnezzar joined 12:28 p6bannerbot sets mode: +v nebuchadnezzar 12:36 shareable6 left, shareable6 joined 12:37 p6bannerbot sets mode: +v shareable6 12:56 dogbert17 joined 12:57 p6bannerbot sets mode: +v dogbert17 13:14 ZofBot joined, p6bannerbot sets mode: +v ZofBot 13:18 dalek left, dalek joined 13:19 p6bannerbot sets mode: +v dalek 13:30 rba joined 13:31 p6bannerbot sets mode: +v rba 14:49 MasterDuke left 15:01 zakharyas left 15:02 rba left
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 :)
15:38 greppable6 left 15:39 greppable6 joined, greppable6 left, greppable6 joined, p6bannerbot sets mode: +v greppable6 15:40 undersightable6 left, releasable6 left, bisectable6 left, squashable6 left, notable6 left, statisfiable6 left, bloatable6 left, p6bannerbot sets mode: +v greppable6, unicodable6 left, undersightable6 joined, releasable6 joined, benchable6 left, coverable6 left, bisectable6 joined, quotable6 left, notable6 joined, squashable6 joined, committable6 left, shareable6 left, notable6 left, squashable6 left, bisectable6 left, greppable6 left, evalable6 left, nativecallable6 left, committable6 joined, shareable6 joined 15:41 p6bannerbot sets mode: +v undersightable6, p6bannerbot sets mode: +v releasable6, p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v shareable6 15:43 evalable6 joined, nativecallable6 joined, greppable6 joined, notable6 joined, quotable6 joined 15:44 p6bannerbot sets mode: +v evalable6, p6bannerbot sets mode: +v nativecallable6, p6bannerbot sets mode: +v greppable6, p6bannerbot sets mode: +v notable6
Geth_ MoarVM/pea: 8e85c3947e | (Jonathan Worthington)++ | 4 files
Add an envvar to turn PEA on/off
 15:44
15:44 p6bannerbot sets mode: +v quotable6 15:46 bisectable6 joined 15:47 p6bannerbot sets mode: +v bisectable6
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
16:09 zakharyas joined, p6bannerbot sets mode: +v zakharyas
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
16:16 robertle left
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)
16:20 domidumont left
jnthn timotimo: Ho, good point. Unless there's something in the profiler that could trigger a similar case? Dunno. 16:20
16:29 zakharyas left, zakharyas joined 16:30 p6bannerbot sets mode: +v zakharyas 16:34 Kaypie left, Kaypie joined 16:35 p6bannerbot sets mode: +v Kaypie 16:40 benchable6 joined, squashable6 joined 16:41 coverable6 joined, unicodable6 joined, statisfiable6 joined, bloatable6 joined, p6bannerbot sets mode: +v benchable6, p6bannerbot sets mode: +v squashable6, p6bannerbot sets mode: +v coverable6, p6bannerbot sets mode: +v unicodable6, p6bannerbot sets mode: +v statisfiable6 16:42 p6bannerbot sets mode: +v bloatable6 16:49 zakharyas left
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
18:35 zakharyas joined 18:36 p6bannerbot sets mode: +v zakharyas 18:40 zakharyas left, zakharyas joined 18:41 p6bannerbot sets mode: +v zakharyas 18:49 emerson left
dogbert17 .seen brrt 18:50
yoleaux I saw brrt 8 Nov 2018 19:58Z in #moarvm: <brrt> \o
18:52 emerson joined, p6bannerbot sets mode: +v emerson
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
19:20 zakharyas left
timotimo i'm not quite sure why the After: section has so many empty BBs still left 19:25
19:29 robertle joined, p6bannerbot sets mode: +v robertle
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
19:47 rba joined
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 ):
19:47 p6bannerbot sets mode: +v rba
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!
20:05 Kaypie left, Kaypie joined 20:06 p6bannerbot sets mode: +v Kaypie 20:41 Kaypie left 20:43 Kaiepi joined 20:44 p6bannerbot sets mode: +v Kaiepi 20:55 Kaiepi left, Kaiepi joined 20:56 p6bannerbot sets mode: +v Kaiepi 22:08 AlexDaniel left, AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 22:09 robertle left 23:14 dogbert11 joined 23:15 p6bannerbot sets mode: +v dogbert11 23:16 dogbert17 left 23:19 Kaypie joined, p6bannerbot sets mode: +v Kaypie 23:20 Kaiepi left
timotimo oh, merge_bbs is commented out, probably only in the pea branch 23:29
23:57 emerson left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!