|
00:07
AmsterdamJoe joined,
vendethiel joined
02:18
vendethiel joined
02:47
ilbot3 joined
02:59
FROGGS_ joined
03:27
colomon joined
04:39
vendethiel joined
06:39
vendethiel joined
07:11
FROGGS joined
07:33
domidumont joined
07:38
domidumont joined
07:42
vendethiel joined
09:34
kjs_ joined
|
|||
| jnthn | In prep for upcoming reliability and performance work, I'll be setting up various daily measurements. Will do a valgrind no-leak one once my work on that is a bit further along, and a spesh-immediately one too. For now, though, there's a daily run of perl6-bench on Rakudo head: www.moarvm.org/measurements/perl6-bench/ | 10:07 | |
|
10:08
zakharyas joined
10:41
cognominal joined
|
|||
| timotimo | i noticed i haven't actually merged the "only use atomic ops when more than one thread exists" code yet. maybe i should. | 12:02 | |
| perhaps i should wait for after february's release, though? | |||
| jnthn | That's still a bit into the future | 12:03 | |
| flussence | .oO( will the february release even be in february? ) |
12:04 | |
| timotimo | OK, then i'll do it later today | ||
| jnthn | flussence: Dunno, that sounds terribly conventional :P | ||
| timotimo | maybe next year we'll use discordian "months" instead of the regular ones | 12:06 | |
| well, in the discordian calendar we only have 5 seasons, which is the equivalent of months | |||
| jnthn | .oO( accordian months sound better to me... :) ) |
12:07 | |
| timotimo | chaos, discord, confusion, bureaucracy, and "The Aftermath" ā„ | ||
| "This is Rakudo Chaos 3182" | |||
|
13:17
Ven joined
13:40
Ven joined
13:52
Ven joined
14:06
masak joined
|
|||
| masak | dunno how relevant this is, but it reminded me of MoarVM for some reason: webkit.org/docs/b3/ | 14:07 | |
| jnthn | Hm, interesting | 14:09 | |
|
14:10
leont joined
14:11
japhb joined
14:30
kjs_ joined
14:52
brrt joined
|
|||
| brrt | ohai | 14:52 | |
| timotimo | oh, hey brrt | ||
| how's your day? :) | |||
| brrt | masak: yeah, b3 and expr jit are similarish, except that b3 is of course written by experts people who know what they're doing, and expr jit is written by me | ||
| hmm, okay i guess | 14:53 | ||
| jnthn: i recall fixing that cleanup on the jitcode earlier | 14:54 | ||
| but maybe that was limited to the expr jit branch | |||
| also, b3 doesn't do 'optimal' tiling but maximal-munch | 15:05 | ||
| which is a good way, fwiw | |||
| recording a 'good idea' here; i was thinking of creating a table of { operation, { operand_nr, operaand_type }, template } for type-specific operation templates | 15:12 | ||
|
15:15
vendethiel joined
15:23
Ven joined
|
|||
| brrt | (and yes, i will eventually get to implementing all these things :-)) | 15:24 | |
|
15:28
Ven joined
|
|||
| brrt | anyway, that would be used for specialized jit templates | 15:30 | |
|
15:33
japhb joined
15:41
vendethiel joined
|
|||
| masak | brrt: yes, the greedy approach seems like it could work quite well | 16:02 | |
|
16:45
leont joined
|
|||
| timotimo | jnthn: something may be off in our "dead BB elimination", i have an example for you: gist.github.com/timo/6e049585004912f5f24d | 17:05 | |
| even the very simple code perl6 -e 'for ^4194304 { rand }' ends up not inlining the loop body (but it does inline rand) | 17:06 | ||
| jnthn | Loop bodies are map closures at present so don't really inline at all | 17:07 | |
| timotimo | oh | ||
| OK, fair enough | |||
| jnthn | Hm, you mean BB4 is unreachable, but left behind? | ||
| timotimo | i think so, yes | 17:08 | |
| Successors: 5 | |||
| Predeccessors: 5 | |||
| ^- very suspicious | |||
| also, that for loop gets turned into a while loop; wouldn't that make it inlinabler? | 17:09 | ||
| in the profile, i get 67.5% exclusive time on the outer block, the one that for's, and 32.5% exclusive time on the inner block, the one that rand's | 17:10 | ||
| so ... rand is really fast, but entering a block and incrementing an integer is really slow in comparison? | |||
| jnthn | Something like | 17:11 | |
| Invocation is fairly high on my list of stuff to speed up | |||
| timotimo | sweet | 17:12 | |
| i'm not really aware what exactly makes invocation expensive | 17:13 | ||
| do you have a clue how much you can get out of optimized invocation? | 17:18 | ||
| jnthn | Not sure, but it can account for up to 10% of runtime in some cases on profiles. | 17:19 | |
| But we also have GC getting costly when there's huge numbers of closures alive | |||
| timotimo | mhm | ||
|
17:24
FROGGS joined
18:08
japhb joined
|
|||
| diakopte1 | I saw fixed size allocation taking up 6% of the 10% of invocation | 18:21 | |
| well, 60% depending how you read it | |||
| timotimo | oh? wow | 18:22 | |
| diakopte1 | (using Xcode's profiler) | ||
| timotimo | was that what we had the frame cache for at some point? | ||
| diakopte1 | yeah, but theoretically the fixed size allocoater should be good too | 18:23 | |
| alligoater | |||
| timotimo | i haven't looked at the FSA yet ... does it have a lot of locking or something? | 18:25 | |
| diakopter | no, but the malloc it calls probably does in most platforms | 18:26 | |
| timotimo | ah | ||
| but don't we have a bunch of pools for that purpose? with like big pages? | |||
| diakopter | there might be some arithmetic wrong somewhere; last time I looked (within 2 months) the number of mallocs seemed quite high compared to number of calls to the FSA | 18:27 | |
| timotimo | hmm | ||
| well, there's a whole bunch of straight-up malloc calls from deserialization | 18:28 | ||
| for STables, iirc | |||
|
18:34
vendethiel joined
18:39
japhb joined
18:58
japhb joined
|
|||
| japhb | Oh holy cow, timotimo++ did a pile of fixes for perl6-bench! | 19:03 | |
| Very many thanks to both of you for keeping it going. :-) | |||
| timotimo | <3 | 19:04 | |
|
19:20
domidumont joined
|
|||
| jnthn | The improvements should show up in tonight's run | 19:24 | |
| timotimo | when is that likely to appear online? do you have to manually upload the result? | 19:25 | |
| jnthn | timotimo: No, it's an automated run | ||
| timotimo | cool :) | ||
| i'm looking forward to that | 19:26 | ||
| jnthn | So I don't have to do anything for it to run. Do have to `git pull` in improvements still | ||
| (Not for Rakudo etc., just for the benchmarks themselves) | 19:27 | ||
| It runs with Rakudo and NQP HEAD and the Moar in MOAR_REVISION | |||
| timotimo | ah, hm. so only benchmark improvements, no moar improvements just yet | 19:31 | |
| diakopter | .oO( I wonder if the cache_sc_idx branch automagically fixed itself on windows... I'll check ) |
19:34 | |
| timotimo | i'm running spec tests with the no-atomics-for-stuff merge | ||
|
19:40
cognominal joined
|
|||
| dalek | Heuristic branch merge: pushed 48 commits to MoarVM/cache_sc_idx by diakopter | 19:40 | |
| diakopter | dalek++ # for once | ||
| [Coke] | even a stopped bot is right twice a... | 20:06 | |
|
20:30
zakharyas joined
|
|||
| timotimo | it seems like all those spec tests are busy-looping inside an AO_ operation | 20:34 | |
| dalek | arVM: 2136293 | jnthn++ | src/core/nativecall_ (2 files): Don't create partly-initialized callsites. We left the named args pointer junk, which would cause problems were it freed later. Would only have come up with --full-cleanup before, but after fixing a leak in callsite interning it could come up much more often. |
20:48 | |