02:13 vendethiel- joined 03:34 dalek joined 06:30 domidumont joined 06:36 domidumont joined 06:56 colomon joined 07:31 zakharyas joined
dalek arVM: 6dad163 | (David Warring)++ | src/6model/serialization.c:
fix sha1 op to work with null bytes
07:55
arVM: fe26e95 | timo++ | src/6model/serialization.c:
Merge pull request #385 from dwarring/sha1-fix

fix sha1 op to work with null bytes
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
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
brrt good * 08:18
timotimo good
brrt i'm itching to start coding... but have to finish thesis first :-( 08:20
jnthn can easily imagine coding being more attractive than thesis writing :) 08:30
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:31
brrt we'll see 08:34
:-)
timotimo my head's yearning for a nap :| 08:36
08:46 domidumont joined
brrt do you have time for a nap? 08:47
09:58 zakharyas joined 10:22 domidumont joined
timotimo i took one anyway 10:28
so, regarding the profiler thing
i thought we were doing orig-bytecode + profile => execution, then orig-bytecode + logging + profile => execution, then orig-bytecode + speshed + profile => execution 10:29
because i don't seem to recall spesh log ever showing the profiling ops being added
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
aha! i must have been wrong 10:33
yes, indeed, i see the prof_* instructions there
brrt i wonder how much trouble it'd be to have loop hotness counts within routines 10:41
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! =)
brrt one of the major things, for me at least 10:43
code is never bullshit
arnsholt In fact, I've done some fun codings in the last three months when I've been procrastinating...
brrt research is always treading a fine line
brrt knows about that
well, from personal epxerience, not about your procrastinating :-)
arnsholt I assumed =D 10:44
Yeah, research is tricky
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
brrt right 10:59
i only last weekend thought of a way to explain my previous research in a understandable yet correct way 11:00
just 5 months late
arnsholt That's how these things seems to work 11:02
timotimo is going to look into the allocation + profile thing 12:32
param_sn should be the one 12:33
ah, i didn't see it because it turned into a fastcreate, apparently? 12:35
jnthn That can happen :-) 12:51
Means "we know we want an empty hash" I guess :)
12:53 dalek joined
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
(and pray to cthulhu that the usages counts are actually accurate at that point)
jnthn They really should be 12:54
Because we use them to do DCE
And set collapsing
timotimo well, it could be things get a bit muddied up during the spesh optimization process 12:56
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
but those were just cases of "useful information gets forgotten"
jnthn Yeah. Note that deopt points also cause +1s on the usage
timotimo yup, that's why i build bridges. well, hope to. in the future. 12:58
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:06
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:08
*scratches head* 13:13
i'll see if putting that into the second pass helps at all 13:14
aha! that does it 13:15
weird. 5,826,423 BOOTHash allocations less, but still the same amount of GC runs?! 13:16
jnthn Are you sure you killed the fastcreate along with the profile instruction? :P 13:18
timotimo hah, good point
the removal of dead code happens between the passes, but not afterwards, i expect 13:19
but i have access to the writer, so i should be able to delete it, too
ah, much better :) 13:20
now it's only 143 gc runs
186 before 13:21
dalek arVM: 0c1ee8c | timotimo++ | src/spesh/optimize.c:
spesh optimizer should kick out prof_allocated

if the only thing that keeps something alive is the log instruction for the allocation ...
timotimo i wonder if we should adopt a common "way to write short commit messages" 13:23
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
actually "it will ..."
arnsholt Commit messages are hard 13:29
Empirically, it also seems to me that lines of commit message is inversely proportional to number of lines in the patch
timotimo haha 13:31
14:02 zakharyas joined 14:05 domidumont joined
brrt we could emperically figure that out 14:18
15:02 domidumont joined 15:09 zakharyas joined 15:13 brrt joined 15:28 domidumont joined 16:01 Util joined 17:30 FROGGS joined
timotimo should we have information about stuff that got killed in the gen2 put into the profile? 18:15
i wonder how costly that is to collect 18:18
a talk called "visualizing garbage collection in ruby and python" doesn't actually have any visualizations apart from a few boxes with arrows 18:21
arnsholt \o/ 18:25
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:28
18:48 pyrimidine joined
lizmat .seen nwc10 19:00
dalek arVM: 5933c81 | timotimo++ | src/spesh/optimize.c:
throw out very spammy debug output
19:40
timotimo took me really long to notice i had left that in ... ^
nwc10 lizmat: seen a bot on this channel? :-) 19:56
lizmat no, not really... bur it worked anyway :-)
nwc10 I might get summoned away at approx zero notice
19:57 woolfy joined, woolfy left 20:50 hoelzro joined 21:23 retupmoca joined