From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ec4f8ae8cbf8519f X-Google-Attributes: gid103376,public From: "W. Wesley Groleau (Wes)" Subject: Re: Ada vs. C: performance, size Date: 1997/01/09 Message-ID: <9701092035.AA15294@most>#1/1 X-Deja-AN: 208875251 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU mailer: Elm [revision: 70.85] newsgroups: comp.lang.ada Date: 1997-01-09T00:00:00+00:00 List-Id: > > I always figured it to turn off the optimizer for one out of a hundred > > files was a lot easier than some of the code contortions people would > > write for the sake of "hand-optimizing". > I find this difficult to understand. If you understand in detail all the bugs > in your compilation system and you have tools to inspect your source code so > that you can identify any files that might suffer from the bugs, then perhaps > I /would/ agree. My experience is different. Compiler bugs tend to be On a large project, I would hope that at least five percent of the people are familiar with compiler bugs. I would further hope that: 1. Every change of any significance has some sort of peer review, which could include watching for such things. 2. Every change of any significance has some sort of testing which could detect most of the bugs that escape the review. > pathelogical, otherwise they would have been found before and fixed (I'm an > optimist). Often they cause the code to behave oddly under obscure situations > which, sadly, don't always get tested. If an optimiser significantly > increases the incidence of latent bugs, that is bad news. If code is well-engineered, in terms of modularity, simplicity, etc. not only are there fewer "obscure situations" possible to slip by testing, but there are also fewer wierd coding techniques to confuse an optimizer. --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Hughes Defense Communications (MS 10-41) Home: 219-471-7206 Fort Wayne, IN 46808 (Unix): wwgrol@pseserv3.fw.hac.com ---------------------------------------------------------------------------