Hacker News Reader

Comment by vardump | Hacker News Reader

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.

View on HN

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.

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.

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.

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/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.

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.)

Reply on news.ycombinator.com