github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:33 lucasb left 00:39 Kaiepi left
MasterDuke ugh, i've never had much luck with asan 01:39
how does everyone else build with it?
moarvm compiled just fine, but i couldn't run my already-built rakudo, so i tried building nqp and rakudo again but the nqp build dies 01:40
some valgrind output gist.github.com/MasterDuke17/11f34...996c343c8e 01:50
moarvm was built with `--debug=3 --telemeh --valgrind --optimize=0` 01:55
.tell jnthn a question about asan, but then some valgrind output colabti.org/irclogger/irclogger_lo...9-04-12#l3 02:34
yoleaux MasterDuke: I'll pass your message to jnthn.
02:51 Kaiepi joined 04:21 Kaiepi left 05:33 robertle left 06:31 brrt joined 06:32 Kaiepi joined 06:42 domidumont joined 07:04 dalek left 07:05 dalek joined, SmokeMachine left 07:06 SmokeMachine joined, p6lert_ left, synopsebot left 07:07 Geth left 07:54 brrt left 08:10 brrt joined 08:32 zakharyas joined 08:48 brrt left 08:54 brrt joined 09:16 brrt left
jnthn morning o/ 09:18
yoleaux 02:34Z <MasterDuke> jnthn: a question about asan, but then some valgrind output colabti.org/irclogger/irclogger_lo...9-04-12#l3
jnthn No Geth here, but I just rebased more-pea 09:36
09:48 domidumont left
jnthn MasterDuke: I just pass --asan to MoarVM's Configure.pl 09:50
09:52 domidumont joined 09:55 Geth joined
Geth MoarVM/more-pea: ac00512c44 | (Jonathan Worthington)++ | src/spesh/pea.c
Fix a use-after-realloc
09:59
jnthn That gets rid of at least the bit of ASAN unhappiness with that branch that was reported
09:59 domidumont left
jnthn Now spectests clean with ASAN enabled and MVM_SPESH_BLOCKING=1 10:13
Guest16965 jnthn: does this work? MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ASAN_OPTIONS=detect_leaks=0 ./perl6 t/spec/S32-array/delete-adverb-native.t 10:59
11:01 patrickb joined
jnthn Yes 11:01
Guest16965 jnthn++ 11:26
11:53 zakharyas left
jnthn Mmm...'twas a nice Vietnamese lunch :) 12:13
Guest16965 is a merge imminent? 12:15
jnthn I did a merge this morning into Rakudo of the work to reduce the number of return handlers 12:16
m: say 14689160 - 14516680
evalable6 172480
timotimo core setting size? 12:17
jnthn 172 KB off CORE.setting size form that :)
timotimo sweet
Guest16965 rebuilds
jnthn And the JIT code for an array indexing operation shrunk by over 300 bytes too in recent changes 12:18
12:43 domidumont joined 12:45 committable6 left, committable6 joined, unicodable6 left 12:46 unicodable6 joined 12:53 domidumont1 joined 12:56 domidumont left
Geth MoarVM: c10fee65c8 | (Jonathan Worthington)++ | 9 files
Handle inlining of outer lexical binds

This is used in code using native types, and was one source of surprise slowness when using natives. For example, this:
   my num $x = 1.5e0;
   my num $y = 0e0;
... (8 more lines)
13:04
Guest16965 jnthn: did the last commit fix R#2333 by any chance? 13:14
jnthn Potentially 13:15
Guest16965 doesn't look like it 13:16
jnthn There's perhaps more going on there 13:17
Guest16965 making $total an int makes the code run at almost half speed. Odd 13:19
timotimo where does $total come from? 13:20
you mean $y?
jnthn He's talking about the code in the issue, not the one I just pasted
timotimo ah
oh, synopsebot is also not there
jnthn Well, I assume Guest16965 is dogbert... :)
13:21 synopsebot joined
timotimo R#2333 13:21
synopsebot R#2333 [open]: github.com/rakudo/rakudo/issues/2333 [performance] Unexpected perf result with native math assignment
Guest16965 jnthn: :-)
new work computer, haven't had time to set things up properly yet 13:22
timotimo does that still build NativeRef all the time?
jnthn timotimo: Probably.
Currently looking at making the EA deal with Int, which is quite tricky because it's not a straight boxing. 13:23
timotimo right
we don't have bigint as a type-ish thing
so can't go into o register
jnthn Yeah, well, my plan is to add a .bi register type that only spesh can deal with 13:24
*but* lifetime management is taking some figuring out
Since there's potentially a malloc'd object in there
And we need to not leak nor double-free those
13:27 brrt joined
Guest16965 the slow version allocates 1_000_000 IntLexRef, the fast version allocates zero IntLexRef 13:30
jnthn That'll be the answer then
timotimo aye, same as before, sadly
13:32 lucasb joined
Geth MoarVM/more-pea: eb48ea1e74 | (Jonathan Worthington)++ | 2 files
Introduce two new register kinds (spesh use only)

