|
01:50
FROGGS_ joined
02:44
retupmoc1 joined,
[Coke]_ joined
02:45
avuserow_ joined,
sergot_ joined,
btyler_ joined
02:52
japhb joined
02:58
FROGGS_ joined
06:57
camelia joined
07:49
FROGGS[mobile]2 joined
09:14
FROGGS[mobile] joined
10:18
camelia joined
12:37
kjs_ joined
13:22
Ven_ joined,
FROGGS[mobile] joined
13:29
vendethiel joined
13:45
zakharyas joined
14:05
FROGGS[mobile]2 joined
|
|||
| timotimo | is there any sense in having an op that "merges" strings together when you find they are equal? | 15:35 | |
|
15:36
Ven_ joined
|
|||
| timotimo | like, the eq operator could - given a string from the nursery that's eq to a string in the gen2 - box the string in the gen2 into/assign to the other object and it'd generate less spill-over into the next nursery (or alternatively the gen2) | 15:36 | |
| and if we have eqat for a size over a certain threshold, we could generate the substring as a piece of rope | 15:37 | ||
| .o( leave it to timotimo to come up with weird optimization opportunities that may or may not be waaaayyy premature ) | 15:38 | ||
|
15:56
kjs_ joined
|
|||
| timotimo | i'm not totally sure what exact properties i have to aggregate in order for the stuff to be correct in the end | 16:34 | |
| i'll figure something out. | |||
| jnthn | timotimo: I can imagine some kind of interning working... | 16:36 | |
| BUT | |||
| As soon as you start cheating on immutables, you run the risk of losing the nice thread safety properties immutable things freely give. | |||
| timotimo | ah, yes, that's right | 16:38 | |
| i think what my code will end up looking will be this: | 16:39 | ||
| if the depth is reached, i'll add the "this one's an aggregated node" to the hash and call a different function for all the callees | |||
| that way i don't duplicate the setup code for the hash at least | 16:40 | ||
| jnthn | Right | ||
| Well, at lesat allocation stats and exclusive time want merging | 16:41 | ||
| And deopt/spesh counts too | |||
| timotimo | OK, let's see | 16:44 | |
| hm, will i need to touch the hash of the aggregate node when i'm working through the tree below? | 16:54 | ||
| it seems so, as i'll have to remove the times frmo the exclusive time | 16:55 | ||
|
17:27
Ven_ joined
|
|||
| timotimo back from le shopping | 17:56 | ||
| i think i'll factor out the "pcn -> hash" part | 17:59 | ||
|
18:04
Ven_ joined
|
|||
| timotimo | jnthn: how come the allocations get emitted after we go through the allocations? | 18:16 | |
|
18:17
kjs_ joined
|
|||
| jnthn looks confusedly at timotimo's question | 18:18 | ||
| timotimo | er | ||
| after we go through the *callees* | |||
| jnthn | Oh... | ||
| timotimo | it doesn't seem important | ||
| jnthn | It isn't | ||
| But allocation profiling was one of the last features I added | |||
| So it comes last 'cus it, well, came last :) | 18:19 | ||
| timotimo | OK | ||
| the code looks like it's a whole lot, but ... | 19:26 | ||
| hm. am i finished? | 19:37 | ||
| i don't think this is going to compile without lots of massaging %) | 19:38 | ||
| src/profiler/profile.c:110:13: warning: passing argument 2 of ‘MVM_repr_elems’ makes pointer from integer without a cast [enabled by default] | 20:01 | ||
| existing_allocations = MVM_repr_elems(tc, MMV_repr_at_key_o(tc, node_hash, pds->allocations)); | |||
| ooooh | |||
| NOW i see it! | |||
| FROGGS | MMV | ||
| timotimo | yeah | 20:02 | |
| and the other instance was writing MVM_repr_at_key | |||
| (see if you can spot the error) | 20:03 | ||
| FROGGS | _o | ||
| timotimo | yup | 20:09 | |
| sorry to keep you hanging for that long | |||
| FROGGS | *g* | ||
| timotimo | wow, this ended up a *lot* of code :\ | 20:14 | |
|
20:17
odc joined
|
|||
| timotimo | i can't believe it compiles | 20:17 | |
| damn: Cannot iterate object with P6opaque representation | 20:32 | ||
| ah, i understand. NQPMu. | 20:35 | ||
| it may work this time | 20:39 | ||
| no clue if the results will make sense, though | |||
| welp, i have an output | 20:42 | ||
| i still get NaN% and NaNms for many routines in the "exclusive time" piece :( | 20:46 | ||
| the call graph looks ... :\ | 20:48 | ||
| well, i'll just upload it and stash my result somewhere as well | 20:50 | ||
| now i'll actually have the opportunity to go ahead and do that, too! | 21:04 | ||
| (but first i'll have to generate a new profile output file) | |||
| oh, i don't think i'm actually recursing at all | 21:05 | ||
| that's not good | |||
| jnthn | One thing to try is to write something that recurses a 1000 calls deep or so | 21:06 | |
| And maybe allocates something at each level | 21:07 | ||
| And then see how it compares with your changes vs. without | |||
| timotimo | my call graph depth limit is currently just 32 | 21:08 | |
| jnthn | The allocation counts should come out the same, for example. | ||
| timotimo | aye | 21:10 | |
|
21:11
zakharyas joined
|
|||
| timotimo | that froze my computer for a solid 10 minutes ... | 21:17 | |
| maybe not that long | |||
| ah | 21:20 | ||
| i was still creating new callees lists for each callee in the aggregate node recursively | 21:21 | ||
| at least i get a segfault now, so i'll find something easier | 21:24 | ||
| i did silly things | 21:37 | ||
| well, it doesn't seem to max out my ram any more | 21:42 | ||
| the output actually looks sane now | 21:52 | ||
| you can has code. | 21:53 | ||
| dalek | arVM/finite_callgraph_depth: e706ca1 | (Timo Paulssen)++ | src/profiler/profile.c: merge profiler data starting at 32 call levels deep this lets us get a profiler output from the core setting |
21:56 | |
| jnthn | timotimo: gut feeling tells me 32 is too shallow, but we can tune it :) | 21:57 | |
|
22:11
Ven_ joined
|
|||
| timotimo | t.h8.lv/profile-1412458985.39989.html - le big file | 22:12 | |
| 44mb in fact | 22:13 | ||
| ah, so deserialization_code takes up the most time? interesting | 22:14 | ||
| jnthn | Well, that means "doing the serialization" I guess | 22:16 | |
| Wow, chrome loaded it | |||
| Wow...we spend THAT long in GC?! | 22:17 | ||
| timotimo | yup :) | ||
| oh holy fuck | |||
| we do | |||
| jnthn | Something feels...very odd...about that | ||
| timotimo | oh yeah | 22:18 | |
| the GC times rise and rise | |||
| the more stuff we have | |||
| jnthn | For one that it doesn't match the C-level data I have, which suggests a number more like 20% | ||
| timotimo | aye, could be bogus | ||
| aaaaah | 22:19 | ||
| i divide by 1000 too often | |||
| let me try again :) | |||
| jnthn | Yeah, something is odd | 22:22 | |
| timotimo | i'm generating a new profile as we speak | 22:23 | |
| dalek | arVM/finite_callgraph_depth: cb7647e | (Timo Paulssen)++ | src/profiler/profile.c: don't do bogus divide by 1000 operation |
22:24 | |
| timotimo | still takes a long while to actually finish | 22:25 | |
| and it finishes right as i complain %) | |||
| filename's profile-1412461543.12799.html in the same folder, but not finished uploading yet | 22:26 | ||
| give it half a minute | |||
| should be up now | 22:30 | ||
| er ... huh? no change? | 22:31 | ||
| jnthn | Something must be wrong still, i think... | 22:34 | |
| See deserialization_code | |||
| timotimo | ooooh | ||
| hold on | |||
| jnthn | exclusive time shoudl never be bigger than inclusive time... | ||
| timotimo | yeah, i'm doing that wrong when i go through the aggregated children | ||
| jnthn | Still, it's great we're on the cusp of having nice profile data for CORE.setting compilation :) | 22:35 | |
| timotimo | i grab the total_time each time instead of taking more stuff | ||
| jnthn | timotimo++ | ||
| timotimo | i'm glad i'm getting out of my "doing nothing" phase a bit | 22:44 | |
| jnthn | :) | 22:49 | |
| Hopefully I can get out of mine soon too :) | |||
| Sleep time for now, though... :) | |||
| timotimo | conference driven design for the APW? :) | ||
| can i get one last tip? | |||
| i need to do the exclusive time calculation wholy differently it feels like | 22:50 | ||
| i need to grab the "exclusive time so far" and add the current merge-candidate's total time minus the callee's total time? | |||
| does that sound right? | |||
| jnthn | Yeah, I think so | 22:51 | |
| Meaning you are adding them up as you come back up the tree | |||
| Well | |||
| Doesn't have to be that way I guess... | |||
| timotimo | i think i can implement that | ||
| jnthn | *nod* | 22:52 | |
| timotimo | seems like i just had to type it out on irc once before i put it into the injection mold :) | ||
| the big C-shaped injection mold | |||
| jnthn | :) | ||
| I wonder if the GC numbers really are correct | |||
| timotimo | gosh i hope not! :) | ||
| jnthn | Well...if they are...we know where to look... :) | ||
| But given we often see other things getting GC overheads of < 10%, it does seem extreme | 22:53 | ||
| We may be hitting a pathological case | |||
| timotimo | ah, another thing i should definitely *not* do is subtract the pcn->succ[i].total_time after i've done the "merging" | ||
| that should come way later | |||
| when the merging is done, and i shouldn't be looking at an individual's succ[i].total_time at all | 22:54 | ||
| jnthn | *nod* | 22:55 | |
| OK, I'm going for some rest | |||
| 'night | |||
| timotimo | gnite! | ||
| thanks for the little kick in the butt :) | |||
| oh, i think i've been putting data into the wrong hash all along! | 23:23 | ||
| ah, not quite ; i think this is all a tiny bit much for my tiny bit of brain %) | 23:24 | ||
| no, what i've actually done is not pass on the right hash | 23:27 | ||
| that would have caused data to only bubble up one layer each time, except for the layer where we actually aggregate ... so the time is just lost | 23:33 | ||
| the GC times still seem wrong | 23:34 | ||
| well, i keep finding things that are wrong, but it still seems to end up wrong all in all ... | 23:42 | ||
| huh, wait, the total time isn't a sum of all the time spent in calls, it's just end time - start time | 23:43 | ||
| so wrongness in the call graph shouldn't cause such wrong numbers for the gc vs the whole time ?! | |||