Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-07

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

All times shown according to UTC.

Time Nick Message
00:35 japhb jnthn: In your newest 6guts: "This ran in 5.12 seconds, with 0.8s startup/compilation time, so let’s call it 5 seconds for the iterations"  Did you mean .08s startup/compilation time?  That makes more sense in context (and also closer to the startup speed I expect from perl5).
00:38 timotimo oh, did i miss a 6guts?
00:38 timotimo i did!
01:50 ggoebel16 joined #moarvm
03:50 ggoebel16 joined #moarvm
05:50 vendethiel joined #moarvm
06:23 mojca joined #moarvm
07:18 domidumont joined #moarvm
07:23 domidumont joined #moarvm
07:25 vendethiel joined #moarvm
07:45 domidumont joined #moarvm
08:19 zakharyas joined #moarvm
08:44 mojca_ joined #moarvm
09:25 FROGGS joined #moarvm
09:38 jnthn japhb: Yes, just a thinko transcribing the numbers from the console. :-)
09:38 jnthn Fixed; thanks!
10:17 timotimo jnthn: i left a message with yoleaux for you :)
10:57 mojca joined #moarvm
11:45 dalek joined #moarvm
11:45 synopsebot6 joined #moarvm
13:36 [Coke] joined #moarvm
14:26 mojca_ joined #moarvm
14:51 brrt joined #moarvm
15:11 FROGGS joined #moarvm
15:23 brrt left #moarvm
15:44 hoelzro joined #moarvm
16:41 donaldh joined #moarvm
16:47 jnthn m: say 425911947 / 428605860
16:47 camelia rakudo-moar c7be33: OUTPUT«0.9937147080␤»
16:48 jnthn m: say 425911947 R- 428605860
16:48 camelia rakudo-moar c7be33: OUTPUT«2693913␤»
16:55 timotimo from ulti's jitlog i can only see very few jit graphs that are aborted after reaching an inline
16:56 timotimo take-rw is one, though. it goes into THROW, then bails at bindexpayload
16:56 timotimo redo goes through THROW-NIL and bails at bindexcategory there
16:56 timotimo that's really all i could see
16:57 jnthn Yeah, I suspect those control operators are now inlined
16:58 jnthn That'd mean it can't JIT the entire enclosing loop
16:58 timotimo except if that's the case, it'd show up in the jit log as entering that inline, no?
16:58 timotimo so wouldn't it just emit an invocation instead?
17:00 donaldh PR to fix dyncall on raspberrypi https://github.com/MoarVM/MoarVM/pull/344
17:01 jnthn timotimo: No, we inline during spesh
17:01 jnthn And JIT the result
17:01 jnthn So inlining something we can't JIT means we can't JIT the thing that it was inlined into
17:03 timotimo yeah, but if we've inlined something we can't jit, it'll show up in the jit log as "constructing graph for blah", then "entering inline for foo", then "bail"
17:03 timotimo the fact that the jit log contains redo and take-rw as "constructing graph", rather than as "entering inline" is what i'm interpreting
17:04 jnthn ah
17:04 timotimo how do i best interpret it when a profile shows a crazy amount of time spent in find_best_dispatchee?
17:08 dalek MoarVM/lazy-strings: 3c5d4fe | jnthn++ | src/ (2 files):
17:08 dalek MoarVM/lazy-strings: A more robust strings JIT fix.
17:08 dalek MoarVM/lazy-strings:
17:08 dalek MoarVM/lazy-strings: All uses of the get_string macro were potentially vulnerable to the
17:08 dalek MoarVM/lazy-strings: string not having been decoded yet, so this moves the check into the
17:08 dalek MoarVM/lazy-strings: macro. Also introduce another little function, just to have a clean
17:08 dalek MoarVM/lazy-strings: way to express that we don't want the string itself, just to be sure
17:08 dalek MoarVM/lazy-strings: it's decoded.
17:08 dalek MoarVM/lazy-strings: review: https://github.com/MoarVM/MoarVM/commit/3c5d4fe9d2
17:08 dalek MoarVM: eff150a | jnthn++ | src/ (4 files):
17:08 dalek MoarVM: First pass at making string decoding lazy.
17:08 dalek MoarVM:
17:08 dalek MoarVM: That is, we only do it the first time a string from the string heap is
17:08 dalek MoarVM: needed. Not quite right yet; we SEGV one of the NQP tests. But close.
17:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eff150add1
17:08 dalek MoarVM: a501a41 | timotimo++ | src/jit/emit_x64.dasc:
17:08 dalek MoarVM: force sp_findmeth to decode strings in the CU
17:08 dalek MoarVM:
17:08 dalek MoarVM: makes nqp build&test and rakudo build.
17:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a501a41e37
17:08 dalek MoarVM: 3c5d4fe | jnthn++ | src/ (2 files):
17:09 timotimo neat :)
17:09 jnthn timotimo: It probably has late-bound multi-dispatch (where clauses etc.)
17:09 timotimo oh
17:10 timotimo that also includes signatures on &sigiled things, then?
17:10 jnthn The above gives us 1.26MB off Rakudo's base memory, and shaves around 2.7 million CPU instructions off startup
17:10 timotimo sweet!
17:10 FROGGS joined #moarvm
17:11 timotimo find_best_dispatchee is difficult for me to analyze as it doesn't actually seem to show up in the call graph itself
17:11 timotimo or maybe i'm just blind
17:12 jnthn Other thing is it could be overflowing the multi cache, but that's rare
17:13 jnthn Time to go work on dinner prep :)
17:13 timotimo mhh :)
17:14 dalek MoarVM: 7170f69 | donaldh++ | src/core/nativecall_dyncall.c:
17:14 dalek MoarVM: Fix dyncall on raspberrypi for calls > 4 params
17:14 dalek MoarVM:
17:14 dalek MoarVM: Dyncall docs say 'This function should be called after setting the call mode (using dcMode),
17:14 dalek MoarVM: but prior to binding arguments to the CallVM'. Likely to be redundant on many platforms, but is the
17:14 dalek MoarVM: documented API behaviour.
17:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7170f690e8
17:14 dalek MoarVM: 21d0ef3 | FROGGS++ | src/core/nativecall_dyncall.c:
17:14 dalek MoarVM: Merge pull request #344 from donaldh/master
17:14 dalek MoarVM:
17:14 dalek MoarVM: Fix dyncall on raspberrypi for calls > 4 params
17:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/21d0ef3bea
17:14 timotimo good catch, donaldh
17:15 FROGGS aye
17:15 FROGGS donaldh++
17:26 donaldh joined #moarvm
17:34 timotimo i don't 100% get why the accessor in jnthn's blog post gets turned into p6oget_o, p6ogetvc_o and another p6oget_o; perhaps there's a Scalar in-between? or something?
17:34 timotimo the output of that code could be a bit better still if we didn't save the contents of $_ unnecessarily :)
17:38 jnthn timotimo: cooking but: decont of self, get the attr from self, decont the attr
17:39 timotimo ah, ok
17:39 timotimo now if we had loop-invariant code motion, the loop body could become completely empty ;)
17:56 domidumont joined #moarvm
18:22 donaldh joined #moarvm
18:49 vendethiel joined #moarvm
19:31 mojca_ joined #moarvm
20:04 [Coke] jnthn++
21:23 timotimo do we know why the CORE.setting.moarvm starts with a few pages full of 00000210: 0800 0800 0800 0800 0800 0800 0800 0800  ................
21:23 timotimo 000019f0: 0800 0800 0800 0800 0700 0800 0800 0800  ................
21:23 timotimo ^- here's the first time the values are changed, it looks like
21:26 jnthn What segment is that?
21:26 jnthn The string heap is usually the first thing in there
21:27 jnthn Oh, maybe not
21:27 timotimo it isn't; i've reached the string heap now
21:27 jnthn Yeah
21:27 jnthn It's the SC dependencies section
21:27 timotimo and that contains like four or five screen pages that look very much like this:
21:27 jnthn Or the extop section
21:28 timotimo 00181c90: 5f35 375f 3134 3537 3338 3234 3334 2e37  _57_1457382434.7
21:28 timotimo 00181ca0: 3836 3735 3800 0000 616c 745f 6e66 615f  86758...alt_nfa_
21:28 timotimo 00181cb0: 5f31 315f 3134 3537 3338 3234 3334 2e33  _11_1457382434.3
21:28 timotimo 00181cc0: 3539 3035 3800 0000 616c 745f 6e66 615f  59058...alt_nfa_
21:28 timotimo 00181cd0: 5f37 355f 3134 3537 3338 3234 3335 2e30  _75_1457382435.0
21:28 timotimo i wonder if we can get these strings deduplicated? i don't think we'd really need this?
21:28 jnthn They're not duplicates?
21:28 jnthn The IDs differ
21:29 jnthn Seems the order is SC dependencies, extension ops, frames (including their lexical and local types), then callsites, and only then strings
21:31 timotimo the leap second dates are apparently in there as strings, that's interesting
21:34 timotimo https://i.imgur.com/XNy7slW.png - this amuses me %)
21:35 timotimo and of course like a thousand pages full of cuid_*_*.*
21:36 timotimo like, seriously, a *lot* of cuid strings
21:41 jnthn :)
21:41 jnthn The errors there are exactly the kind of thing I figured we could just lazily decode :)
21:42 timotimo aye
21:51 jnthn Enough for today :) 'night
21:52 FROGGS gnight jnthn
21:53 timotimo gnite jnthn

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