01:48 ilbot3 joined 05:36 domidumont joined 05:42 domidumont joined 05:55 brrt joined 06:43 domidumont joined 06:49 brrt joined 07:33 zakharyas joined
brrt \o #moarvm 09:09
nwc10 good *, brrt 09:17
brrt ohai nwc10 09:22
10:10 pyrimidi_ joined 14:29 hoelzro joined 15:28 ggoebel joined 16:00 brrt joined 16:40 domidumont joined 17:52 brrt joined
timotimo huh 18:50
i'm looking into making CStruct attribute accesses speshed 18:51
it looks a bit complicated, because we're going through an extra STable per attribute
but now that i'm starting to write about it here on IRC, i understand that it's all about different sized ints and such 18:52
i wonder how to best spesh that ...
also, i can most probably still just re-use the code from P6opaque's spesh function 1:1 18:59
except i have to turn p6oget_* into get_* because we don't have a REAL_DATA indirection 19:00
dang it. if i had looked at the spesh log before i would have known we don't generate getattr or bindattr for those cases, we use attrref and we don't have the infrastructure to lower those to bindattr/getattr yet 19:09
yeah, and in this case i have here the attrref is immediately passed on as an argument to an invocation, so no optimization for this would happen anyway 19:12
boo.
though getattrref may get the same kind of optimization where it wouldn't have to go through finding the right offset each time 19:19
though to be honest, that code doesn't seem to appear in the perf report at all ... 19:21
timotimo tries callgrind instead
yeah, the CStruct object file hardly comes up at all 19:57
20:13 zakharyas joined
timotimo going grocery shoppign helped me figure out that getattrref can't get an optimization based on offsets 20:14
TimToady you should go grocery shopping more often, or maybe less often... 20:26
timotimo :)
21:38 ggoebel joined, stmuk joined, BinGOs joined, arnsholt joined, krunen_ joined, [Coke] joined 21:40 camelia joined, TimToady joined, synopsebot6 joined, nwc10 joined, jnthn joined, mst joined, konobi joined, _longines joined 21:42 brrt joined, krunen joined
timotimo i'm really not very sure what's making my code so slow. 50% of run time is spent in enqueue alone 21:45
(inclusive, not exclusive)
(that's the sub that sorts rects into CArray queues by color) 21:46
dalek arVM/line_based_coverage_4: 794c3c4 | (Zoffix Znet)++ | tools/parse_coverage_report.p6:
Include a note on the date/time when the report was generated
22:53
arVM/line_based_coverage_4: fb8f50d | jnthn++ | tools/parse_coverage_report.p6:
Merge pull request #411 from zoffixznet/patch-1

Include a note on the date/time when the report was generated
timotimo our MVMInstance doesn't actually have an array (or some other collection) of threads? 23:44
i suppose the profiler currently doesn't collect data from all threads because threads have to be blocked for it to be reliable? 23:45
also, when threads get joined, data ought to be placed somewhere
hm. it'd probably be sensible to join all threads for ending the profile ... but not all threads are cooperative about ending 23:52
timotimo does some more shrugging 23:53