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-28 20:37:41 PST Path: archiver1.google.com!news1.google.com!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: 1 Mar 2002 02:59:36 GMT Organization: Oklahoma State University Message-ID: References: <3C74E519.3F5349C4@baesystems.com> <20020221205157.05542.00000012@mb-cm.news.cs.com> <3C763746.CC8B2965@baesystems.com> <4rcf8.1777$I33.586791085@newssvr12.news.prodigy.com> Reply-To: starner@okstate.edu NNTP-Posting-Host: x8b4e51cf.dhcp.okstate.edu User-Agent: slrn/0.9.7.3 (Linux) Xref: archiver1.google.com comp.lang.ada:20626 Date: 2002-03-01T02:59:36+00:00 List-Id: On Wed, 27 Feb 2002 21:44:32 GMT, Pat Rogers wrote: > Ah, this is what I'm trying to get to. Taking the defaults for the two > compilers/languages is *not* comparable. You need to at least turn of run-time > checking for the Ada program. That's enough to invalidate the test by itself. > >> 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. > > That isn't as meaningful as one might think, although it is not an uncommon > test. I assume you used Text_IO? The compile times were hugely overshadowed by > handling of the I/O libraries. That is not a comparable program to one in C > that uses the much simpler I/O library. > >> 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. > > So pathological, in fact, that I don't believe they were the "same" program. > I'm surprised anyone would! You mean, besides the fact that GNAT and GNU C produced the exact same assembly, except for four instructions (apparently GNU C felt the need to align the stack, where GNAT didn't). You mean besides the fact the fact the two programs have the exact same semantics - emit no output and never exit except on a signal. > It is extremely easy to get this kind of thing wrong -- thinking that the > semantics are the same when they aren't. I've done it before and no doubt will > do it again. It is trivially easy to drive an Ada compiler to its knees -- over > a period of several grinding minutes in some compilers -- by declaring a series > of named numbers that look like regular old C constants. All nice advocate answers. Now back to real life, if I write several programs simple enough that the semantics are exactly the same for each language, and each one is slower to compile with GNAT than GNU C, then I will come to the conclusion that GNAT is slower than GNU C. You seem to be interested in some idealized "fair" compairson. But that's not what matters - what matters is how long it takes on real life programs. > Otherwise we are > only comparing implementations and cannot generalize the result. Um, of course we can generalize the result. That's science - you take sample data points and see if you can draw a conclusion. How an idealized optimal Ada compiler performs is of little interest; how the Ada compiler that's on their desk or will be on their desk performs is of interest. > Again, we are talking about compile time, not the time it takes to build the > executable, because indeed the Ada binder/linker implements requirements that > the C tools do not bother with, like interface consistency. And again, we are > talking about compiling the same way -- with the switches set so that the > compilers behave comparably. Turning of the checking is the obvious example. You keep trying to add a handicap. The interesting question is time from submitting the sources to getting a binary; any features is a whole different question. What switches should be added is a complex question, but the answer should have to do with what will be normally used, and not what would make it more theoratically "fair". > At the end of the day, we are in agreement that in practice the time it takes to > produce an executable image from an Ada toolchain is typically slightly longer. > What we're arguing is whether the compilation phase itself is inherently slower, What does "inherently slower" mean? If you go back to the original post to which I responded, he was talking about most implementations being as fast as most C implementations; that was what I was responding to; I never said anything about all Ada implementations being inherently slower. -- 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."