|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
03:00
lucasb left
03:56
sena_kun joined
04:43
sena_kun left
05:44
domidumont joined
06:13
domidumont left
07:26
robertle joined
07:47
domidumont joined
08:46
dogbert17 left
08:58
sena_kun joined
09:31
zakharyas joined
09:50
zakharyas left
10:00
domidumont left
|
|||
| Geth | MoarVM: 38915b934d | (Jonathan Worthington)++ | 4 files Tweak spesh logging's new compunit handling/quotas The mechanism to put a new spesh log in place when we see a new compilation unit is helpful for making sure we do decently at OSR for program mainlines. However, it was not so well engineered; recent Rakudo changes made it start to miss out on optimizing some programs, but it also turned out to be to blame for #968. Tune the mechanism, thus ... (5 more lines) |
10:04 | |
|
10:25
zakharyas joined
11:41
zakharyas left
11:48
domidumont joined,
domidumont left
11:49
domidumont joined
11:55
lucasb joined
12:04
Guest15407 joined
|
|||
| Guest15407 is trying to reproduce the last/latest fromspace bug | 13:32 | ||
|
13:41
zakharyas joined
|
|||
| Geth | MoarVM: 1fd0fdcd68 | (Jonathan Worthington)++ | 8 files Fix stack simulation losing track in some cases When we had specialized code calling unspecialized code, it was possible for the stack in the specializer's stack simulation to keep on growing. This made searches on it far more costly, not to mention increasing memory use (though bounded to the point that the unspecialized code got to being specialized, so it wasn't unbounded). Make sure that we log enough to know to take such frames away again. Fixes #1060. |
13:46 | |
| MoarVM/frame-opts: f7aecd905b | (Jonathan Worthington)++ | 12 files Only create arg processing context if needed Most specialized frames do not need it, since they rewrite their argument processing code into something far cheaper. We can also save the cost of cleaning it up afterwards. On a benchmark doing quite a lot of non-inlinable calls, this saved ~2% of the total CPU cycles, as measured by callgrind. |
13:55 | ||
| MoarVM/frame-opts: 72fb2f3305 | (Jonathan Worthington)++ | src/moar.c Make MVM_HASH_RANDOMIZE properly control hash rand Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also. |
|||
| MoarVM/frame-opts: 676a6ed0c0 | (Jonathan Worthington)++ | 8 files Avoid having to NULL ->extras on each frame By using ->flags instead. This saves us at least one CPU instruction per call frame creation. |
13:56 | ||
|
14:02
squashable6 left
14:03
squashable6 joined
|
|||
| Geth | MoarVM: 5f177f5828 | (Jonathan Worthington)++ | src/moar.c Make MVM_HASH_RANDOMIZE properly control hash rand Before, if one set it to 0, some randomization could still happen. The sure-fire way to make sure that doesn't happen is to just fix the hash secrets to 0 also. |
14:09 | |
| MoarVM/frame-opts: 18654e8c32 | (Jonathan Worthington)++ | 12 files Only create arg processing context if needed Most specialized frames do not need it, since they rewrite their argument processing code into something far cheaper. We can also save the cost of cleaning it up afterwards. On a benchmark doing quite a lot of non-inlinable calls, this saved ~2% of the total CPU cycles, as measured by callgrind. |
|||
| MoarVM/frame-opts: e2b8aa10fe | (Jonathan Worthington)++ | 8 files Avoid having to NULL ->extras on each frame By using ->flags instead. This saves us at least one CPU instruction per call frame creation. |
14:10 | ||
| timotimo | i see this latest one is a rebase, i *thought* i had already seen at least one of these commits before | ||
| jnthn | I then re-ordered the branch so I could pick out the first commit into master, since it's not really related to what's in the branch at all, and helpful otherwise | 14:11 | |
| timotimo | OK, that makes sense | 14:21 | |
| jnthn | There's something wrong with at least one of the two commits in that branch | 14:23 | |
| Going to have a got at github.com/rakudo/rakudo/issues/3114 first though | |||
| Geth | MoarVM: cf3b545e53 | (Jonathan Worthington)++ | 3 files Reinstate callsite during uninlining This fixes the bug in github.com/rakudo/rakudo/issues/3114. It's possible that there may be situations that need a more complete args processing context too, but for the crash in question this is sufficient. |
15:02 | |
|
15:26
zakharyas left
15:39
domidumont left
15:52
robertle left
16:23
domidumont joined,
domidumont left
16:24
domidumont joined
17:00
robertle joined
17:06
zakharyas joined
17:14
domidumont left
17:22
domidumont joined
17:24
domidumont left
18:16
domidumont joined
18:19
domidumont left
18:32
Elronnd joined
18:38
zakharyas left
18:43
zakharyas joined
18:58
dogbert17 joined
19:13
zakharyas left
|
|||
| Kaiepi | building moarvm with clang generates 49 warnings on my machine, but i don't really have the time to fix them for a couple weeks | 20:01 | |
| timotimo | surely in part my fault for being a little sloppy with fprint macros | 20:11 | |
|
20:12
brrt joined
20:31
MasterDuke joined
|
|||
| Elronnd | even just including the headers generates quite a few warnings | 20:33 | |
| timotimo | can you paste them somewhere? | ||
| Elronnd | sure, one sec | 20:34 | |
| a bunch of them are unused static inline functions, which is maybe not much of a concern but would still be nice to do something about | |||
| Geth | MoarVM/expr-jit-devirtualize: 4 commits pushed by (Bart Wiegmans)++ | 20:36 | |
| timotimo | well, if you only include headers, the static inline functions surely won't be used at all | ||
| Elronnd | yes | ||
| 0x0.st/zJTV.txt | |||
|
21:04
lucasb left
21:17
sena_kun left
21:25
japhb left
21:47
japhb joined
22:44
brrt left
|
|||