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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7b73eb137e4ed638 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-20 16:35:54 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!west.cox.net!cox.net!newspeer1-gui.server.ntli.net!ntli.net!diablo.theplanet.net!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada Compilers Date: Mon, 20 May 2002 09:28:40 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CE2AF22.2060208@gmx.spam.egg.sausage.and.spam.net> <878z6kq4rr.fsf@deneb.enyo.de> <3CE58053.2020809@gmx.spam.egg.sausage.and.spam.net> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1021901321 11389 136.170.200.133 (20 May 2002 13:28:41 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 20 May 2002 13:28:41 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:24439 Date: 2002-05-20T13:28:41+00:00 List-Id: Well, from a purely *practical* standpoint (realizing that we are talking about existing implementations rather than either the language or any particular compiler) we might say this: Most popular Ada implementations are generating code that is pretty efficient in comparison to most other compiled languages. You won't discover that your basic workstation/PC application programmed in Ada is somehow bog-slow in comparison to the same thing in some other language typically used for the same application. Now a few caveats: If you truly have a time-critical application, you'd best conduct a timing study with algorithms typical of the application at hand. Compilers (even for the same language) can have a good deal of variance in terms of the code they generate for different operations. Be sure that when timing any Ada code, that you either *really* know what you're doing or that you are working with the vendor to get the best possible optimization. (Its easy to compile with all runtime checking in place and/or by using constructs unwisely and discovering you have pretty slow code. Quite often throwing a few compiler switches, or including a few pragmas or otherwise tweaking things a bit, you get really nice code. But you need to know...) There are some Ada implementations for some targets that are extremely highly optimizing and will do a wonderful job of producing highly efficient code. Remember that Ada was originally invented for embedded, real time apps, so it is possible to find very efficient compilers. However, that isn't saying there are highly efficient compilers for all platforms and targets. It also isn't saying that they will be efficient for the algorithms you intend to use. Compiler timing studies are *very* complex to get right. (I've been through a couple of serious ones) But its the only way to get any truly useful information. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "David Rasmussen" wrote in message news:3CE58053.2020809@gmx.spam.egg.sausage.and.spam.net... > > I know that, of course. My question was of a more pragmatic nature. Most > languages (ML, Lisp, Java etc.) could have compilers that created as > good code on a given platform (say x86), as the best C compilers for the > same platform. But in real life, this is not at all the case. So my > question was if, in practice, most Ada compilers generate code that is > comparable to, say, C++ compilers. The question makes a lot of pragmatic > sense. >