3 ms·
> Note that the above “if” starts with “if instance variables types remain the same”. But how can we know that? The problem is that the compiler determines thei
by 13of40 11y ago
> Note that the above “if” starts with “if instance variables types remain the same”. But how can we know that? The problem is that the compiler determines their
> type by traversing the program, instantiating methods, and checking what gets assigned to them. So we can’t really reuse the cache because we can’t know the final
> types until we type the whole program! It’s a chicken and egg problem."
Maybe I'm oversimplifying it, but suppose you compiled a statement like...
a++
...into something like...
if a is an integer (which would presumably be something fast like "CMP [RAX],123; JNZ NotAnInteger") do "INC [RAX+8]", otherwise do more expensive stuff to look up the actual type and a function to use as a ++ operator?
As long as the programmer sticks to the same type, the compiled expression runs fast, and if they switch types midstream, it still runs, albeit with a performance hit.
- tekacs 11y agoYou might be interested in deoptimisation: :) http://chrisseaton.com/rubytruffle/deoptimizing/ http://chrisseaton.com/rubytruffle/deoptimizing/ This would have the effect that you describe (actually even faster than what you're proposing, by essentially trapping on all changes to the target to know ahead of time that deoptimisation has to occur), but it's not the world's most trivial feature to implement.
- PeCaN 11y agoThat's what a lot of JIT compilers do. SpiderMonkey for example does type inference in the interpreter (or baseline JIT? what do they use now) and uses that to generate almost exactly what you're describing. If the type inference holds (it usually does, even in dynamic languages) then you get almost native performance.
- mvitorino 11y agoDon't really know Crystal but it seems to me that it is statically compiled which means you need to find the type of 'a' at compile time. The approach you suggest is more commonly used in dynamic languages and involves keeping at runtime a tag on every single value that indicates it's type (memory and speed overhead). You would be trading compile time with run time. Also it seems that not only it is statically compiled, it produces a static binary in the target platform. If, like others suggest in this thread, you were to optimize at runtime instead of generating the alternate paths, you would need a bytecode representation of the program embedded in the executable and very likely a virtual machine with the optimiser and capability to hot reload code. Any of these options would be a substantial departure of the current path the language is taking.
- asterite 11y agoWe mostly want to never have to do this. This way we can guarantee that "no method error" never happens at runtime (one of the most feared exceptions after a big refactor in a dynamically typed language)