3 ms·

The important thing is for language users to recognize that nothing is free, and to understand the implications of language features and design decisions they m

The important thing is for language users to recognize that nothing is free, and to understand the implications of language features and design decisions they make in their own programs. I can agree with this statement. Other than that, I have some qualms with the post. For a start, it doesn't consider that compilation takes time. The great thing about JIT compilation is you know everything about the code being run. The bad thing is you have no time to make use of this information. Then there is this: Traditionally, static typing was the best way to guarantee we produced good CPU instructions. It gave us a clear picture of the world we could ponder and meditate over, eventually boiling out the secrets of the universe and producing the fastest possible code. Huh, what? Any compiler author knows that many compiler optimization problems are NP-Complete. For example, graph colouring register allocation is, as the name suggests, NP-complete. You have to do register allocation whether you JIT compile or AOT compile, and you have to do it approximately in both cases. (IIRC typical JIT compilers use a linear scan graph allocation algorithm which is almost as good as graph colouring but much faster.) Furthermore, in the languages he considers there are loads of optimization opportunities that cannot be statically expressed in the language (e.g. stack allocation of memory, immutability, SIMD operations). You can infer many of these statically, but statically typed languages also benefit from JIT optimization using extra information available at runtime in the same way that dynamically typed languages do. Finally, a type theorist would have a fit over how he uses the word "typed" (and they would object to this comment as well.) Types don't exist a runtime -- representations do. Update AOT compilers also allow code to be targeted to specific machines. An obvious example is a Linux distro available in 32-bit and 64-bit versions. GCC allows much finer distinctions than this. AOT compilers can also make use of runtime information -- so-called "profile guided optimisation."

qznc 13y ago
I agree with you, although it comes out unnecessarily rude. However, JIT does not necessarily mean fast compilation (e.g. Linear Scan). A JIT might identify hot spots in the code and the optimize the hell out of that part with the same optimizations that GCC -O3 uses. Plus, it might have additional runtime information. Advanced JIT engines usually have multiple stages of optimization.
- noelwelsh 13y ago
  Rudeness is unintentional. It was written in a hurry.
- nickik 13y ago
  Its a good point about jit time. It is however also true that even if you do it in the background (as for example Azul does, I think) you are not completly free of its problems. It is often hard to firgure out if it is worth the coordination of the background work. Im not complety sure but I think V8 does advanced optimisation on thread. Also I am sure that Lua Jit does everything on a single thread. LuaJit is a special case most of the time since it works so fundamentally diffrent almost all other high performace jits in the wild. It only has one compiler and still works with a interpreter.
mwcampbell 13y ago
I think the reason why he mostly limited his comparison to JIT-compiled implementations is that the most popular languages, at least right now, are not very amenable to AOT optimization. So, taking JIT compilation as a given, he explored the language properties that help or hurt optimization. There are always trade-offs, of course. Sometimes, to gain maximum performance without requiring the overhead of JIT compilation, it makes sense to use C++, so you can be explicit about stack versus heap allocation, boxed versus unboxed values, etc. But I think we can agree that many application developers want to work at a higher level of abstraction while still getting pretty good performance. In that context, one of the languages that he compared is probably a much better fit than C++.
jmatthews 13y ago
Perhaps parallel to your point but not only does compilation take time but development takes even more time. The article essentially compares mutable and immutable values, and their effect on compilation and cycles. Sure the type system is a subset of the larger mutable/immutable issue. The reality is that few implementations would use mutable values "under the hood" if they could make the actual use of the language appear to allow mutables. Stated more simply, In a concurrent world the only benefit of mutable values is the programmers ability to reason about them.

qznc 13y ago

I agree with you, although it comes out unnecessarily rude. However, JIT does not necessarily mean fast compilation (e.g. Linear Scan). A JIT might identify hot spots in the code and the optimize the hell out of that part with the same optimizations that GCC -O3 uses. Plus, it might have additional runtime information. Advanced JIT engines usually have multiple stages of optimization.

noelwelsh 13y ago
Rudeness is unintentional. It was written in a hurry.
nickik 13y ago
Its a good point about jit time. It is however also true that even if you do it in the background (as for example Azul does, I think) you are not completly free of its problems. It is often hard to firgure out if it is worth the coordination of the background work. Im not complety sure but I think V8 does advanced optimisation on thread. Also I am sure that Lua Jit does everything on a single thread. LuaJit is a special case most of the time since it works so fundamentally diffrent almost all other high performace jits in the wild. It only has one compiler and still works with a interpreter.

mwcampbell 13y ago

I think the reason why he mostly limited his comparison to JIT-compiled implementations is that the most popular languages, at least right now, are not very amenable to AOT optimization. So, taking JIT compilation as a given, he explored the language properties that help or hurt optimization. There are always trade-offs, of course. Sometimes, to gain maximum performance without requiring the overhead of JIT compilation, it makes sense to use C++, so you can be explicit about stack versus heap allocation, boxed versus unboxed values, etc. But I think we can agree that many application developers want to work at a higher level of abstraction while still getting pretty good performance. In that context, one of the languages that he compared is probably a much better fit than C++.

jmatthews 13y ago

Perhaps parallel to your point but not only does compilation take time but development takes even more time. The article essentially compares mutable and immutable values, and their effect on compilation and cycles. Sure the type system is a subset of the larger mutable/immutable issue. The reality is that few implementations would use mutable values "under the hood" if they could make the actual use of the language appear to allow mutables. Stated more simply, In a concurrent world the only benefit of mutable values is the programmers ability to reason about them.