Hacker News Reader

Comment by sgift | Hacker News Reader

Torvalds' argument makes for a nice quote but reality tells a different story: If people just wanted a reliable compiler they would use the oldest compiler they could find which is able to compile their code. If it is old all bugs, problems and faults are known. You know how to work around them and nothing can surprise you anymore. The performance may not be great, it may be a bit of a pain to do some things, but you know it all, so it is not great, but reliable.

What people really want is something which is reliable and smart and fast and .. people love smart compilers/programs/whatever, only when those programs fail them they cry "why did you try in the first place? No one wants this"

There's a thin line between smart and crazy. Trying to be always on the right side is one of the hardest parts of software design.

View on HN

I think that different elements of the language call for a different approach. I believe that everything related to mutable shared state calls for a very conservative compilation approach, because the potential benefits seem to me rather tiny while the potential drawbacks seem very large (since when it comes to race conditions, runtime testing is at its weakest when trying to find bugs in the code generated after a compiler upgrade.) To me it doesn't make sense economically. But this is not the case with a whole lot of other optimizations. I think that making this distinction is my modest attempt at being on the right side on this issue :-)

(So I agree that the original quote taken literally and out of the original context does become a nice talking point contradicted by reality; I think however that it's much more sensible in its original context - and the context of this discussion - this context being optimizing code working with mutable shared state.)

Of course, everyone wants the best of everything.

When someone says they prefer "reliable over smart," I assume that they mean they want as smart a compiler as possible under the constraint that it has to be reliable first.

And that's reasonable. Small (semantic) changes to code should result in small changes to performance.

I agree. Another proof is that the people like the -O3 optimization mode, when the -O0 optimization mode provides the same functionality with less compiling time (with the side effect of more run time).

I was under impression that, at least on gcc, everybody uses -O2 and -O3 is reserved for those who have the patience to verify that their software not only still works correctly, but even actually becomes faster.

FWIW, I once tried -O3 on some number crunching code few years ago and results were mixed. Improvements, if any, came from only one or few of the many -f flags enabled by -O3.

Oh, and I also tried -O3 on Gentoo. Some weird gtk crashes, had to rebuild back with -O2.

> If people just wanted a reliable compiler they would use the oldest compiler they could find which is able to compile their code.

True, but not really possible. For a while, the Linux Kernel keep some support to be compiled with older versions of GCC (2.95 IIRC) because it was faster

However you need modern compilers to be able to support things like: support for modern processors, support for intrinsics, etc

Reply on news.ycombinator.com