4 ms·

> Programming languages aren't slower or faster. The implementations of them are. This is not true. Different languages provide different guarantees, which al

> Programming languages aren't slower or faster. The implementations of them are. This is not true. Different languages provide different guarantees, which allow implementations to safely make different optimisations. For a trivial example, c99 is a faster language than c89, because the 'restrict' keyword was added.

mrob 11y ago
The argument is that the mythical "sufficiently smart compiler" will figure out where restrict can be used automatically. In practice "sufficiently smart" means "at least as smart as a human", in which case pointer aliasing is the least of your concerns.
vardump 11y ago
No. The 'restrict' keyword makes it just easier to write a compiler that can properly optimize pointer access. In other words: the compiler can be less sophisticated: it doesn't need to globally prove how a pointer is used. When it sees 'restrict', it can simply take shortcuts and assume no aliasing possible and no pointer tricks are used. Can you add the keyword in appropriate places based on a set of rules when to use 'restrict' keyword? Yes? Then a hypothetical compiler could follow the same rules and get to same conclusions.
- shiro 11y ago
  In theoretical extreme, you're correct. Even with a dynamically typed language like Scheme, if you do the whole program analysis you can eliminate most of run-time type checking, boxing/unboxing and some transient allocations (e.g. Stalin). The problem is that the cost of whole program analysis is superlinear and it'll doomed to be impractical as the size of program grows, imho.
  - altarius 11y ago
    Even whole program analyzing compilers can't necessarily outperform a well-tuned regular compiler, see e.g. MLTon vs OCaml in this (micro-) benchmark. The OCaml compiler is just well-written and well-tuned and performs surprisingly well. http://www.ffconsultancy.com/languages/ray_tracer/performance.html http://www.ffconsultancy.com/languages/ray_tracer/performanc... But then as always, this benchmark may just test an implementation detail (afair OCaml is unboxing floats or float arrays (?) or maybe some of the MLTon standard lib is really slow). I seem to remember other benchmarks mirroring these results though.
    - shiro 11y ago
      Interesting report. Thanks. Does MLTon recompile including standard lib? (Stalin does---it recompiles and inlines all std lib functions used from the program every time, which is why it takes so long to compile.)
- AlisdairO 11y ago
  Even if we ignore the massive complexity problems with whole-program analysis, what if you can't globally prove how the pointer is used? Pointer arithmetic can be done based on runtime information. A compiler doesn't have access to knowledge like 'this system will never encounter data that causes those pointers to alias'. If you add a system to provide information like that, well, you're pretty much defining a language extension right there. Now, obviously you'd hope that people aim not to write programs that rely so subtly hopes and dreams of runtime information, but hopefully it's illustrative as a counterexample.
  - cactusface 11y ago
    Also consider that fixed point optimization algorithms can only ever approach the optimal solution. Languages that are closer to the hardware generally have simpler (tighter) optimization constraints, and compilers for them will generally get closer to the optimal solution.

mrob 11y ago

The argument is that the mythical "sufficiently smart compiler" will figure out where restrict can be used automatically. In practice "sufficiently smart" means "at least as smart as a human", in which case pointer aliasing is the least of your concerns.

vardump 11y ago

No. The 'restrict' keyword makes it just easier to write a compiler that can properly optimize pointer access. In other words: the compiler can be less sophisticated: it doesn't need to globally prove how a pointer is used. When it sees 'restrict', it can simply take shortcuts and assume no aliasing possible and no pointer tricks are used. Can you add the keyword in appropriate places based on a set of rules when to use 'restrict' keyword? Yes? Then a hypothetical compiler could follow the same rules and get to same conclusions.

shiro 11y ago
In theoretical extreme, you're correct. Even with a dynamically typed language like Scheme, if you do the whole program analysis you can eliminate most of run-time type checking, boxing/unboxing and some transient allocations (e.g. Stalin). The problem is that the cost of whole program analysis is superlinear and it'll doomed to be impractical as the size of program grows, imho.
- altarius 11y ago
  Even whole program analyzing compilers can't necessarily outperform a well-tuned regular compiler, see e.g. MLTon vs OCaml in this (micro-) benchmark. The OCaml compiler is just well-written and well-tuned and performs surprisingly well. http://www.ffconsultancy.com/languages/ray_tracer/performance.html http://www.ffconsultancy.com/languages/ray_tracer/performanc... But then as always, this benchmark may just test an implementation detail (afair OCaml is unboxing floats or float arrays (?) or maybe some of the MLTon standard lib is really slow). I seem to remember other benchmarks mirroring these results though.
  - shiro 11y ago
    Interesting report. Thanks. Does MLTon recompile including standard lib? (Stalin does---it recompiles and inlines all std lib functions used from the program every time, which is why it takes so long to compile.)
AlisdairO 11y ago
Even if we ignore the massive complexity problems with whole-program analysis, what if you can't globally prove how the pointer is used? Pointer arithmetic can be done based on runtime information. A compiler doesn't have access to knowledge like 'this system will never encounter data that causes those pointers to alias'. If you add a system to provide information like that, well, you're pretty much defining a language extension right there. Now, obviously you'd hope that people aim not to write programs that rely so subtly hopes and dreams of runtime information, but hopefully it's illustrative as a counterexample.
- cactusface 11y ago
  Also consider that fixed point optimization algorithms can only ever approach the optimal solution. Languages that are closer to the hardware generally have simpler (tighter) optimization constraints, and compilers for them will generally get closer to the optimal solution.