4 ms·

> For example, it's not possible to statically determine whether a function should be inlined or not. MLton has absolutely no problems inlining functions, even

> For example, it's not possible to statically determine whether a function should be inlined or not. MLton has absolutely no problems inlining functions, even higher-order functions, at compile time. This is only difficult in languages with virtual methods, because they can be overridden anywhere. If anything, that's an indictment of virtual methods, not AOT compilers. > However, a JIT can see that it's used in a hot loop and dynamically inline. What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop. > For any language, no matter the type system, runtime information will always be a superset of compile-time information. Runtime information is always anecdotal, specific to one particular run of a program, so... > There will always exist optimizations in a JIT that aren't possible in an AOT compiler. ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound. > Idiomatic Java code doesn't use these features heavily. Language implementations must work correctly whether you write idiomatic or unidiomatic code. > Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed. Most code I write in Python could be given static types too. That doesn't make Python a statically typed language. And “strongly typed” doesn't really mean anything.

smallnamespace 10y ago
> MLton has absolutely no problems inlining functions, even higher-order functions, at compile time Of course, but how does it know which functions to inline? If you inline everything, then you will blow through your cache. > What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop. That's not true--a JIT could optimistically replace with a concrete realization. > Runtime information is always anecdotal, specific to one particular run of a program, so... That's a benefit. No matter what AOT compiled code you have, it is possible to speed up execution if you know what code paths you will take. > ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound. Yes, but so what? As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. You can equally well write deliberately obfuscated code that an AOT compiler has trouble with. > Language implementations must work correctly whether you write idiomatic or unidiomatic code. Implementation is correct. Only reflection is slow. If you don't want that, don't write reflection.
- catnaroek 10y ago
  > Of course, but how does it know which functions to inline? Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) > That's not true--a JIT could optimistically replace with a concrete realization. You'd have to roll back an unsound optimization in the middle of a hot loop. I'm pretty sure that's not what you want. > it is possible to speed up execution if you know what code paths you will take. That knowledge can be encoded statically in many cases, if only you used the right languages. > As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. This is only the case when your program wasn't close to optimal to begin with. > You can equally well write deliberately obfuscated code that an AOT compiler has trouble with. Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. The static analysis either tells you that your program is gibberish, or outputs nonsensical gibberish of its own. So the path of least resistance is to write code that the static analysis knows how to optimize. Which is not the case in dynamic languages (including pseudo-static ones like Java). > Only reflection is slow. If you don't want that, don't write reflection. So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
  - smallnamespace 10y ago
    > Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) But then you're just guessing. Isn't that also inelegant? Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that it shouldn't, and it will fail to inline other functions that it should. It will do worse than a JIT at this, because the JIT has more information. > That knowledge can be encoded statically in many cases, if only you used the right languages. Sure, but you won't ever succeed in encoding all of it, which is why runtime techniques can have a place. > This is only the case when your program wasn't close to optimal to begin with. That's simply untrue, and you can prove that formally -- given a machine M and a program P that produces outputs on a set of inputs I, it is always possible to come up with a program P' that produces those outputs with fewer steps on some subset of I, in return for taking more steps on the rest of I (except in the trivial case where the running time is completely independent of input). You can view a JIT as iteratively replacing P with P' after it sees which inputs I are most common, and this is true no matter what M, P, or I are. In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. > Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. I don't see how that isn't equally applicable to writing code to fool your JIT. > So. basically, you're telling me to ditch Java's entire library and framework ecosystem? Framework code doesn't generally run inside your inner loops, so I don't see how that should affect either your AOT or JIT compiler much.

smallnamespace 10y ago

> MLton has absolutely no problems inlining functions, even higher-order functions, at compile time Of course, but how does it know which functions to inline? If you inline everything, then you will blow through your cache. > What if it's a virtual method call that's known to be overridden in several places? You can't inline it, even if it's in the middle of a hot loop. That's not true--a JIT could optimistically replace with a concrete realization. > Runtime information is always anecdotal, specific to one particular run of a program, so... That's a benefit. No matter what AOT compiled code you have, it is possible to speed up execution if you know what code paths you will take. > ... for every “optimization” a JIT can perform, there will always exist a program for which the “optimization” will have to be rolled back after it has already been performed, because it turned out to be unsound. Yes, but so what? As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. You can equally well write deliberately obfuscated code that an AOT compiler has trouble with. > Language implementations must work correctly whether you write idiomatic or unidiomatic code. Implementation is correct. Only reflection is slow. If you don't want that, don't write reflection.

catnaroek 10y ago
> Of course, but how does it know which functions to inline? Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) > That's not true--a JIT could optimistically replace with a concrete realization. You'd have to roll back an unsound optimization in the middle of a hot loop. I'm pretty sure that's not what you want. > it is possible to speed up execution if you know what code paths you will take. That knowledge can be encoded statically in many cases, if only you used the right languages. > As long as it improves performance in the average case, and the worst case is bounded, then that is a net win. This is only the case when your program wasn't close to optimal to begin with. > You can equally well write deliberately obfuscated code that an AOT compiler has trouble with. Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. The static analysis either tells you that your program is gibberish, or outputs nonsensical gibberish of its own. So the path of least resistance is to write code that the static analysis knows how to optimize. Which is not the case in dynamic languages (including pseudo-static ones like Java). > Only reflection is slow. If you don't want that, don't write reflection. So. basically, you're telling me to ditch Java's entire library and framework ecosystem?
- smallnamespace 10y ago
  > Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) But then you're just guessing. Isn't that also inelegant? Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that it shouldn't, and it will fail to inline other functions that it should. It will do worse than a JIT at this, because the JIT has more information. > That knowledge can be encoded statically in many cases, if only you used the right languages. Sure, but you won't ever succeed in encoding all of it, which is why runtime techniques can have a place. > This is only the case when your program wasn't close to optimal to begin with. That's simply untrue, and you can prove that formally -- given a machine M and a program P that produces outputs on a set of inputs I, it is always possible to come up with a program P' that produces those outputs with fewer steps on some subset of I, in return for taking more steps on the rest of I (except in the trivial case where the running time is completely independent of input). You can view a JIT as iteratively replacing P with P' after it sees which inputs I are most common, and this is true no matter what M, P, or I are. In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. > Yes, but languages amenable to static analysis will actively get in your way if you try to write such obfuscated code. I don't see how that isn't equally applicable to writing code to fool your JIT. > So. basically, you're telling me to ditch Java's entire library and framework ecosystem? Framework code doesn't generally run inside your inner loops, so I don't see how that should affect either your AOT or JIT compiler much.