Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-10-04

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

All times shown according to UTC.

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

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