github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 scovit_ left
timotimo the highly important of "while ++$i { }" is strongly impacted by this. $i++ as well, but not as strongly (it was faster to begin with) 00:01
AlexDaniel: what do you think about this commit? compare with these two graphs: gist.github.com/Whateverable/d4766...1cb7f440fb / gist.github.com/Whateverable/1f5f9...35fcf4db60 00:06
the commit that bumps up both graphs is the same one, c2db40b 00:07
an NQP bump, which brings an MVM bump that moves the speshresolve handling into optimize phase; i think it used to be earlier, which would explain why we would have optimized the result before but not now 00:08
AlexDaniel c2db40b ? 00:09
we're not talking about this? github.com/rakudo/rakudo/commit/c2db40b 00:10
timotimo sorry, the one before that
5cf0afce02c
AlexDaniel bench: 5cf0afce02c^,5cf0afce02c my $i; while $i++ < 5_000_000 {} 00:11
benchable6 AlexDaniel, starting to benchmark the 2 given commits
AlexDaniel, ¦5cf0afce02c^: «0.6815» ¦5cf0afc: «0.8724»
AlexDaniel, No new data found
AlexDaniel timotimo: so what can we do about it? 00:13
timotimo cherry-pick the commit i made above 00:14
AlexDaniel timotimo: I see. Well, the situation is that there are still blockers to resolve, and I will be running toaster at least once 00:16
so by merging that in we're not exactly sneaking it into the release
timotimo i'd be delighted if it made it in, and hopeful that it breaks nothing 00:18
AlexDaniel I think if it breaks something badly we'll definitely notice, and if mildly then even if it was one or two weeks earlier we perhaps wouldn't notice :) 00:20
timotimo we do use spesh plugins in many places
AlexDaniel timotimo: I can't really understand the last sentence in your comment though
“so we remember the previous instruction and see to it that we run across the new instructions” 00:21
but yeah, go ahead and put it in, and fwiw you'll have a few days to rethink that :) 00:23
the commit also makes sense, even if to my untrained eye 00:28
and recently someone was saying that things got a bit slower, maybe that's related 00:29
00:30 lizmat left
MasterDuke if we've still got some time before the release, what about github.com/MoarVM/MoarVM/pull/915 ? 00:36
timotimo i don't see a problem with it 00:42
MasterDuke: would you rename the MVMObject *result argument in the bigintops.h?
AlexDaniel IMO there's no need to rush with it unless it results in huge perf improvements 00:43
timotimo i'll leave that as a review
AlexDaniel timo's commit is different because it undoes a noticeable slowdown
MasterDuke true, there isn't a huge benefit. waiting is fine
timotimo increased amounts of inlining (such as the changes throughout the month have given us) will cause jit bails to impact performance more 00:44
MasterDuke and timotimo++ good suggestion
AlexDaniel 💤 00:45
MasterDuke when did codefactor get added to our CI pipeline? 00:50
Geth MoarVM: 389a3a10fc | (Timo Paulssen)++ | src/spesh/optimize.c
Make sure output of spesh resolve gets optimized, too

Until now we'd have resumed optimization after the last instruction a speshresolve has put in. This misses the opportunity to improve getattr faux-guards into direct pointer access versions.
Fix this by remembering the previous instruction before speshresolve is optimized and continuing with that instruction. The next thing in the loop is to go to ins->next, so we use prev->prev.
timotimo i deleted the post-release branch again
MoarVM: ebf0464e00 | (Timo Paulssen)++ | src/spesh/optimize.c
be extra careful about prev

a speshresolve being the first instruction in a BB could cause a null pointer deref here.		 00:52
timotimo i wonder if the code should instead find the prepargs instruction before the speshresolve and get the instruction before that to hold on to 00:55
since the prev instruction to the speshresolve will be the args_* that get deleted 00:57
the way it's written now it probably depends on how exactly those get removed/replaced 01:03
i'll go have a sleep first. 01:04
surely jnthn will have something to say tomorrow
MasterDuke later...
timotimo l8r 2.0 beta 01:05
01:23 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'be extra careful about prev 01:23
travis-ci.org/MoarVM/MoarVM/builds/407406171 github.com/MoarVM/MoarVM/compare/3...f0464e0036
01:23 travis-ci left 01:33 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'be extra careful about prev 01:33
travis-ci.org/MoarVM/MoarVM/builds/407406171 github.com/MoarVM/MoarVM/compare/3...f0464e0036
01:33 travis-ci left
MasterDuke seems to die on t/nqp/019-file-ops.t when built with clang 02:18
i've been running it in valgrind and gdb locally, but nothing so far
04:09 undersightable6 joined 04:45 Kaiepi left 05:18 brrt joined
brrt \o 05:44
06:18 robertle joined 07:21 domidumont joined 07:27 domidumont left 07:28 domidumont joined 07:40 brrt left 08:35 lizmat joined 08:51 diakopter left
jnthn timotimo: Hmm, interesting; we used to insert spesh plugin guards during the facts phase, so this wasn't a problem. I guess the change you did became needed once it moved to the optimize phase, which was needed for the more granular deopt. 08:57
Geth MoarVM: 4199a95649 | (Jonathan Worthington)++ | src/6model/reprs/MVMContext.c
Enable gc_free of MVMContext

