|
00:04
i42 joined
00:52
i42 joined
01:36
fengc joined
05:53
domidumont joined
06:12
domidumont joined
07:18
zakharyas joined
08:04
domidumont joined
|
|||
| jnthn | moarning o/ | 08:42 | |
| nwc10 | good *, jnthn | ||
|
08:52
domidumont joined
09:32
patrickz joined
09:39
domidumont joined
09:42
domidumont joined
11:38
domidumont joined
|
|||
| dalek | arVM: 882c50d | jnthn++ | / (10 files): Implement payload throw/handler support. To more effciently provide for implementing `return` using control exceptions instead of the lexotic mechanism. |
12:14 | |
|
13:36
domidumont joined
|
|||
| dalek | arVM: 018a4ee | jnthn++ | src/core/exceptions.c: Implement callerlex throwing mode. Skips the current routine (and then any thunks) before looking for a lexical handler. Which is precisely what Perl 6 returns need. |
13:38 | |
| nwc10 | jnthn: keep trying (you've still not tripped ASAN) | 13:46 | |
| jnthn | :) | 13:47 | |
| Just pushed the Rakudo patch also | |||
| Didn't spectest it yet | |||
| Just got a bit ahead of myself and decided to benchmark. Things came out *worse* on the loop benchmark. Looked at the callgrind output and realized...I didn't add the new ops to the JIT yet :) | |||
| dalek | arVM: be612b2 | jnthn++ | src/ (4 files): Elimiante needing a NULL check. Faster and will make things easier to JIT. |
13:53 | |
| arVM: dbdc82f | jnthn++ | src/gc/roots.c: GC mark last_payload. |
13:56 | ||
|
13:58
patrickz joined
|
|||
| dalek | arVM: d221b2e | jnthn++ | src/jit/ (2 files): JIT lastexpayload. |
14:11 | |
| jnthn | With that it's cheaper. :) | ||
| (Than with the lexotic return thing) | 14:12 | ||
| 10,989,973,606 -> 10,687,951,433 CPU instructions, or around 2.7% improvement. | |||
| m: say 10976016 - 10894440 | 14:14 | ||
| camelia | rakudo-moar 069b78: OUTPUTĀ«81576ā¤Ā» | ||
| jnthn | 81.5 KB smaller CORE.setting due to smaller code | 14:15 | |
| m: say 5820016 - 5810008 | 14:16 | ||
| camelia | rakudo-moar 069b78: OUTPUTĀ«10008ā¤Ā» | ||
| jnthn | 10KB off the size of the compiler itself | ||
| NQP got a bit bigger 'cus of the added ops etc. | |||
| Oh, but only by 2KB | 14:17 | ||
|
14:18
domidumont joined
|
|||
| nine | jnthn: will that mean that we can use explicit return again? | 14:22 | |
|
14:25
brrt joined
|
|||
| timotimo | not bad | 14:27 | |
| jnthn | nine: Why can't you now? :) | 14:32 | |
| timotimo | because it's awfully slow and doesn't belong on hot paths :P | 14:33 | |
| a lot of work has gone into the core setting for getting rid of returns by using ternaries and such | 14:34 | ||
| jnthn | Ah, yeah, on hot paths that could be an issue | ||
| I don't know without measuring, but this should work out a decent bit cheaper when I'm done | |||
| timotimo | aye, i expect that, too | 14:35 | |
| jnthn | Think is that the non-explicit return case will also get faster too :P | ||
| *Thing | |||
| timotimo | that's good news, too! | ||
| jnthn turns return and return-rw into subs, and gets bizzare failure | 14:51 | ||
| timotimo | hm, turn off the static optimizer for a bit? | 14:55 | |
| jnthn | We're not even making it that far | 14:58 | |
| jnthn makes sure a parallel "innocent" change he did in Moar isn't to blame :) | 14:59 | ||
| nope | |||
| timotimo | oh, hm | 15:01 | |
| jnthn | Changing just return-rw is harmless | 15:03 | |
|
15:04
edehont joined
|
|||
| jnthn | And it gets stranger still. We don't end up inside the return point at all during compilation | 15:06 | |
| but...we call it loads once I make it a sub?! | 15:08 | ||
| When it's a pointy we don't assign it until startup I guess, so code trying to use return at compile time would thus fail. Apparently we're relying on that :P | 15:10 | ||
| Damn, it is that. We somehow during canonicalizing colonpair names relied on val always failing to get the right outcome | 15:23 | ||
| japhb | That's ... an odd dependency | 15:25 | |
| jnthn | Very | 15:28 | |
| I mean, an infix:<<(<)>> would take a pass through val | 15:29 | ||
| Since the << >> imply that | |||
| japhb | Oh. Weird. | 15:30 | |
| timotimo | if that always goes through val, maybe we should consider using [' '] instead for those cases to speed things up a bit in general? | 15:31 | |
| jnthn | Quite possibly :) | 15:32 | |
| Anyway, it seems that a failing val just returns the original string | |||
| Ugh, this'll take some untangling. | 15:39 | ||
| Good point for a break. :) | |||
| timotimo | dance the untango | ||
| jnthn reverts the "make return a sub" part and runs a spectest while he rests, to see what over fallout there may be | 15:40 | ||
|
15:59
brrt joined
16:07
patrickz joined
16:57
zakharyas joined
17:12
edehont joined
17:40
TimToady joined
20:53
sivoais joined
23:00
avar joined
|
|||