Hacker News Reader

Comment by catnaroek | Hacker News Reader

I'm admittedly not very familiar with compiler backends - especially not JIT compilers. But how does this optimization even work if I'm constantly modifying the method tables of objects at runtime? If I understand correctly, ORMs and Web frameworks for dynamic languages do this sort of thing all the time.

View on HN

In a JIT for a dynamic language, you generally have to predicate your more aggressive optimizations on some runtime condition, e.g. "this variable is actually an integer", or "this object has the same method layout as other objects did before". These conditions are checked before relying on the optimization, and if they fail, the generated code jumps into a runtime that may decide to use an interpreter, generate deoptimized code, etc.

This actually sounds more complicated thank thinking ahead how to define your abstraction in more precise terms. (So that you don't need to perform optimistic optimizations that you might later need to roll back.)

I don't understand, who should define such abstractions? If you're the JIT developer and you define a value encoding that supports all possible values (so that the JITed function never has to be rolled back), then you can't really optimize.

For example, if the JIT has the code "function(a, b) { return a+b; }", and it sees that the function has been called 50 times with a and b as integers, it can generate a machine code implementation that is just a couple of instructions adding two registers.

If you keep the abstractions wide enough to support other values, you can never achieve this efficiency.

> I don't understand, who should define such abstractions?

The language designer.

> If you're the JIT developer and you define a value encoding that supports all possible values (so that the JITed function never has to be rolled back), then you can't really optimize.

Obviously, the solution is to know the types of values ahead of time. This is precisely where a language with more precise abstractions can make the lives of implementors easier.

Well, yes, but the whole point is to make the lives of the end programmers easier, not of the language implementors. If you want to avoid forcing people to manually tag each variable, the implementors either need to write an optimistic JIT or a really good type inference engine.

More precise abstractions benefit end programmers too:

(0) They increase the effectiveness of code as a communication medium between programmers. To use an analogy: If I tell you a story, you don't need to hire actors to enact it, just to understand the plot. You can just use your knowledge of the English language, right? Imagine if we could do the same with code: programmers conversing in code, because they understand it natively, without having to “interpret” it (in a REPL, using a test suite, etc.).

(1) They decrease the burden of anticipating, preventing and handling things that may go wrong. Again, to use an analogy: Defensive programming in a language with imprecise abstractions is like spending 75% of a construction project's budget on buying insurance.

The fact that precise abstractions usually lend themselves to simpler and more elegant implementations than imprecise abstractions, well, it is just a nice additional benefit.

Clearly there are millions of end programmers who disagree with you, since they could be using a language with more precise abstractions and yet they choose not to. As one of them, my claim is that you need to eliminate the burden of manually tagging each value, because that effort usually isn't worth it. And eliminating that burden while keeping precise abstractions is not an easy task for implementors.

They're generally operating on the assumption that there's some amount of setup that you do initially, maybe the first time you try to call methods on your magic ORM object, that will set up the inheritance for that class and inject the appropriate methods, and then this will mostly stay static for the remainder of the process lifetime. This seems to me like a generally reasonable assumption.

I don't think this scales to systems with more than, say, 50 tables. In an ERP system with dozens of thousands of tables and views, and which supports adding new functionality to a running application server, you can't assume that the database schema will remain fixed throughout the lifetime of the application server process.

Reply on news.ycombinator.com