| MasterDuke | `loop (my int $i = 1; $i <= 10_000_000; $i = $i + 1) { my uint64 $a = 2**64-1; my int64 $b = 2**62; my int64 $c = -2**63 }; say now - INIT now` took an average of about 3.5s before, 3.4s after | 00:07 | |
|
02:48
ilbot3 joined
06:27
domidumont joined
06:34
domidumont joined
06:39
brrt joined
|
|||
| brrt | good * #moarvm | 06:40 | |
| samcv | good * brrt | 06:55 | |
|
07:04
domidumont joined
07:42
brrt joined
08:22
zakharyas joined
|
|||
| brrt | ohai samcv | 08:30 | |
| samcv | hello | ||
| brrt | i've settled on making spills explicit graph-reducing steps (so that they work with the topological sort), but i'm not 100% positive that i'm doing it correctly yet | 08:31 | |
| samcv | where in MoarVM is this code so i can look at it | 08:32 | |
| brrt | if you check out the even-moar-jit branch, it's in src/jit/linear_scan.c | ||
| in the function prepare_arglist_and_call | 08:33 | ||
| samcv | kk | 08:56 | |
| brrt | :-) | ||
| it's arguably evil code | |||
| well, or 'rather complex' | 08:57 | ||
|
10:47
Ven joined
11:00
KDr2_c joined
|
|||
| brrt back | 11:08 | ||
|
12:26
domidumont joined
|
|||
| brrt | so.. i've done more thinking; the trick in topological sort is that all nodes are eventually handled | 12:53 | |
| or si that all edges? anyway | 12:54 | ||
| so a node (= register) can be blocked due to one of those reasons: it needs to be moved to another register, it needs to be spilled to memory, it needs to be placed on stack | 12:55 | ||
| and there's two reasons a register's value may need to be copied: a): because it needs to be in another register for the arg list, or b): because it's used by CALL as an explicit register | 12:57 | ||
| so any of these 'blocks' should add to the counter, and any of these operations should decrement | |||
|
13:22
spebern joined
13:30
domidumont joined
|
|||
| timotimo | so, actually ... would i want to implement a bytecode-level debugger inside moar, or add more features to moar-gdb.py until it's useful for bytecode-level debugging ... | 13:59 | |
| jnthn | Likely the first :) | 14:00 | |
|
14:00
brrt joined
|
|||
| timotimo | seems like more work :P | 14:00 | |
| jnthn | Doing stuff right often is ;P | ||
| timotimo | especially since if you're a plugin for gdb you can also immediately continue C-level debugging if you're doing internals hacking | ||
| though tbh our ops are usually not terribly buggy :P | |||
| just the composition of ops | |||
|
14:01
brrt joined
|
|||
| timotimo | of course, i'm already supposed to give spesh line-annotations. can use those for the debugger, too. not just the line-coverage tool | 14:18 | |
|
14:29
Ven joined
14:33
brrt joined
15:10
domidumont joined
15:15
brrt joined
|
|||
| timotimo | right now i'm running a benchmark for join and \n and \n\r and unrelated control characters | 15:30 | |
|
15:31
Ven joined
16:09
brrt joined
|
|||
| brrt | yeah, it is a bunch of work | 16:10 | |
| timotimo | hm, well, the benchmark proved uninteresting | 16:46 | |
| but i probably measured an uninteresting workload | |||
| gist.github.com/timo/7477f7cecfc2a...ac98499740 | 16:48 | ||
| i should probably put in a combining character at the beginning of one of these strings | |||
|
16:57
agentzh joined
17:11
agentzh joined
|
|||
| timotimo | this run will take a bit longer :| | 17:15 | |
| all it does is get noisier the more elements i'm joining | 17:22 | ||
|
17:48
dogbert17 joined
18:14
domidumont joined
20:14
domidumont joined
20:15
nebuchad` joined
20:18
harrow joined
20:19
brrt joined
20:23
japhb_ joined
21:54
domidumont joined
|
|||