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,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 10 Mar 2005 17:05:09 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada,comp.realtime,comp.software-eng References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <422ee0ce$0$1091$9b4e6d93@newsread2.arcor-online.net> <112v9p788s1684d@corp.supernews.com> Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Thu, 10 Mar 2005 17:07:20 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-tRPRf+6pwyxsE5zOrsnWmT0/uPd8hEXr+cwNZN/HSgmVvYX15tHQ+wla1qDVbvK/TKxbhj7bUdRS9GD!PnZEjMnnkujgswDt8TDfIC+WF4F/izdWCpbHqxLaTyF0B54sqgAEycWGZ//CNUp0/7OW2ltTrNxJ X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.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.32 Xref: g2news1.google.com comp.lang.ada:9073 comp.realtime:1223 comp.software-eng:4791 Date: 2005-03-10T17:07:20-06:00 List-Id: "CTips" wrote in message news:112v9p788s1684d@corp.supernews.com... ... > Don't have something specific to Ada, but I've seen work on PL.8, which > had similar dynamic bounds checking. They observed, *on the average* > about 8%, but this was on a machine with a special trap instruction for > bounds checking. It would be closer to 15-20% if the check had to be > done using subtract/compares/branches. The vast majority of dynamic checks are eliminated in modern Ada compilers. Our compiler provides an option to turn that checking off, in case something imported or uninitialized is causing problems, but it's hardly ever used. ... > There is a secondary, but fairly important affect. Compiler resources > are finite, and compilers also suffer from "bit-rot". Maybe if they're written in C. :-)_ We haven't observed this effect in our compiler (which is written in Ada, of course). > Roughly, you can > only cram in so much effort into a compiler before its run-time or > bug-rates or heuristic-balancing effort become unacceptable. I agree; which is one of the advantages of using Ada. You put that effort toward getting the design and features right, not into debugging. That's why OOP was such a big win for most people: they discovered the advantages of encapsulation (which of course Ada programmers had been using since the early 80s). > In the case of a feature rich language like Ada (or C++), much of the effort goes > into getting all the features right. In C, almost all the effort goes > into the optimizations. Even when people appear to use the same backend, > in practice, there are various optimizations which get disabled for > non-C languages because they break at various corner cases in other > languages. Well, that's certainly not been the case with our compiler, and I doubt it is with any commercial compiler: you have to be at least competitive or you won't have customers for long. Ada compiler vendors (including GNAT) put a lot of effort into runtime checking optimizations; the vast majority of checks are eliminated. And code can be written to move the ones that remain to places where they have little effect on performance -- by declaring objects with appropriate constraints, for instance. ... > > Given that the language provides > > pragma Optimize (Time/Space/Off) > > I doubt that this general doubt can be justified. > > and you are speaking from how many years of compiler development...? I won't speak for Georg, but I've been working on Ada compilers since 1980. So that would be about 24 years (although I should admit that I haven't done a lot of compiler development in the last 5 years or so, although I do continue to maintain Janus/Ada). In one sense, you are right, though. The Ada language provides a lot of information to the compiler that other languages don't have. That should allow Ada compiler optimizers to generate *better* code than C compiler optimizers, where that same information has to be inferred. But that hasn't been taken advantage of, possibly because of lack of resources, and probably because of concerns about breaking poorly written Ada 83 code. Randy Brukardt