On Sat, 19 Mar 2016 02:04:35 -0600
Scott Robison <scott at casaderobison.com> wrote:
> As he says, there's not real choice between fast and
> > correct
>
> Except that testing can verify something is correct for a given
> environment.
That's actually not true, on a couple of levels.
"[T]esting can be used very effectively to show the presence of
bugs but never to show their absence."
-- EWD303
I think that should be called Dijkstra's Dictum. It's not just quip;
it's a concise insight into limits of testing versus proving
correctness.
Second, you can't test the future. If the correctness of the code is
subject to change by the compiler's interpretation of the language, how
is the programmer to prevent it?
> > finally drive gcc & friends in the direction of working
> > with their users for a change. Or make them irrelevant.
>
> I think they'd continue to be popular with people looking to eek out
> as much performance as possible.
You may be right. As a consultant I've often felt I was hired to
sprinkle magic pixie performance dust on the system. People want to
believe that performance is found in tools. How come there's no -O5?
In truth, every performance problem I've encountered was a design
problem, often obvious, always unnecessary. "Use a better compiler"
has never been the solution. Unloading mounds of unnecessary
processing with a pitchfork is.
Doubtless there are some well tested, highly stable applications run at
scale, for which 5% is a measurable and meaningful gain. IMO they're
actually the ones driving UB treatment by compiler writers. The
other 99% stand to gain from a compiler that emphasizes correctness and
predictable behavior.
--jkl
