| diakopter | well, caching the object's idx (where I think it would be cached) shaves 8% off core setting compilation time, but I get a 'Probable version skew' error when building restricted setting | 00:14 | |
|
00:14
zakharyas joined
|
|||
| diakopter | so it either needs rebootstrapped or there's a make dependency problem or I'm stoopid | 00:14 | |
|
00:25
tokuhiro_ joined
00:29
colomon joined
00:42
colomon joined
00:55
colomon joined
|
|||
| diakopter | .tell jnthn shaved 8% off CORE compilation by writing the idx after looking it up in interp.c i.imgur.com/WX35mFe.png | 01:00 | |
| timotimo | diakopter: did you get the build problem fixed in the time since then? | 01:50 | |
| diakopter | yes, the build problem was for an earlier attempt (not in interp.c) | 01:51 | |
| here's the addl line for OP(scgetobjidx): | 01:53 | ||
| MVM_set_idx_in_sc(&GET_REG(cur_op, 4).o->header, GET_REG(cur_op, 0).i64); | |||
| timotimo: (I tried to cache it in various places, interp.c was the only safe one) | 01:55 | ||
|
02:27
tokuhiro_ joined
02:47
ilbot3 joined
03:36
pyrimidine joined
03:39
psch_ joined
03:46
Hotkeys joined
03:53
JimmyZ joined
03:55
btyler_ joined,
moritz joined
03:56
japhb_ joined
03:57
Hotkeys joined
04:29
tokuhiro_ joined
06:30
tokuhiro_ joined
07:41
nwc10 joined
08:08
domidumont joined
08:13
domidumont joined
08:19
flaviusb joined
08:59
FROGGS joined
09:26
Peter_R joined
09:49
camelia joined
11:00
kjs_ joined
11:01
domidumont joined
11:12
lizmat joined
11:28
tokuhiro_ joined
11:58
vendethiel joined
12:01
leont joined
12:03
vendethiel joined
13:29
tokuhiro_ joined
13:31
brrt joined
|
|||
| brrt | goood * #moarvm | 13:32 | |
| i think i finally know a solution to a problem that's been bugging me | |||
| well, a few solutions to some problems | |||
| nwc10 | good *, brrt | 13:33 | |
|
13:35
kjs_ joined
|
|||
| brrt | good *, nwc10 | 13:38 | |
| problem one is, how to deal with the fact that register flow is broken during the compilation of an epxression tree as a result of the expression tree containing calls and conditionals | 13:40 | ||
| well, i'm not 100% finished with it, but i think the best thing is to divide the (linearised) tile list into ... basic blocks | 13:41 | ||
| (such innovation, many wow) | |||
| the second problem was how to ensure that some operations have their operands in speciifc registers | 13:46 | ||
| for instance, imul and idiv operands | |||
| need rax/rcx pair | |||
| so the solution, as far as i can see, is to give the tile a register flags field and implement a platform-specific flag decoder which can assign registers | 13:49 | ||
| these | 13:50 | ||
| 'flagged' tiles can then be scanned first to assign registers first | |||
| whereas unflagged tiles can use any old register | 13:51 | ||
| dunno if any of that makes any sense.. :-) | 13:54 | ||
| nwc10 | I'm not the right person to ask that question to | 13:57 | |
| brrt | hmm... well, ok | ||
| :-) | |||
| brrt brb | 13:59 | ||
|
14:00
brrt joined
|
|||
| brrt | anyway, i'm happy because i have a clear and reachable goal again | 14:08 | |
| anyway, off again | 14:10 | ||
| see you | |||
| have a nice sunday :-) | |||
|
14:30
tokuhiro_ joined
14:41
kjs_ joined
16:05
vendethiel joined
16:11
FROGGS joined
16:32
tokuhiro_ joined
16:35
FROGGS joined
17:00
FROGGS joined
17:13
Ven joined
17:21
Ven joined
|
|||
| diakopter | best core setting compilation time in a bunch of runs (without the one-line patch above): 72.0 seconds | 17:25 | |
| timotimo | on my machine i usually get a bit under 50 | 17:26 | |
| diakopter | try it with the patch? | ||
| 50 for stage parse or the whole thing | 17:27 | ||
| timotimo | parse stage | 17:28 | |
| right, you're measuring everything | |||
| diakopter | most of the improvement is actually in optimize/mast | ||
| timotimo | where does that line go? | ||
| beginning? end? | |||
| diakopter | best core setting compilation time in a bunch of runs (with the patch): 67.6 seconds | ||
| timotimo | ah, at the end | ||
| my computer is too busy for a good benchmark at the moment | 17:29 | ||
| diakopter | ok, moving onto the next hotspot that seems possible aberrant | 17:30 | |
| *possibly | |||
|
17:35
Ven joined
17:49
Ven joined
17:57
zakharyas joined
18:12
zakharyas joined
19:24
mj41 joined
20:21
FROGGS joined
20:50
sivoais joined
20:54
kjs_ joined
22:25
tokuhiro_ joined
|
|||
| hoelzro | o/ #moarvm | 22:46 | |
| I'm looking at a memory leak in cleaning up comp units; it seems that body->callsites[i]->arg_flags is malloc'd, but never freed | |||
| problem is, callsites[i] may sometimes refer to a common callsite, so we can't just free its arg_flags | 22:47 | ||
| should I add a way to check if a callsite is a common callsite? or maybe there's a better way to go about this? | |||
|
23:20
ggoebel2 joined,
ggoebel3 joined
23:22
ggoebel4 joined
23:31
tokuhiro_ joined
23:34
ggoebel5 joined
23:35
ggoebel6 joined
|
|||
