Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-06

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:42 nwc10 joined #moarvm
00:53 kjs_ joined #moarvm
02:34 FROGGS joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
05:56 vendethiel joined #moarvm
06:42 vendethiel joined #moarvm
06:52 domidumont joined #moarvm
06:53 domidumont joined #moarvm
06:59 domidumont joined #moarvm
08:58 lizmat joined #moarvm
09:18 lizmat joined #moarvm
09:23 vendethiel joined #moarvm
09:38 lizmat joined #moarvm
09:38 mojca joined #moarvm
09:38 mojca is the following compile warning expected? src/jit/emit_x64.dasc:274:86: warning: shift count >= width of type [-Wshift-count-overflow]
09:38 mojca it's about shifting for 32 "dasm_put(Dst, 94, (unsigned int)((uintptr_t)obj), (unsigned int)(((uintptr_t)obj)>>32), Dt1E([reg]));"
09:58 kjs_ joined #moarvm
10:40 nine mojca: what platform are you on?
10:40 mojca OS X
10:41 mojca nine: x86_64 to be complete
10:41 mojca oh, wait, maybe I just forgot about recent changes
10:41 mojca but I'm not building for i386, at least not intentionally
10:42 mojca oh, wait … stupid me
10:42 mojca the warnings come from an unintentional universal build (I did just "port upgrade moarvm", forgetting that I had installed this as universal earlier)
10:43 mojca I'm sorry for the noise; I'll try again, but I think that's it
10:48 kjs_ joined #moarvm
10:53 mojca nine: indeed, sorry for the false alarm; I tried building just for x86_64 again and the warnings are gone; it was just confusing and I forgot the issue from one or two months back
10:54 nine mojca: then the warning fulfilled it's purpose :)
10:55 mojca in a sense; I would be happier if that code was simply commented out, but it's fine as it is
10:55 mojca tha code would not be used on i386 anyway
10:57 nine Is there any i386 support at all in the jit?
11:11 mojca nine: no, it's not, but it has recently been circumvented at runtime
11:11 mojca earlier it just crashed
11:12 kjs_ joined #moarvm
11:47 lizmat joined #moarvm
14:33 TimToady joined #moarvm
15:07 Ven joined #moarvm
15:21 brrt joined #moarvm
15:34 zakharyas joined #moarvm
15:34 timotimo Constructing JIT graph (cuuid: cuid_2975_1457271489.25971, name: 'infix:<*>')
15:34 timotimo BAIL: op <param_rp_n>
15:34 timotimo ^- required positional, num ... shouldn't we be able to jit this already?
15:35 timotimo brrt: ^?
15:35 brrt oh, yes
15:36 brrt pending refactoring these ops
15:36 timotimo oh
15:36 brrt :-P
15:36 timotimo ah well
15:36 brrt to recall what went wrong there
15:36 brrt these functions return a struct
15:36 brrt with a value and a boolean-if-they-received-that-value
15:37 brrt they should, probably, be refactored to return success/failure and write the value to a pointer arg
15:37 timotimo oh, atposref_n aborts jitting of this AT-POS
15:37 timotimo i can implements this
15:37 brrt cool
15:37 * brrt is implementing a jit test bisector
15:38 timotimo neat
15:38 timotimo based on the "fuel" metaphor, i see
15:43 brrt fuel metaphor?
15:45 timotimo yeah
15:45 timotimo the optimizer (or jit in this case) would "run on" fuel and only do stuff until it "runs out"
15:46 timotimo so if you want to find some place that breaks things, you give it more or less fuel and see where it runs out
15:47 brrt hahahah
15:47 brrt cool
15:47 timotimo -Constructing JIT graph (cuuid: cuid_4876_1457271489.25971, name: 'AT-POS')
15:47 timotimo -BAIL: op <atposref_n>
15:47 timotimo \o/
15:48 timotimo my local changes are teaching facts.c about all the *ref_* ops creating the corresponding types from the HLL and jitting the atposref_* ops
15:48 brrt \o/
15:48 timotimo i should have a closer look if the *ref_* ops are currently appearing in the after-inlining-all-the-things output in my current test code
15:49 timotimo if they do, i could start working on spesh going directly via the original object and whatever register has the index/name/...
15:49 timotimo in any case, this code generates a gigantic amount of reference objects
15:49 timotimo to the point where 10% run time is spent in GC
16:06 timotimo we're taking lexical refs to pass to postcircumfix:<[ ]> ;_;
16:06 timotimo as indices ;_;
16:09 timotimo maybe because we specify \key ?
16:10 timotimo but we also have candidates with the int position available
16:31 dalek MoarVM: 6b2e4e0 | timotimo++ | src/jit/graph.c:
16:31 dalek MoarVM: jit the atposref_* ops
16:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6b2e4e07e3
16:31 dalek MoarVM: a3a5d0f | timotimo++ | src/spesh/facts.c:
16:31 dalek MoarVM: all the ref ops now properly set up facts in spesh
16:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a3a5d0f1bf
16:32 * timotimo pushes before heading out
16:34 dalek MoarVM/even-moar-jit: 207a337 | brrt++ | src/ (3 files):
16:34 dalek MoarVM/even-moar-jit: Add maximum jit expr compile indexes
16:34 dalek MoarVM/even-moar-jit:
16:34 dalek MoarVM/even-moar-jit: This is to allow 'easy' bisection of the relevant broken piece of
16:34 dalek MoarVM/even-moar-jit: code. To be coupled with a bisection script.
16:34 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/207a337c70
16:34 dalek MoarVM/even-moar-jit: cd79c8e | brrt++ | tools/jit-bisect.pl:
16:34 dalek MoarVM/even-moar-jit: Add tool for expr JIT bisecting
16:34 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/cd79c8e5c1
16:35 brrt we can now bisect where a particular piece of code really breaks
16:35 brrt if it is a piece of the expression jit, at least
16:35 nine This segfault worries me a bit: https://gist.github.com/niner/dfdb4ef9ce9ac040abc2
16:36 brrt hmm
16:36 brrt rerun with --optimize=0 --debug
16:37 nine Note that this is in Inline::Perl6 which is hacky code that embeds MoarVM despite the latter not having an embedding interface. That's why I worry only a bit.
16:42 nine What variables do those command line switches set in the code? I think it would be easier setting them in C than trying to find out how to pass those args to MoarVM
16:44 nine Oh you mean Configure.pl!
16:44 brrt sorry, i mean: reconfigure with --optimize=0 --debug, build, and rerun your test :-)
16:44 brrt aye
16:44 nine That I can do :)
16:45 dalek MoarVM/even-moar-jit: 8281387 | brrt++ | tools/jit-bisect.pl:
16:45 dalek MoarVM/even-moar-jit: Tell reader which frame really is broken
16:45 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/828138722f
16:46 cognominal joined #moarvm
16:47 nine Updated the gist: https://gist.github.com/niner/dfdb4ef9ce9ac040abc2
16:48 brrt hmm
16:48 brrt doesn't really ring a bell
16:48 brrt jnthn has been fixing leaks recently though
16:49 nine So maybe MoarVM is now trying to properly free things that I have not set up correctly.
16:59 timotimo interesting, a compunit's gc_free is asploding?
17:00 timotimo could this have something to do with sharing callsites between things? that's what hoelzro hunted at some point
17:03 hoelzro I hope that's not it; that was a pain to track down
17:05 timotimo well, a valgrind run might tell us more about this
17:05 timotimo or even asan
17:10 kjs_ joined #moarvm
17:13 dalek MoarVM/even-moar-jit: e5a150c | brrt++ | tools/jit-bisect.pl:
17:13 dalek MoarVM/even-moar-jit: Silence prove, probe for broken basic block
17:13 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e5a150c6cb
17:14 brrt this allows me to pinpoint *exactly* which basic block compilcation is wrong for a given test
17:15 brrt which is , frame 395, basic block 8, binparse-string
17:18 brrt joined #moarvm
17:18 brrt hmm
17:18 brrt next stop
17:18 brrt make jit bytecode dumps comparable
17:21 domidumont joined #moarvm
17:46 timotimo oh yeah
18:17 kjs_ joined #moarvm
18:36 kjs_ joined #moarvm
19:02 Ven joined #moarvm
19:17 mojca_ joined #moarvm
20:01 brrt joined #moarvm
20:24 brrt dalek has disconnected...
20:24 brrt anyway, i've pinpointed the exact breakage
20:24 brrt will now ponder a fix
20:24 jnthn brrt++
20:24 brrt anyway, that's not the cool bit
20:24 brrt the cool bit is
20:24 brrt i've automated the pinpointing
20:25 jnthn \o/
20:25 jnthn That *is* cool
20:25 jnthn 'cus it'll save a lot of time later
20:26 brrt thing is, it's probably not the getlex which is wrong
20:26 brrt because that one looks right
20:30 brrt hmmm
20:30 brrt the plot thickens
20:59 mojca joined #moarvm
21:04 kjs_ joined #moarvm
21:23 timotimo aaw, he didn't get to fixing it before leaving?
21:25 lizmat the plot thickens indeed  :-(
21:25 lizmat :-)
21:48 timotimo yeah
21:59 kjs_ joined #moarvm
22:07 kjs_ joined #moarvm
22:09 brrt joined #moarvm
22:26 timotimo hooray, less than one garbage collection per frame
22:26 timotimo *cough* *cough*
22:26 timotimo not significantly less, though

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary