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