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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!