|
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
|
|||