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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,539c04254abf1b37 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-26 20:22:25 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-03!supernews.com!logbridge.uoregon.edu!newsfeed.stanford.edu!headwall.stanford.edu!unlnews.unl.edu!newsfeed.ksu.edu!nntp.ksu.edu!news.okstate.edu!not-for-mail From: David Starner Newsgroups: comp.lang.ada Subject: Re: naval systems Date: 27 Feb 2002 02:28:16 GMT Organization: Oklahoma State University Message-ID: References: <3C74E519.3F5349C4@baesystems.com> <20020221205157.05542.00000012@mb-cm.news.cs.com> <3C763746.CC8B2965@baesystems.com> Reply-To: starner@okstate.edu NNTP-Posting-Host: x8b4e51a7.dhcp.okstate.edu User-Agent: slrn/0.9.7.3 (Linux) Xref: archiver1.google.com comp.lang.ada:20495 Date: 2002-02-27T02:28:16+00:00 List-Id: On Tue, 26 Feb 2002 20:46:45 GMT, Pat Rogers wrote: > Of course that is what I mean. Therefore, the stand-alone assertion that "GNAT > is noticably slower than gcc" is confusing. Does he mean that the front-end > for GNAT is slower than the front-end for C? I mean that compiling a program with gnat takes longer than a comparable program with the C compiler. Both in uncontrolled experiance and tests. > Does he mean that the end-to-end > performance of any Ada compiler is slower than any C compiler, as supported by a > comparison of supplying C code and Ada code to gcc? Of course not. That's absurd. Nice strawman, though. > Did this Ada code and C > code do the same thing? Of course. >What switches did he use for both? None, for the tests. > One can just as easily assert that -- with comparable (not identical) switches > and with the code doing the same thing -- most of the time there won't be a > significant difference in either compile-time or run-time. Pathological cases > in either direction can no doubt be constructed. So what? One can easily assert that. One can easily assert pretty much anything. But if it's to believed, it should be backed up by evidence or it's just noise. Given both the null program and Hello, World!, the C compiler took about 1/3 of the time that GNAT did, with no options and with -O2 -g. I generated a 32,002 line program that had 32,000 randomly pointing (but the same for the C and Ada program) goto statements in it, and told it to write to assembly only, with no optimization. The C compiler took 4 seconds. GNAT took 7 minutes to tell me I was missing a semicolon. After fixing that semicolon, it took 6 minutes 59 seconds to produce assembly with no significant difference. The last case is a bit pathological, but it is a data point. In all cases I tried the C compiler was significantly faster than GNAT. If you want to argue that there won't be a significant difference, please show test cases and numbers, instead of just making assertions. I argue not that the speed matters, merely that there is a difference in speed. (BTW: The example solution in Graphics was in C++, and I hand converted it to Ada. Compiling it with G++ took about 40% longer than with GNAT. I converted nested vector classes to arrays of pointers, though, which probably made a difference.) >> If one means gcc to mean the C/C++ compiler only, then of course it is not the >> same -- they compile different languages. > > Clearly. However, that is an obsolete definition, given that GCC is now the "GNU > Compiler Collection". Ah, but you're assuming that Unix acronyms are case-insensitive. They aren't - GCC is unambigiously the "GNU Compiler Collection", but gcc may be "GNU C Compiler", or the driver program that merely runs the compilers, or occasionally the same as GCC. -- David Starner - starner@okstate.edu What we've got is a blue-light special on truth. It's the hottest thing with the youth. -- Information Society, "Peace and Love, Inc."