Yes, you can pretty easily beat the compiler in simple cases when you do this.
I would seriously challenge anyone to try to, by hand, do what PLUTO+ does .
http://dl.acm.org/citation.cfm?id=2688512
It is implemented in at least one real production C++ compiler. The analogue would be graphite in gcc, and polly in llvm, but they don't have the full cost modeling it does.
Then try to do it for multiple architectures or even different cache models (IE newer vs older processors).
Even simpler things than that, like deciding when it is profitable to add runtime vectorization/alignment checks, etc, is really hard by hand.
Hell, in larger functions, i doubt people can even optimally do register allocation (including live range splitting, remat, etc).
So yeah, stupid quicksort, sure, you can beat it.
I'm not sure what it's supposed to prove?
If you restrict yourselves to small cases that are easily optimizable without any thought, and not amenable to any even slightly advanced optimization, yes, you can beat the compiler.
I would seriously challenge anyone to try to, by hand, do what PLUTO+ does . http://dl.acm.org/citation.cfm?id=2688512 It is implemented in at least one real production C++ compiler. The analogue would be graphite in gcc, and polly in llvm, but they don't have the full cost modeling it does. Then try to do it for multiple architectures or even different cache models (IE newer vs older processors).
Even simpler things than that, like deciding when it is profitable to add runtime vectorization/alignment checks, etc, is really hard by hand. Hell, in larger functions, i doubt people can even optimally do register allocation (including live range splitting, remat, etc).
So yeah, stupid quicksort, sure, you can beat it.
I'm not sure what it's supposed to prove?
If you restrict yourselves to small cases that are easily optimizable without any thought, and not amenable to any even slightly advanced optimization, yes, you can beat the compiler.