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