Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-07-13

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

All times shown according to UTC.

Time Nick Message
02:13 vendethiel- joined #moarvm
03:34 dalek joined #moarvm
06:30 domidumont joined #moarvm
06:36 domidumont joined #moarvm
06:56 colomon joined #moarvm
07:31 zakharyas joined #moarvm
07:55 dalek MoarVM: 6dad163 | (David Warring)++ | src/6model/serialization.c:
07:55 dalek MoarVM: fix sha1 op to work with null bytes
07:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6dad163992
07:55 dalek MoarVM: fe26e95 | timo++ | src/6model/serialization.c:
07:55 dalek MoarVM: Merge pull request #385 from dwarring/sha1-fix
07:55 dalek MoarVM:
07:55 dalek MoarVM: fix sha1 op to work with null bytes
07:55 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fe26e9569e
07:59 timotimo ^- it's a very good idea to not stop hashing on null bytes, though we'll still want to expose a sha1 for buffery and array-y types, too
07:59 timotimo it's not quite as bad as when nintendo used strcmp to compare two hash values in order to figure out if a cartridge is legit or not
08:12 brrt joined #moarvm
08:18 brrt good *
08:18 timotimo good
08:20 brrt i'm itching to start coding... but have to finish thesis first :-(
08:30 * jnthn can easily imagine coding being more attractive than thesis writing :)
08:31 timotimo right. except when you don't have to write a thesis, maybe coding will become what you don't want to do and something else seems more attractive :D
08:34 brrt we'll see
08:34 brrt :-)
08:36 timotimo my head's yearning for a nap :|
08:46 domidumont joined #moarvm
08:47 brrt do you have time for a nap?
09:58 zakharyas joined #moarvm
10:22 domidumont joined #moarvm
10:28 timotimo i took one anyway
10:28 timotimo so, regarding the profiler thing
10:29 timotimo i thought we were doing orig-bytecode + profile => execution, then orig-bytecode + logging + profile => execution, then orig-bytecode + speshed + profile => execution
10:29 timotimo because i don't seem to recall spesh log ever showing the profiling ops being added
10:31 jnthn No, we include profiling info in spesh'd code...we even rewrite certain profiling opts to record we're in spesh'd/JIT-compiled/inlined code
10:31 timotimo right, but that happens after we've speshed the code
10:33 timotimo aha! i must have been wrong
10:33 timotimo yes, indeed, i see the prof_* instructions there
10:41 brrt i wonder how much trouble it'd be to have loop hotness counts within routines
10:42 brrt for a far future cleverer JIT that can do register allocation based on estimated use counts
10:42 arnsholt brrt: I so know the pain of thesis writing over coding! =)
10:43 brrt one of the major things, for me at least
10:43 brrt code is never bullshit
10:43 arnsholt In fact, I've done some fun codings in the last three months when I've been procrastinating...
10:43 brrt research is always treading a fine line
10:43 * brrt knows about that
10:43 brrt well, from personal epxerience, not about your procrastinating :-)
10:44 arnsholt I assumed =D
10:44 arnsholt Yeah, research is tricky
10:44 arnsholt On the one hand, you want to present it in such a way that it's understandable. On the other, it needs to sounds like something worth doing
10:59 brrt right
11:00 brrt i only last weekend thought of a way to explain my previous research in a understandable yet correct way
11:00 brrt just 5 months late
11:02 arnsholt That's how these things seems to work
12:32 * timotimo is going to look into the allocation + profile thing
12:33 timotimo param_sn should be the one
12:35 timotimo ah, i didn't see it because it turned into a fastcreate, apparently?
12:51 jnthn That can happen :-)
12:51 jnthn Means "we know we want an empty hash" I guess :)
12:53 dalek joined #moarvm
12:53 timotimo seems like all i need to do is check if something we prof_allocated has only a usage of 1, then kick it out if so
12:53 timotimo (and pray to cthulhu that the usages counts are actually accurate at that point)
12:54 jnthn They really should be
12:54 jnthn Because we use them to do DCE
12:54 jnthn And set collapsing
12:56 timotimo well, it could be things get a bit muddied up during the spesh optimization process
12:57 timotimo i've seen multiple times in the past that a version of a register was just "skipped", and so the facts were not quite accurate any more
12:57 timotimo but those were just cases of "useful information gets forgotten"
12:57 jnthn Yeah. Note that deopt points also cause +1s on the usage
12:58 timotimo yup, that's why i build bridges. well, hope to. in the future.
13:06 timotimo huh. i have a case in the spesh log where i can see the usages count is one, but the optimization didn't fire. i output the usages of every argument to prof_allocated and it's always 2 or more
13:08 timotimo i would say it's probably because the usage got dropped down later in the bb or graph, but the register was already only used for the log after the log insertion phase
13:13 timotimo *scratches head*
13:14 timotimo i'll see if putting that into the second pass helps at all
13:15 timotimo aha! that does it
13:16 timotimo weird. 5,826,423 BOOTHash allocations less, but still the same amount of GC runs?!
13:18 jnthn Are you sure you killed the fastcreate along with the profile instruction? :P
13:18 timotimo hah, good point
13:19 timotimo the removal of dead code happens between the passes, but not afterwards, i expect
13:19 timotimo but i have access to the writer, so i should be able to delete it, too
13:20 timotimo ah, much better :)
13:20 timotimo now it's only 143 gc runs
13:21 timotimo 186 before
13:21 dalek MoarVM: 0c1ee8c | timotimo++ | src/spesh/optimize.c:
13:21 dalek MoarVM: spesh optimizer should kick out prof_allocated
13:21 dalek MoarVM:
13:21 dalek MoarVM: if the only thing that keeps something alive is
13:21 dalek MoarVM: the log instruction for the allocation ...
13:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0c1ee8c219
13:23 timotimo i wonder if we should adopt a common "way to write short commit messages"
13:23 timotimo i read somewhere that a good way to get good commit messages is to pretend it says "when this commit gets merged, it ..." in front
13:23 timotimo actually "it will ..."
13:29 arnsholt Commit messages are hard
13:29 arnsholt Empirically, it also seems to me that lines of commit message is inversely proportional to number of lines in the patch
13:31 timotimo haha
14:02 zakharyas joined #moarvm
14:05 domidumont joined #moarvm
14:18 brrt we could emperically figure that out
15:02 domidumont joined #moarvm
15:09 zakharyas joined #moarvm
15:13 brrt joined #moarvm
15:28 domidumont joined #moarvm
16:01 Util joined #moarvm
17:30 FROGGS joined #moarvm
18:15 timotimo should we have information about stuff that got killed in the gen2 put into the profile?
18:18 timotimo i wonder how costly that is to collect
18:21 timotimo a talk called "visualizing garbage collection in ruby and python" doesn't actually have any visualizations apart from a few boxes with arrows
18:25 arnsholt \o/
18:28 timotimo for me it was no new information, besides that mri (matz' rubi impl) also uses generational GC all in all, and that objects touched by c-extension are "shady objects" that behave differently regarding the write barrier
18:48 pyrimidine joined #moarvm
19:00 lizmat .seen nwc10
19:40 dalek MoarVM: 5933c81 | timotimo++ | src/spesh/optimize.c:
19:40 dalek MoarVM: throw out very spammy debug output
19:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5933c816fb
19:40 timotimo took me really long to notice i had left that in ... ^
19:56 nwc10 lizmat: seen a bot on this channel? :-)
19:56 lizmat no, not really... bur it worked anyway  :-)
19:56 nwc10 I might get summoned away at approx zero notice
19:57 woolfy joined #moarvm
19:57 woolfy left #moarvm
20:50 hoelzro joined #moarvm
21:23 retupmoca joined #moarvm

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