Spotted by mlschroe++.		 09:20
09:21 Redfoxmoon left 09:39 robertle left 09:42 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Enable gc_free of MVMContext 09:42
travis-ci.org/MoarVM/MoarVM/builds/407521296 github.com/MoarVM/MoarVM/compare/e...99a9564973
09:42 travis-ci left 09:47 camelia left, lizmat left 09:48 camelia joined 09:49 zakharyas joined 10:03 Kaiepi joined 10:05 squashable6 left, squashable6 joined 10:09 brrt joined 10:30 squashable6 left 10:42 brrt left
timotimo jnthn: got a comment about the problem i mentioned with the speshresolve's prev instruction getting deleted in the rewrite_speshresolve step, thus we'd be relying on instructions that have been deleted still linking to the actual linked list of the BB? 10:59
jnthn timotimo: Really you need to take the instruction *before* the prepargs 11:09
And then see if there's still a prepargs after it, in which case you know it wasn't rewritten
(Because it might not be)
And if it was, then continue from the instruction now where the prepargs used to be
You can find the prepargs easily 'cus it's in the call_info data structure
timotimo ah, i see 11:10
if you look at the irc history i actually said i'd probably need to get the one before the prepargs ;)
jnthn :) 11:11
Yeah, you were right :)
But we keep it around so it's easy :) 11:12
timotimo i saw code in the speshresolve rewrite step actually go through the prev links to find the prepargs, though
perhaps that can be replaced too
or perhaps that is part of the thing that sets up call_info?
nah, i'm sure call_info comes from fact discovery 11:13
jnthn timotimo: It could be replaced now, yes. 11:14
call_info is built up in optimize_bb
The reason it wasn't used is because originally we did the speshresolve rewrite in facts
Now we do it in optimize
timotimo right
jnthn So before callinfo wasn't an option, and now it is, so yes, we can simplify things :) 11:15
timotimo i wonder if resolving ins->next at the start of the switch will give the prefetcher a better hint than what we have now 11:16
though given spesh doesn't really do computationally heavy stuff, it's quite likely it's completely memory-transfer-stalled anyway 11:17
BBL 11:38
samcv well it seems my changes actually slowed things down in siphash measurably. but i'm going to use a union instead and that should be a nice way to fix it 11:39
and not do anything weird with pointers anymore 11:40
well except for unaligned 64-bit reads, but that is handled
so the buggy compiler compiles this code correctly without having any real downsides 11:45
i still do: t.u32 = *((uint32_t*)src); where src is uint8_t*, but the compiler does that fine, so it's all good 11:47
dogbert17 jnthn: are you busy as hell or do you have time for a question? 11:49
Geth MoarVM: 5504b84421 | (Samantha McVey)++ | src/strings/siphash/csiphash.h
Use better solution to SipHash fix for GCC 4

The previous solution was slower than I would have hoped. Although it worked, using unions reduce the amount of type punning we need to do. It is also faster than the version before the fix was introduced while not triggering the compiler issue in GCC 4. It is also more elegant and nice to look at.		 12:14
MoarVM: 4c7281af44 | (Samantha McVey)++ | src/strings/siphash/csiphash.h
Add some more SipHash comments and update copyright message

Also have all #'s start at the beginning of the line. Most compilers are fine with how it was before, but some older ones have issues with them anywhere but at the start of the line.
samcv also ++ on me actually making it faster
dogbert17 samcv++ 12:29
12:35 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Add some more SipHash comments and update copyright message 12:35
travis-ci.org/MoarVM/MoarVM/builds/407580415 github.com/MoarVM/MoarVM/compare/4...7281af44f6
12:35 travis-ci left 13:05 MasterDuke left
dogbert17 I have a slight problem with the following commit github.com/MoarVM/MoarVM/commit/92...e6b8d9dd0, probably because I'm a noob :) 13:20
if I pressure the GC I can still get a failure but not in the original place, i.e. line 87, because jnthn fixed that. The failure now occurs on line 91 instead so I'm wondering if something is not rooted there which should be (test ?) 13:22
13:29 brrt joined 13:46 brrt left 13:48 robertle joined 13:59 diakopter joined 14:03 zakharyas left, zakharyas joined 14:08 zakharyas left 15:01 Redfoxmoon joined 15:19 samcv left
timotimo it'd kind of be cool to have a description that can be provided when creating a thread, so that could show up in the profiler 15:28
15:34 samcv joined
timotimo whoopsie-daisies, my cro app just segv'd 15:35
Thread 1 (Thread 0x7f632170d700 (LWP 9531)): 15:37
#0 0x00007f633f5a28f6 in ?? () from //home/timo/perl6/install/lib/libmoar.so
#1 0x0000000000000000 in ?? ()
wow, that's super helpful!
15:44 lizmat joined
timotimo i think i want to change when the orchestrate calls log_gc_end 15:44
to put it before the "wait for everybody to agree it's over" phase
that way we should get a clearer picture of the individual threads' workloads 15:45
15:59 brrt joined 16:07 domidumont left 16:12 Ven`` joined 16:25 robertle left
Geth MoarVM/pea: 8e9241f704 | (Jonathan Worthington)++ | 11 files
[WIP] Exploratory partial escape analysis impl

