Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-22

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

All times shown according to UTC.

Time Nick Message
01:26 FROGGS_ joined #moarvm
02:18 cognome joined #moarvm
05:28 tadzik I saw jnthn, he was safe :)
05:29 [Coke] yay
05:29 [Coke] what about brrt?
05:30 tadzik maybe he arrived, but I don't know how he looks like :o
05:30 TimToady um, look at his blog?
05:31 TimToady let me just verify that it is currently 8:30 am there?
05:31 tadzik it is
05:31 TimToady okay, thanks
05:31 tadzik https://www.blogger.com/profile/05760700924227974153 that doesn't help me recognize him :)
05:32 tadzik but even looking at the github picture, I don't think I've seen him
05:32 TimToady he has a big picture on his planteria blogs
05:33 [Coke] https://avatars1.githubusercontent.com/u/1617678?s=400, mebbe
05:34 TimToady yes, that's the picture
05:34 TimToady allowing for a bit of fisheye distortion...
05:36 [Coke] .tell lizmat - had to fudge some of the new throws_like tests for parrot & jvm.
05:36 [Coke] ww.
06:57 sergot hi o/
06:57 [Coke] o, hi
07:14 woolfy joined #moarvm
07:26 zakharyas joined #moarvm
07:31 klaas-janstol joined #moarvm
07:57 jnthn morning o/
07:58 jnthn brrt: If you're here somehere, please come introduce yourself...I'm sitting on row 2 :)
08:02 * TimToady is sitting up on the stage somewhere...
08:10 nine_ joined #moarvm
08:39 Ven joined #moarvm
08:42 zakharyas1 joined #moarvm
08:57 zakharyas1 joined #moarvm
08:59 klaas-janstol joined #moarvm
10:04 Ven joined #moarvm
11:11 Ven joined #moarvm
11:17 timotimo TimToady: is that because you're telepresenced by the camera? %)
11:35 FROGGS TimToady: you are sitting on my lap :P
11:36 FROGGS would be kind if you could put that hat off :o)
11:48 TimToady jjjjjjj~.
11:49 TimToady sorry, started snoring
11:50 TimToady actually, lost half the channel, had ot reconnect
12:07 cognome joined #moarvm
13:13 ggoebel11111116 joined #moarvm
13:21 dalek Heuristic branch merge: pushed 28 commits to MoarVM by jnthn
13:21 timotimo YAY
13:21 carlin !!!!!!!!!!!!!!!!
13:24 Ven joined #moarvm
13:24 timotimo how the hell ... this isn't even much code
13:25 jnthn <- lazy
13:25 jnthn NQP part of it for the profiler UI coming in a moment
13:26 timotimo ah, i was wondering where that would be found :))
13:26 jnthn Actually it needs some more work to get it to properly install the UI template thingy so things work out well with Rakudo.
13:28 timotimo $obj := subst($obj, /'\\'/, '\\\\\\\\', :global);
13:28 timotimo m)
13:36 jnap joined #moarvm
13:38 jnthn *lol*
13:38 jnthn It was, like, 2am :P
13:39 timotimo so the problem is the path to the template would have to be fixed?
13:39 timotimo as in: it ought to be installed somewhere by the makefile?
13:39 jnthn yeah, we should make install it somewhere
13:39 jnthn And then find it using lib path or something
13:39 timotimo right
13:39 moritz ah, profiling is a Configure.pl option
13:39 jnthn So for now you can only run it in the build directory for it to find the template
13:40 jnthn moritz: No
13:40 jnthn Stock build gets you it.
13:40 moritz oh, I read the diff the wrong way 'round
13:40 moritz -    prefix=s make-install profilecalls asan),
13:40 moritz +    prefix=s make-install asan),
13:41 jnthn It actaully uses spesh to instrument the code with recording profile info.
13:42 timotimo it'll "spesh" every frame for its very first invocation, i assume?
13:42 jnthn First after you turn on profiling, yes.
13:42 timotimo that's perfect
13:43 jnthn And if you already called it before turning on profiling, it knows it should make and swap in an instrumented version too
13:43 jnap joined #moarvm
13:44 timotimo hah
13:44 timotimo a super simple compilation profile gives me 62% time spent in the ws rule %)
13:45 jnthn o.O
13:45 jnthn Well
13:46 jnthn perl6-m --profile-compile -e "1" shows we spend 30%+ of time at startup inside of real2abs o.O
13:46 jnthn ooh, masak lightning talks
13:46 timotimo that's amusing :)
13:50 moritz it likely means that's a lot of potential for optimizing startup :-)
13:50 jnthn yes ;)
14:01 timotimo should rc-forest-fire be using nums for the loops? maybe we should specify them to be "int" instead
14:01 timotimo wow, way cool.
14:01 timotimo the later gc runs of rc-forest-fire all end up retaining < 4kb and promoting 0kb
14:10 timotimo jnthn: just browsing through the call graph is *fascinating*
14:11 timotimo except the call graph kinda goes boom on me ... i mean the breadcrumbs view on the top
14:12 timotimo jnthn: i have an example, where 18350 calls happen to Bool for Parcel ... and all of them are interpreted
14:12 timotimo multi method Bool(Parcel:D:)           { nqp::p6bool($!storage) }
14:13 timotimo to be fair, this is only 7.41ms in total time
14:13 timotimo out of 15087.87ms
14:14 timotimo but still ... it kinda surprises me that we can't jit that
14:17 jnthn I suspect lack of callsite interning.
14:17 timotimo oh, hm
14:18 timotimo it's kinda painful to click through eager -> gimme -> reify -> ... over and over and over again
14:18 timotimo i wonder if it's good or bad that these usually always have a 99.9% time spent in a single callee
14:21 timotimo it seems like it's easy to get from the breadcrumb navigation of the call graph to having "Callers: none"
14:21 jnthn There's some kinda bug there...it's meant to show the 5 most recent...
14:22 timotimo interesting. 368393 BOOTint allocated in find_best_dispatchee
14:23 timotimo 320736 in bind_one_param
14:23 timotimo i suppose bind_one_param happens really really often if we can't use the fast path binder
14:25 timotimo the full collections in rc-forest-fire all retain tiny amounts of data and freeign loads and loads of data
14:25 timotimo is the full gc profile display correct?
14:25 timotimo like 16KB / 82KB / 3998KB
14:27 timotimo wow. 204673 local deopts inside ListIter's reify
14:27 * diakopter anticipates more than a handful of >10% speedups
14:27 timotimo :)
14:28 timotimo actually, i believe the full gc display isn't what i think it is
14:28 timotimo as it only adds up to about 4mb, which is the nursery size
14:30 jnthn timotimo: It says it's nursery state.
14:30 timotimo oh!
14:30 timotimo of course it does %)
14:35 timotimo is there a way to instrument gen2 gc runs, too?
14:49 jnthn It's not anything like so obvious what to report on it...
14:50 timotimo aye
15:25 Ven joined #moarvm
16:21 FROGGS[mobile] joined #moarvm
16:23 hoelzro joined #moarvm
17:03 Ven joined #moarvm
17:09 TimToady timotimo: yes, the eager->gimme->reify loop is one of the things we'd like to fix with the list refactor; it should not have to refigure out how lazy it's being every time through
17:09 TimToady instead we should probably just have a function that returns the next batch, and if it's lazy, it happens to be size 1
17:10 TimToady and if we can delegate such functions upward, we can probably even do some level skipping, where a list is basically doing nothing
17:11 TimToady this gimme/reify thing is all sort of an "ask if you can ask" suboptimality
17:14 TimToady though not sure how iterators if we're just calling fetchers
17:15 TimToady perhaps the immutability of iterators is an illusion we maintain on the surface while just mutating things underneath
17:19 TimToady oh, btw, I did play with a batching gather/take that, I mean, more batching than the current one
17:20 TimToady it inteposed another take handler, then threw an outer take at the end of each batch
17:20 TimToady so it didn't save exceptions, but it saved continuations
17:20 TimToady turned out to save about 5%, less than I expected
17:20 TimToady and I accidentally the code
17:21 TimToady and I also figured we'll end up with something better
17:21 TimToady so it's not in this release
17:21 TimToady also, didn't really solve the deparcel-the-batch problem
17:22 TimToady so it was only useful in a .flat context
17:23 TimToady well, maybe this all belonged in #perl6, I dunno...
17:44 timotimo sadly, the profiler will not write its stuff out if the program exits with an exception :\
18:16 Ven joined #moarvm
19:17 klaas-janstol joined #moarvm
19:34 Ven joined #moarvm
19:44 lizmat timotimo: perhaps a tap on signal() could be of help?
19:45 timotimo i put a try/catch around the part of the profile runner that'd do the exception
19:46 timotimo lizmat: can you try if "perl6-m --profile -e 'say "hi"; die' will output a line "wrote profiler data to ..."?
19:46 timotimo because locally it does now
19:49 * lizmat is building latest / greatest now
19:55 lizmat timotimo: it doesn't
19:56 timotimo good
19:56 lizmat it *does* without the die  :-(
19:56 timotimo now how do i ensure my fix is proper?
19:59 timotimo hm, it doesn't do the same kind of error reporting that it used to do without --profile
20:33 Ven joined #moarvm
21:47 avuserow joined #moarvm
22:13 [Coke] any pointers how to use the new profiler stuff?
22:20 timotimo yup
22:20 timotimo perl6 --profile foobar.p6
22:21 timotimo it'll tell you how to get at the results
22:21 jnthn Why the heck'd you not be able to come up with something profilable that *doesn't* die?
22:21 timotimo well ... now it segfaults instead
22:21 timotimo are you happy now? :)
22:21 timotimo (the spesh_diff.p6 script in moarvm's repo)
22:22 timotimo btw, i'd like to change the spesh log output a bit to be more friendly to parse ...
22:22 timotimo the intra-frame-stuff is almost perfectly fine, but the inter-frame stuff ... not so much
22:23 jnthn The spesh log output wasn't really designed for a program to consume....
22:23 timotimo right
22:23 timotimo but diffing it by eye is ... tough
22:23 timotimo and spesh_diff has to fight as it is
22:23 jnthn OK. I just haven't ever felt a huge need to, really...
22:23 timotimo i'd like to let each BB print its memory address next to its need
22:24 timotimo so that it'd be easier for a program (or user?) to see which bb turned into what
22:24 jnthn Why each BB?
22:24 jnthn Isn't the issue to identify specializations?
22:24 jnthn In which case I think those already have an index...
22:24 timotimo the index changes during spesh, though
22:25 timotimo and we'll end up with a whole bunch of goto statements changing just because their target BB has moved in the linear order
22:25 timotimo and git diff is also not clever enough to recognize BBs changing *and* getting their id changed
22:25 timotimo it all looks a bit rough
22:26 timotimo (trying to get a coredump now ...)
22:32 jnthn What coredumps exactly?
22:33 jnthn Doing a profile?
22:33 * jnthn didn't manage to explode it
22:34 jnthn I did try to profile CORE.setting build and had to kill it when RAM usage hit 15GB :P
22:36 TimToady diHwidt
22:37 jnthn Well, I probably need to teach it to depth limit the call graph tracing
22:37 jnthn So you can still get a useful big picture
22:37 nwc10 jnthn: are profiling files portable? Can they be shipped from server with MOAR RAM to desktop client with useful stuff?
22:37 TimToady or some way to limit it to a particular thing
22:39 jnthn nwc10: Profiling files are JSON... :)
22:39 nwc10 OK
22:39 jnthn Well, that's the current serialization
22:39 jnthn Actually the profile makes a data structure
22:39 jnthn And at the moemnt I dump it to JSON and shove it in a HTML template
22:42 * TimToady con-templates that
22:42 flussence how much of that 15GB would be compressible/stringy stuff? I wonder if throwing tons of /dev/zram swapspace at it would get it further...
22:43 jnthn flussence: I...think I'd rather solve it with depth charges
22:43 jnthn uh
22:43 jnthn with depth limiting
22:43 jnthn wtf, brain...
22:43 flussence heh :)
22:45 flussence I might sound insane, but in ye olde days that same trick allowed me to build all of r-p on my netbook
22:46 nwc10 well, Devel::NYTProf got compressed profile files because I was filling my disk
22:47 nwc10 and in turn, what I was profiling was Test::Harness for parallel tests
22:47 nwc10 to make it work.
22:48 timotimo BFD: Warning: /home/timo/perl6/rakudo/core.23210 is truncated: expected core file size >= 6807769088, found: 1097076736.
22:48 timotimo oh
22:48 timotimo my hard drive full'd
22:48 jnthn lolz
22:49 jnthn Yeah, I guess I'll have to do something about profiling big things.
22:49 timotimo :)
22:49 timotimo this was a very big thing
22:50 jnthn For now I can only suggest profiling rodents of *usual* size...
22:50 timotimo maybe i shouldn't have used the spesh log of core setting compilation to profile the spesh_diff script %)
22:51 jnthn ;)
22:53 timotimo ah, turns out that if there's something that waits on I/O, the profiler will count that waiting as time ... spent
22:53 timotimo hm
22:55 * jnthn doesn't consider that particularly bad.
22:55 jnthn For example, knowing that in many of the NQP tests, most of the time is spent in print, might give us a hint we want to look at I/O performance :)
22:55 timotimo now i can't tell if our socket's get method is inefficient or if my script just waits a bunch
22:55 timotimo ah. that's certainly true.
22:55 jnthn Doesn't get mostly delegate?
22:55 jnthn (to the op)
22:56 timotimo we don't measure op times, though ... or do we?
22:57 jnthn No
22:57 jnthn It's routine level
22:57 timotimo anyway, the second place is firmly held by reify followed by gimme
22:57 timotimo and then comes MapIter's reify
23:00 jnthn are you looking at inclusive or exclusive there?
23:00 timotimo exclusive
23:02 jnthn ah
23:02 jnthn that's...interesting.
23:02 jnthn so is my hotel bed :)
23:02 jnthn 'night
23:02 TimToady o/
23:03 timotimo gnite!
23:50 timotimo sadly i don't really know how to limit the call-chain-walking without messing up the inclusive/exclusive times :\

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