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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-11 04:51:04 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!elnk-pas-nf1!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!newsread3.news.atl.earthlink.net.POSTED!d9c68f36!not-for-mail Message-ID: <402A2529.7000808@noplace.com> From: Marin David Condic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (OEM-HPQ-PRS1C03) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) References: <20040206174017.7E84F4C4114@lovelace.ada-france.org> <54759e7e.0402071124.322ea376@posting.google.com> <2460735.u7KiuvdgQP@linux1.krischik.com> <54759e7e.0402081525.50c7adae@posting.google.com> <54759e7e.0402091826.2847e0c@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Feb 2004 12:51:03 GMT NNTP-Posting-Host: 209.165.23.177 X-Complaints-To: abuse@earthlink.net X-Trace: newsread3.news.atl.earthlink.net 1076503863 209.165.23.177 (Wed, 11 Feb 2004 04:51:03 PST) NNTP-Posting-Date: Wed, 11 Feb 2004 04:51:03 PST Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: archiver1.google.com comp.lang.ada:5431 Date: 2004-02-11T12:51:03+00:00 List-Id: Jerry Coffin wrote: > > I've looked. It's usually not. For real-time systems, the primary > requirement is usually for absolute predictability, NOT for maximum > performance. > Speaking as one who does this daily in Ada, I'd take minor exception. Yes, *predictability* is essential and that's more an algorithmic issue rather than a language issue. However, don't believe for a moment that we don't sweat bullets over *speed* as well. When you have things that *must* finish in a millisecond and leave something to spare you worry about compiler efficiency quite a lot. Embedded, avionics quality compilers are typically stressing efficiency over other attributes (like related support tools). I've used and do use Ada compilers that are as good or better than those for other languages. > > The last time I checked, GNAT uses the same back-end as the other GNU > compilers, so if it doesn't produce as good of code, it's a strong > indication of a performance problem in the language proper. > Having used Gnat quite a bit, I'd like to know what you think it does that is slow. I'd be interested in some benchmark code that Gnat does inefficiently in comparison to similar code in C passed through gcc. Given that I regularly use high quality Ada compilers for hard realtime work and have been more than satisfied with the resultant efficiency of the code, I'd have to say that your "strong indication of a performance problem in the language proper" is essentially disproven by example. Its an old cannard that gets regularly dragged out because people have this tendancy to believe unicorn stories. "My brother knows this guy who had a friend wo worked with this guy who used to use Ada 20 years ago and he said that Ada is slow, so it *must* be true..." > > Though I don't work with as many Ada programmers on as regular a basis, > it appears to me that many do more or less the opposite: it's so widely > assumed that the compiler will catch almost all errors, that many > blithely assume that almost anything that compiles MUST be correct. At I work with lots of Ada programmers in a place where failure is not an option. We *never* blithely assume that if it compiles, its correct. We spend lots of time and money testing. However, in studies I've done of errors in Ada code versus that in other languages, you typically get a) fewer of them and b) of a different class. We used to get all sorts of errors relating to scalings on numeric values and similar sorts of problems that relate closely to type checking. Now, those errors all but disappear. We still have errors - but they tend to be more along the lines of *logic* errors. No language can save you from that. The net result is that we save lots of money in not having to rework code and regression test it all because of relatively small problems that the compiler can catch for us. Everyone who studies "process" knows that the sooner you catch a problem in the production chain, the cheaper it is to fix. > the same time, execution speed has been perceived as a problem often > enough that many knowingly and intentionally subvert type-checking and > such, on the assumption that it's necessary to get the speed they think > they need to be competitive. > There's no way that runtime checks aren't going to cost *something*. However, in most apps, the cost isn't so high as to be prohibitive. When I build PC based apps in Ada, all the checks are left on and though there must be a performance hit in there somewhere, its really hard to see these days given the speed of your garden variety microprocessor. For 90% of apps it should fall below the noise floor and not matter. For the relatively *small* number of apps (and usually only in some critical places within those apps) that have a performance issue, sure - go ahead and turn off checks. You still get the static checks and that covers a lot of ground. It seems to be a non-issue to me. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/NSFrames.htm Send Replies To: m o d c @ a m o g c n i c . r "Face it ladies, its not the dress that makes you look fat. Its the FAT that makes you look fat." -- Al Bundy ======================================================================