This is in preparation for dealing with P6bigint (and thus Perl 6 Int values) in the escape analysis. The two are:
  * Referenced big integer: big integer value that is copied out of an
   owning object
  * Owned big integer: big integer object that is currently not owned by
   any all allocated box object, and so needs to be cleared up at scope
   exit
13:51
timotimo all allocated, mhm
jnthn oops :) 13:53
13:55 zakharyas joined 14:21 brrt left 14:23 ggoebel left 14:25 domidumont joined 14:27 domidumont1 left
Geth MoarVM/more-pea: e4d5368485 | (Jonathan Worthington)++ | tools/update_ops.p6
Recognize new rbi/obi regs in op update tool
14:52
15:02 robertle joined 15:43 Woodi joined
Woodi yo 15:43
C++ have RVO optimisation and looks like using pointer to variable that will be assigned when function returns. so function do not need to create tmp value + one less copy... do we have such thing in Moar ? en.wikipedia.org/wiki/Copy_elision 15:44
jnthn Perl 6 example where such an optimization might apply? 15:51
15:52 zakharyas left
jnthn Certainly if you do things like `$foo.bar.baz` and we inline both bar and baz then the output of one can, deopt allowing, be used directly in the second without need of storing the value in the register of the caller 15:52
Not sure if that counts as such a case, though (I barely read C++ :)) 15:53
Woodi jnthn: I thinked that RVO "inlines" varible from outer func into inner func by replacing creating temp variable with pointer to container from outer... 15:55
15:55 domidumont left
Woodi but probably /me just theoretizing... 15:57
16:52 lucasb left
Geth MoarVM/more-pea: 8c2a1bad93 | (Jonathan Worthington)++ | 5 files
Stub in some proposed unboxed big int ops

These will be used as part of the big integer EA unboxing work.
17:25
MoarVM/more-pea: 5b847bdd94 | (Jonathan Worthington)++ | src/spesh/pea.c
First steps towards SR with big integers

This adds the algorithm to scalar replace various (for now, only very carefully constructed) cases of objects boxing big integers. This will not yet work; the ops it rewrites things into are unimplemented, and the freeing of any allocated big integers is not yet implemented, so they will be leaked.
timotimo hm, does that mean we'll have to have an sp variant of every big int operation, too? 17:32
wait
timotimo actually reads the commit
17:32 harrow` left
timotimo i see, there's a few of them there right now 17:33
17:36 brrt joined 17:38 harrow joined 17:46 Kaiepi left 17:52 zakharyas joined 18:38 zakharyas left
jnthn timotimo: Yes, probably, though I plan to get rid of the sp_add_I series in favor of the sp_add_bi and similar, I think... 19:10
19:42 Kaiepi joined 19:51 Kaiepi left
timotimo ah, that makes sense, can always make those by putting an unbox in front 19:58
maybe we'll be able to reason in the JIT that some bigint was actually small and we don't have to check twice in a row or something 20:02
21:11 brrt left 21:47 Kaiepi joined 23:14 patrickb left
MasterDuke jnthn, timotimo: do my valgrind outputs from last night look useful? 23:21
jnthn MasterDuke: They didn't give me any immediate guesses 23:33
MasterDuke jnthn: hmm, too bad. when you build with --asan, do you have to rebuild nqp/rakudo? 23:38
jnthn nqp, no; Rakudo it seems since the new runner, yes 23:43
Though if using ./perl6-m I think that's still the hell script
uh, *shell :D
MasterDuke ha 23:44
timotimo there is also a flag to configure that makes it not do that, iirc
"--no-relocatable" maybe 23:45
MasterDuke huh. i rebuilt moar with `--asan --compiler=clang`. trying to run perl6-m gives `./install/bin/perl6-m: symbol lookup error: /home/dan/Source/perl6/install/bin/../lib/libmoar.so: undefined symbol: __asan_option_detect_stack_use_after_return` 23:48
and then trying to rebuild rakudo gives gist.github.com/MasterDuke17/f9358...7f673775b6 23:49
same behavior in kubuntu 18.10 with clang 7.0.0-3 and arch linux with clang 8.0.0 23:53
but i've had this behavior since way before the relocatable work 23:54