4 ms·

Torvalds on memory ordering and clever compilers (http://yarchive.net/comp/linux/memory_barriers.html http://yarchive.net/comp/linux/memory_barriers.html): "Co

by yosefk 10y ago

Torvalds on memory ordering and clever compilers (http://yarchive.net/comp/linux/memory_barriers.html http://yarchive.net/comp/linux/memory_barriers.html): "Compiler people tend to think that people want smart compilers. I as a compiler power-user can emphatically tell you that that isn't true. People want _reliable_ compilers, and they want compilers that can be told to just get the hell out of the way when needed." I guess I'm largely at the same side of the argument, on the theory that atomics etc. should be used very sparingly by people who know what they're doing and spend time to hand-optimize their code and think it through semantically (and these people aren't helped by the semantics of atomics becoming more complicated for the sake of optimization opportunities), as opposed to other language mechanisms which are used all over the place by everyone, and so with these mechanisms you do gain a lot from clever optimizations. But I understand the other side of this argument...

sgift 10y ago
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.
- gus_massa 10y ago
  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).
  - qb45 10y ago
    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.
- mike_hock 10y ago
  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.
- raverbashing 10y ago
  > 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
- _yosefk 10y ago
  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.)
eternalban 10y ago
Linus was speaking in context of kernel development. See below and happy trails: https://lwn.net/Articles/586838/ https://lwn.net/Articles/586838/ https://lwn.net/Articles/586957/ https://lwn.net/Articles/586957/ [edit: meat here]
gpderetta 10y ago
Linus ideal memory model is 'DWIM'; to him it is obvious what the compiler should or shouldn't do. When people have asked him to write down exactly the rules he either refused or handwaved it. Unfortunately it is still pretty hard to write a compiler that would exactly replicate Linus thought processes and he also might not appreciate the brain dissection required to do so.
- jfbastien 10y ago
  Paul wrote a memory model for Linux, with input from the Linux community: http://wg21.link/p0124r1 http://wg21.link/p0124r1
  - gpderetta 10y ago
    Yes, and Paul 'RCU' McKenney actively engaged with the C++ committee during the standardization process, even writing multiple papers, contrary to Linus which assumed that nothing good would ever come from it.

by yosefk 10y ago

sgift 10y ago

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.

gus_massa 10y ago
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).
- qb45 10y ago
  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.
mike_hock 10y ago
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.
raverbashing 10y ago
> 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
_yosefk 10y ago
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.)

eternalban 10y ago

Linus was speaking in context of kernel development. See below and happy trails: https://lwn.net/Articles/586838/ https://lwn.net/Articles/586838/ https://lwn.net/Articles/586957/ https://lwn.net/Articles/586957/ [edit: meat here]

gpderetta 10y ago

Linus ideal memory model is 'DWIM'; to him it is obvious what the compiler should or shouldn't do. When people have asked him to write down exactly the rules he either refused or handwaved it. Unfortunately it is still pretty hard to write a compiler that would exactly replicate Linus thought processes and he also might not appreciate the brain dissection required to do so.

jfbastien 10y ago
Paul wrote a memory model for Linux, with input from the Linux community: http://wg21.link/p0124r1 http://wg21.link/p0124r1
- gpderetta 10y ago
  Yes, and Paul 'RCU' McKenney actively engaged with the C++ committee during the standardization process, even writing multiple papers, contrary to Linus which assumed that nothing good would ever come from it.