Developed with masak++.		 16:37
16:38 samcv left
masak waves escape-analyzingly 16:39
16:40 samcv joined
timotimo is that the one from years ago? 16:42
jnthn timotimo: No, different algorithm, this time aimed at doing partial escape analysis 16:45
16:52 brrt left
timotimo i assume there's some kind of limit on how many cases we can analyze with that? but the trade-off makes it worthwhile anyway? 17:04
oh, if we get to materializing things as soon as they are needed, that'd let us do allocation sinking or what it's called 17:12
like, if the object is only used in a branch that is taken rarely, which could be an exception handler for example
nice.
17:27 Ven`` left 18:09 dogbert17 left 18:10 zakharyas joined 18:32 Redfoxmoon left, Redfoxmoon joined 18:33 zakharyas left 20:26 zakharyas joined 20:56 domidumont joined 21:03 domidumont left 21:07 zakharyas left
Geth MoarVM: a60e53f720 | (Timo Paulssen)++ | src/spesh/optimize.c
skip to before the prepargs instruction

we have to go ->prev->next to figure out if a different instruction has taken its place in the BB.		 21:21
21:42 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'skip to before the prepargs instruction 21:42
travis-ci.org/MoarVM/MoarVM/builds/407806531 github.com/MoarVM/MoarVM/compare/4...0e53f72031
21:42 travis-ci left
jnthn timotimo: Yeah, we're implementing an *extremely* constrained version of the algorithm first that will just handle our very artificial test case, then very gradually generalize it 21:45
timotimo: And yes, it's allocation sinking
timotimo would like to see the test case, is it a one-liner? 21:50
jnthn It's just a create, a bindattr, and a getattr 21:54
And returning what came out of the getattr
timotimo right, that makes sense 21:56
jnthn The idea being that ideally it optimizes the object away entirely 21:59
timotimo right
jnthn Once we get that to work we can liberalize it steadily in various ways
timotimo any specific paper you're working off of?
jnthn The graal partial escape analysis one mostly, though of course we have a different representation so we can't follow it exactly 22:00
But the ideas seem to map
timotimo Partial Escape Analysis and 22:02
Scalar Replacement for Java
this is the one?
jnthn ssw.jku.at/Research/Papers/Stadler1...ler_14.pdf 22:04
timotimo that's the one i have
are you +1 on changing when the GC end gets logged btw? 22:07
jnthn I didn't spot that discussion 22:09
Though it's a tricky problem in the sense that it ends at different times for different threads, depending how you measure :)
timotimo the new app shows all of 'em 22:10
jnthn ooh, nice :)
timotimo i think the old html one just takes the gc timings from the main thread 22:11
i should verify that
if i do change how it gets measured, that could throw it off more than it currently would be
the thread with id 3, which could be the spesh thread perhaps, tends to start around the time the other threads end. that's weird 22:17
imgur.com/R3dXmO4 - check it out 22:20
jnthn Ah, slow reaction time 22:33
timotimo oh, huh, deopt without "bridges" is going to frustrate this endeavour quite a bit i fear 22:40
22:52 MasterDuke joined
jnthn Which endeavor? 22:55
timotimo allocation sinking 23:01
jnthn I don't see the issue; if we deopt, the deopt process materializes the objects 23:03
MasterDuke timotimo: did you see my comment on your most recent commit? 23:04
timotimo oh, i did not
thanks for the heads-up 23:05
ah, indeed
Geth MoarVM: b8f9f85f2c | (Timo Paulssen)++ | src/spesh/optimize.c
remove superfluous line spotted by MasterDuke17++
 23:24
23:43 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'remove superfluous line spotted by MasterDuke17++' 23:43
travis-ci.org/MoarVM/MoarVM/builds/407845846 github.com/MoarVM/MoarVM/compare/a...f9f85f2c04
23:43 travis-ci left
timotimo what's wrong with t/nqp/019-file-ops.t? 23:45
MasterDuke timotimo: don't know. it's been the cause of the most recent couple of travis fails 23:51
but i couldn't repro it locally, even when running in a loop for a while
timotimo seems to be mac only? 23:52
MasterDuke looks like 23:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!