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,2a34b7ad6c6a0774 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.nethere.com!news.nethere.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 14 Aug 2010 11:13:34 -0500 Newsgroups: comp.lang.ada Subject: Re: Efficiency of code generated by Ada compilers From: csampson@inetworld.net (Charles H. Sampson) Date: Sat, 14 Aug 2010 09:13:31 -0700 Message-ID: <1jn7hdz.1612v6172y0thN%csampson@inetworld.net> References: <1jn1a4o.1dfllwo1uin3imN%csampson@inetworld.net> <1jn36d6.se2f0g1edjjnyN%csampson@inetworld.net> <61f149b9-00ff-40cd-9698-01e69fdc5c0f@v15g2000yqe.googlegroups.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: MacSOUP/2.8.2 (Mac OS X version 10.4.11 (PPC)) X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-nkjDfcb+MDv22rSQmQIAq6BL+Oz02IsimygpWuk0Yg9rJXoeWra0jr7f0irYh5UhjAibBXVYZwQtFda!zB9YOdQAw9pUfvngbP0uoy0M4lXanE/sMDJKxRwRowdyrL40zdF3BFkaYoM9iQXre8rACLbnkf8J!RTTLdM+tmugng9GYZMGpBMmq43nG X-Complaints-To: abuse@nethere.com X-DMCA-Complaints-To: abuse@nethere.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Xref: g2news1.google.com comp.lang.ada:13288 Date: 2010-08-14T09:13:31-07:00 List-Id: Elias Salom�o Helou Neto wrote: > ... > > Well, we are definitely drifting away from the original question. So > much that I am considering to give up reading answers from this > post... > > Anyway, someone prematurely implied that I may be doing premature > optimization. The fact is that I do know, from profiling, how > important is _not_ to range check in my specific application, so I > will try to give you a "bottom line" of what have been said that > really matters to me. > > ... I think I'm the guy who implied that you're doing premature optimization, or at least the guy who you think implied that. You appear to have a deep knowledge of your application. I certainly don't. Therefore I have to defer to your judgement on the question. But I probably did raise the question that you _might be_ prematurely worrying about optimiziing. What I remember saying is that almost every time _I_ make a guess about optimization, I'm wrong. A number of people have given you information about optimization of a number of Ada compilers. I'll give you an example of the last one I worked with. This compiler uses a not uncommon approach to code generation. It initially generates pretty mediocre code, in particular code that contains a lot of unnecessary range checks and even unnecessary register loads. Then, if the user wants, it passes that code through a pretty good optimizer. You might say that the compiler has two modes, development and production. My last project was a real-time application. We hit all of our deadlines, which is all that counts in the real-time world. (We achieved this in the crudest way: We beat it about the head and shoulders with a very fast CPU and gobs of memory.) Nonetheless, twice during my time on the project, I compiled the whole application using the optimizer (but not with range checks, or any checks, explicitly suppressed). The generated code improved dramatically. Checks that the optimizer could verify weren't needed disappeared. Code motion did some pretty things. And so on. However, when I ran this much improved version, I couldn't see any difference between it and the crude version, including any increase in the amount of time the application was in its idle state. In short, whatever improvement there was in execution, wasn't worth the increase in compilation time. That's a pretty standard story, illustrating that you usally need to analyze before optimizing. However, as people love to say, YMMV. (That's twitter-speak for "This might not apply in your case.") Charlie -- All the world's a stage, and most of us are desperately unrehearsed. Sean O'Casey