3 ms·

Huh, cool - I never really looked into what goes into doing compiler optimizations. What sort of gains would we be looking at with syntactic language differenc

by javanix 16y ago

Huh, cool - I never really looked into what goes into doing compiler optimizations. What sort of gains would we be looking at with syntactic language differences taken into account? For instance, suppose I wrote some program in C, compiled, and ran it with the latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down to bare bytecode with a comparably optimized compiler - no interpreter or JIT happenings - would there be a large number of optimizations that just couldn't happen for one language or the other?

silentbicycle 16y ago
You have to think about what invariants the compiler is capable of recognizing in your code, and can prove are valid: "If I guarantee X, it can do optimization Y behind the curtain, but will still run as if things were compiled normally." For example, if all variables are immutable by default, they can be inlined at point of use, skipping a lookup. Functions whose arguments are all known can potentially be run once at compile time (partial evaluation). Collections can potentially be handled in parallel if each cell's processing is independent. Etc. This sort of thing is why languages with strong invariants (such as Haskell or Erlang) can do really interesting optimizations. On the other hand, if the language semantics require that everything is polymorphic and has to be looked up at runtime, that adds extra overhead, and it's not always provable what those values will be at compile-time. A JIT-compiler can compile at runtime, when the information is available, but since they're usually not able to pause execution for long, they can't do extensive analysis. JIT compilers can also make optimizations not statically available because they can revert to the non JIT'd code and recompile differently, whereas static compilation is permanent. (Method lookups can also be cached, of course.) Incidentally, normal Lua (i.e., not LuaJIT)'s compiler doesn't do much analysis - it's tuned for vacuuming up huge dumps of structured data, rather than trying to generate optimal bytecode. Lua usually still runs significantly faster than Python or Javascript, but that has more to do with the the clean language semantics and high-quality implementation. Also, a good comment by Mike Pall (the LuaJIT implementer): http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0 http://www.reddit.com/r/programming/comments/badl2/luajit_2_...
dkersten 16y ago
Well, for one thing, Python guarantees that objects can be dynamically modified (methods can be rebound, new methods can be added, methods can be removed.. same goes for data members. Python can do this because the methods are stored in a dictionary which gets looked up by method name at runtime). This will never be as fast as a static function call in C or even an indirect vtable-based call (indirect pointer access vs hash table lookup). That is a single reason why Python can never be compiled to run as fast as C. I'm sure there are plenty of other features that help or hinder performance optimisations. Its all about tradeoffs. (Of course, a suficiently advanced language may allow you to choose these tradeoffs at a finer grain than the language level)

by javanix 16y ago

silentbicycle 16y ago

You have to think about what invariants the compiler is capable of recognizing in your code, and can prove are valid: "If I guarantee X, it can do optimization Y behind the curtain, but will still run as if things were compiled normally." For example, if all variables are immutable by default, they can be inlined at point of use, skipping a lookup. Functions whose arguments are all known can potentially be run once at compile time (partial evaluation). Collections can potentially be handled in parallel if each cell's processing is independent. Etc. This sort of thing is why languages with strong invariants (such as Haskell or Erlang) can do really interesting optimizations. On the other hand, if the language semantics require that everything is polymorphic and has to be looked up at runtime, that adds extra overhead, and it's not always provable what those values will be at compile-time. A JIT-compiler can compile at runtime, when the information is available, but since they're usually not able to pause execution for long, they can't do extensive analysis. JIT compilers can also make optimizations not statically available because they can revert to the non JIT'd code and recompile differently, whereas static compilation is permanent. (Method lookups can also be cached, of course.) Incidentally, normal Lua (i.e., not LuaJIT)'s compiler doesn't do much analysis - it's tuned for vacuuming up huge dumps of structured data, rather than trying to generate optimal bytecode. Lua usually still runs significantly faster than Python or Javascript, but that has more to do with the the clean language semantics and high-quality implementation. Also, a good comment by Mike Pall (the LuaJIT implementer): http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0 http://www.reddit.com/r/programming/comments/badl2/luajit_2_...

dkersten 16y ago

Well, for one thing, Python guarantees that objects can be dynamically modified (methods can be rebound, new methods can be added, methods can be removed.. same goes for data members. Python can do this because the methods are stored in a dictionary which gets looked up by method name at runtime). This will never be as fast as a static function call in C or even an indirect vtable-based call (indirect pointer access vs hash table lookup). That is a single reason why Python can never be compiled to run as fast as C. I'm sure there are plenty of other features that help or hinder performance optimisations. Its all about tradeoffs. (Of course, a suficiently advanced language may allow you to choose these tradeoffs at a finer grain than the language level)