github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:48
patrickb joined,
patrickb left,
patrickb joined,
patrickb left
00:52
patrickz left
01:01
MasterDuke joined
01:02
MasterDuke left,
MasterDuke joined
|
|||
MasterDuke | timotimo: did that patch you made to optimize invoking .Str/.Num/.Int get merged already? | 01:03 | |
timotimo | looks like it hasn't been merged | 01:29 | |
MasterDuke | k. just wanted to make sure i didn't need to update some of the comments that mention those in my PR | 01:33 | |
timotimo: btw, think any of the stuff currently commented out here github.com/MoarVM/MoarVM/blame/2ae...ize.c#L340 could be uncommented? | 01:40 | ||
timotimo | could be attempted | 01:43 | |
MasterDuke | oh, and any idea why we don't have a branch for num here? github.com/MoarVM/MoarVM/blame/2ae...#L946-L965 | ||
timotimo | not sure | 01:44 | |
MasterDuke | hm, maybe i'll try those things after that PR is merged | ||
timotimo | the PR could surely go into postrelease-opts soon | 01:45 | |
i'll go have a sleep. seeya! | 01:48 | ||
MasterDuke | later... | 01:54 | |
02:38
Guest32385 is now known as masak
04:50
AlexDani` joined
04:55
AlexDaniel left
05:41
brrt joined
05:56
robertle joined
06:07
robertle left
06:33
domidumont joined
07:21
domidumont left,
domidumont joined
|
|||
nine | Was the plan not at some point to create release branches and keep master open for development at all times? | 07:51 | |
brrt | plan, never executed | 08:05 | |
good * nine | |||
nine | Good morning! | 08:13 | |
nwc10 | good *, #moarvm | 08:19 | |
08:33
zakharyas joined
08:54
harrow left
09:04
harrow joined
09:06
harrow left
09:18
harrow joined
09:38
domidumont1 joined
09:40
domidumont left
|
|||
jnthn | Good morning o/ | 09:57 | |
nwc10 | \o | 09:58 | |
jnthn | Currently playing with some patches that has us explicitly label types that could be the target of a mixin | 10:12 | |
The idea being that if we specialize on a P6opaque-based type without that set, then we know it will not have any real_data pointer | 10:13 | ||
And so can have ~4 instructions (including a conditional move) off every attribute read/write | 10:14 | ||
10:19
domidumont1 left
10:21
AlexDani` is now known as AlexDaniel
10:22
Geth left,
Geth joined
|
|||
Geth | MoarVM/postrelease-opts: b51bb13296 | (Jonathan Worthington)++ | 8 files Add a newmixintype op A form of `newtype` that sets a flag saying that this type can be the target of a mixin. Added as a new op used at type creation time so that we can easily reason about a type always having that property for its lifetime, rather than any timing worries about it being set later. This alone doesn't do anything useful; the useful part will be when we start ... (5 more lines) |
10:35 | |
brrt | oh hey, geth is back again | 10:55 | |
jnthn | Urgh, I wonder why changing it to use the simpler ops is so explosive... | 11:11 | |
Anyway, on one benchmark that does run, just some of them getting rewritten to the simpler form seems to be worth a few percent. | 11:29 | ||
lizmat | jnthn: you are aware of the recent changes in test-t and make spectest performance ? | 11:33 | |
I can sorta understand the make spectest changes | 11:34 | ||
nwc10 | jnthn: ASAN is extremely exited by origin/postrelease-opts | ||
lizmat | but the test-t changes feel worrisome (which I see myself as well) | ||
jnthn | lizmat: Yes, aware; the spectest one isn't a big surprise, the test-t one somewhat is, though | ||
lizmat: Don't panic. | |||
lizmat | I'm not, just wanted to make sure you're aware | 11:35 | |
jnthn | OK, good. | ||
nwc10 | jnthn: it can't even bootstrap NQP | ||
heap-use-after-free | |||
(in spesh) | |||
jnthn | nwc10: huh, interesting | ||
lizmat | FWIW, a --profile on the test-t doesn't have anything that jumps out | ||
jnthn | nwc10: Builds quite happily here; I'll valgrind it | ||
nwc10 | jnthn: this might correlate with "Urgh, I wonder why changing it to use the simpler ops is so explosive..." | 11:36 | |
jnthn | Well, that was in the immediate becuase I screwed up in the JIT... :) | 11:39 | |
Geth | MoarVM/postrelease-opts: e41e355e71 | (Jonathan Worthington)++ | 7 files Add vivifying non-p6o object ops Which we'll be able to use to produce simpler code for attribute access to non-mixin types. |
11:46 | |
jnthn | m: say 11533654155 / 11794375512 | 11:51 | |
camelia | 0.97789443309 | ||
jnthn | m: say 11533654155 R- 11794375512 | 11:52 | |
camelia | 260721357 | ||
jnthn | That's probably worth continuing with, especially as it'll only become more of a factor with time... | 11:57 | |
Geth | MoarVM/postrelease-opts: 01e1902c9b | (Jonathan Worthington)++ | src/spesh/optimize.c Fix a use-after-free |
||
jnthn | nwc10++ for reporting | ||
Unfortunately, that isn't The Cause of the instability I was looking for | 11:58 | ||
ah, but I might see what that is | 11:59 | ||
12:01
AlexDaniel left
|
|||
jnthn | oh wow, it looks like there was a longstanding bug in sp_get_o in the interp and a different one in its JIT... | 12:12 | |
12:14
lucasb joined
|
|||
Geth | MoarVM/postrelease-opts: 78e8a60275 | (Jonathan Worthington)++ | src/core/interp.c Correct interp implementation of sp_get_o It was failing to deference the target address it calculated. |
12:16 | |
MoarVM/postrelease-opts: c5e432653a | (Jonathan Worthington)++ | src/jit/x64/emit.dasc Make JIT of sp_get_o match the interp That is, add the NULL -> VMNull mapping logic in there. |
|||
jnthn | Lunch now | ||
12:20
robertle joined
12:28
zakharyas left
12:50
brrt left
12:57
brrt joined
|
|||
jnthn | Yes, and with those, my local patch set for attr access speedups passes spectest | 13:13 | |
It fails a couple of NQP tests (the tests need adaptation) and also I probably need to rebootstrap JVM; I'll clean that lot up in the future. | 13:14 | ||
13:55
domidumont joined
13:56
domidumont left
14:00
domidumont joined
14:18
zakharyas joined
14:29
dogbert2_ left
15:20
AlexDaniel joined
16:54
lucasb left
16:59
brrt left
17:00
brrt joined
|
|||
Geth | MoarVM/postrelease-opts: c5f47fba7c | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c Require rebless target type is a mixin type Testing this branch going forward requires the identify-mixin-types branches in both NQP and Rakudo. |
17:26 | |
MoarVM/postrelease-opts: 0cc8b2b8c5 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c Produce simpler attribute access instructions Only for object type attributes so far. When we know the target type is not a mixin type, we can go directly for the attributes, rather than needing to do the real_data dance, which saves four instructions per attribute access. |
|||
17:43
domidumont1 joined
17:44
domidumont1 left
17:47
domidumont left,
brrt left
17:50
domidumont joined
17:51
domidumont left
17:52
domidumont joined
17:53
domidumont left,
domidumont joined
17:55
domidumont left
18:20
vendethiel- joined
18:36
vendethiel- left
18:37
vendethiel- joined
19:10
zakharyas left
|
|||
timotimo | cool. what kind of type won't allow mixed in? | 19:27 | |
just roles? | 19:28 | ||
this ought to also make P6opaque "as cheap as" CStruct "for real" :D | 19:36 | ||
19:52
vendethiel- left
20:32
vendethiel- joined
20:36
zakharyas joined
21:15
zakharyas left
22:17
vendethiel- left
|
|||
jnthn | timotimo: Well, only if we pre-initialize the attrs so we don't gotta null check 'em all, but then we need a new solution to nqp::attrinitted | 22:23 | |
japhb | jnthn: Are those null checks or VMNull checks? | 22:25 | |
jnthn | japhb: Really null checks. We use (C) NULL as a "this attribute was never touched" sentinel. | ||
japhb: Which seemed clever when everything else was to blame for being slow, and seems annoying now we're getting down to "how many CPU cycles can I make attribute access" :) | |||
(Of course, I want the answer to be "1 if you already have the object in a CPU register") | 22:26 | ||
Geth | MoarVM: apapas++ created pull request #1054: use _wopen on windows |
22:52 | |
22:57
dogbert17 left
|