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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,acba876b1e3c9639 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!proxad.net!usenet-fr.net!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT Optimization of Constant Expressions Date: Thu, 17 May 2007 18:38:34 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1179355028.624745.258370@q75g2000hsh.googlegroups.com> <464cb4cd$1_3@news.bluewin.ch> <1179442153.169828.109970@l77g2000hsb.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1179444993 21381 69.95.181.76 (17 May 2007 23:36:33 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 17 May 2007 23:36:33 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:15824 Date: 2007-05-17T18:38:34-05:00 List-Id: "David Smith" wrote in message news:1179442153.169828.109970@l77g2000hsb.googlegroups.com... > > > > I agree for any function call, but in the special case of functions from > > > Generic_Elementary_Functions, it is _not_ asking a lot! A decent compiler > > > should perform optimizations around these functions as well as around > > > arithmetic operators. > > The purpose in leaving them in was to test this aspect of the > optimization process. This is a very common expression to see in > legacy scientific codes written by novices, and I wanted to know if > GNAT can handle naive structures as well as Fortran compilers do. If > it can't, then many scientists and potential Ada converts will be > turned off because they'll write a naive bit of code for a benchmark > and find that Ada is much slower than Fortran without trying to > understand why. Fair enough, but this seems to be the wrong question to ask. The question is whether it is fast enough for the application, not whether it is as fast as some other language that doesn't have the same requirements. Anything else is premature optimization. And, in addition, can the code be made fast if it actually matters. (I have serious doubts about the value of "naive" numerical code, but I'll leave that rant for some other time...) > I understand that the FP ops are not associative, but doesn't the gcc - > O3 imply that the user chooses speed over accuracy? And especially if > the user passes -ffast-math the compiler should get the hint. I don't agree. Ada has fairly strict requirements on accuracy that C and Fortran don't have. An optimizer shouldn't be providing the *wrong* answer in order to make code fast; so I doubt that -O3 would have that effect on an Ada program (where it might for C).. I realize that Ada 95 made those accuracy requirements optional, but I think that most Ada compilers (which have Ada 83 roots) make the strict mode their default. And since the strict mode necessarily encorporates any relaxed mode, it's quite likely that they never deviate from it. I don't know Gnat well enough to comment on whether it has a separate relaxed mode. > > There are optimizations that you can do safely, like common subexpression > > evaluation, but there are many fewer of them than you have with integer > > optimizations. Luckily, most of the code in a program (any program, once you > > take address calculations like array indexing into account) is integer code. > > It is very important to do a good job on integer expressions, much less > > valuable of float ones (because of the limited things that you can do). > > This may be true, but FP ops are very expensive, so trimming those can > potentially save more than you might think. In this example, the > common expression elimination speeds the code up by a factor of 10, > roughly. No, FP isn't very expensive. "Elementary function" library calls that may execute hundreds of lines of code are expensive! (Keep in mind that Ada's accuracy rules prevent Ada compilers from using the hardware support for Sin/Cos/Tan -- it's not accurate enough.) You can write a lot of interesting FP code (statistics, for instance) without using any elementary functions other than Sqrt. And the use of constants as arguments to those expensive routines is pretty silly. (Besides, good Ada practice would be to name your constants, and when you did that, you got essentially the same code as with Fortran.) None of which is to say that common subs shouldn't be handled, but there is a big difference between hoisting expressions and simply avoiding duplicate evaluations. The former can make code larger and slower if done inappropriately. It may simply not be worth doing, if it doesn't help most programs. Of course, you can always write a program that it does help (like yours), but one has to allocate ones resources based on the value to all customers and all programs, not just one. (And please remember I know nothing at all about Gnat's actual optimization technology. This might just be a bug in something that is supposed to work.) Randy.