|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:02
reportable6 left
00:04
reportable6 joined
03:26
squashable6 left,
sourceable6 left,
shareable6 left,
reportable6 left,
nativecallable6 left,
bloatable6 left,
unicodable6 left,
committable6 left,
releasable6 left,
quotable6 left,
statisfiable6 left,
linkable6 left,
tellable6 left,
greppable6 left,
evalable6 left,
bisectable6 left,
coverable6 left,
benchable6 left,
notable6 left,
benchable6 joined,
tellable6 joined,
evalable6 joined,
quotable6 joined,
statisfiable6 joined
03:27
coverable6 joined,
sourceable6 joined,
greppable6 joined
03:28
bisectable6 joined,
linkable6 joined,
shareable6 joined,
notable6 joined,
unicodable6 joined,
committable6 joined,
reportable6 joined,
squashable6 joined,
bloatable6 joined
03:29
nativecallable6 joined,
releasable6 joined
03:58
lucasb left
06:02
reportable6 left
06:03
reportable6 joined
|
|||
| nwc10 | So yes, Guido thinks that spesh is a good idea and Python should have it too: raw.githubusercontent.com/faster-c...onDark.pdf | 07:39 | |
| timotimo | i wonder if the "zero overhead" exception handling is a thing we have in moarvm right now? since we handle exceptions on top of the stack instead of rewinding first | 07:48 | |
| japhb | timotimo: github.com/timo/json_fast/pull/73 -- pretty please? :-) | 07:51 | |
| timotimo | oh! | 07:52 | |
| nwc10 | good morning japhb | 08:02 | |
| clearly far too early in the mornign as I'm trying to hit tab to auto-complete "mor" to "morning" | |||
|
08:03
Altai-man_ joined
08:04
sena_kun left
08:14
Altai-man_ left
08:16
sena_kun joined
08:34
zakharyas joined
|
|||
| japhb | good morning nwc10 :-) | 09:05 | |
| jnthn | timotimo: Some control exception handlers get rewritten into goto in spesh, at least | 09:13 | |
| timotimo | true | 09:29 | |
| anyway, their specialization approach is to have a per-instruction granular decision for specialized and how, or not | 09:30 | ||
| deopt now becomes trivial, but optimizations across opcodes aren't in the cards | |||
| i assume they also benefit from not having to do any cross-thread synchronization here, thanks to the GIL | 09:31 | ||
| other than that, their specialized ops include attribute access and invocation | 09:32 | ||
| i don't think they have a simple avenue towards inlining | 09:33 | ||
| which as we all know rakudo profits a lot from | |||
| but also, our benefits from inlining include parameter passing simplification and tossing out guards on types and such, the first one of which may not be easy for them | 09:34 | ||
| i don't see anything obvious for having multiple specializations of the same code, just that they deoptimize when expectations are violated and toss out the specialization when it's failed too often (compared to how often it succeeds) | 09:35 | ||
| jnthn | Hm, this sounds more like inline caching than the whole spesh thing, going on what timotimo just described... | 09:37 | |
| timotimo | so would this be trouble if you iterate over, say, a list of [k, v, k, v, k, v] and just `print(it)` and keys are strings and values are ints? since specializing the loop body's print call would alternate between success and fail | ||
| yeah, they also describe it as "inline caching, but not totally" | |||
| The closest approach to this PEP in the literature is "Inline Caching meets Quickening" [3]. This PEP has the advantages of inline caching, but adds the ability to quickly deoptimize making the performance more robust in cases where specialization fails or is not stable. | |||
| jnthn | Does that make new-disp "inline caching but a bit too totally"? :) | 09:38 | |
| timotimo | www.complang.tuwien.ac.at/kps09/pdf...thaler.pdf | ||
| haha, you bet | |||
|
10:09
zakharyas left
|
|||
| nine | I wonder why they aim so low when they have 3 people working full time on this and already expect it to take multiple years | 11:57 | |
| nwc10 | you might be underestimating how hard it is | 11:58 | |
| given the constraints of what they are not prepared to break | 11:59 | ||
|
12:02
reportable6 left
12:03
reportable6 joined
|
|||
| lizmat | .oO( that sounds oddly familiar somehow ) |
12:08 | |
| jnthn | Probably retaining predictability makes it a bit non-trivial also, and that seems to be an important consideration for them | 12:10 | |
| See "Virtual Machine Warmup Blows Hot and Cold" for just how "interesting" this gets; MoarVM has all the same troubles. | 12:11 | ||
|
13:08
evalable6 left,
linkable6 left
13:09
linkable6 joined
13:10
evalable6 joined
13:44
zakharyas joined
17:43
MasterDuke joined
18:02
reportable6 left
18:03
reportable6 joined
19:16
zakharyas left
19:47
zakharyas joined
20:11
zakharyas left
23:46
linkable6 left,
evalable6 left
23:48
linkable6 joined
23:49
evalable6 joined
|
|||