Re: naval systems

["Pat Rogers" <progers@classwide.com>]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a5hg80$8a22@news.cis.okstate.edu...
> On Tue, 26 Feb 2002 20:46:45 GMT, Pat Rogers <progers@classwide.com> 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.

I think that is a fair description, actually, although I can see you may not
have meant the earlier post the way I took it.

> > Did this Ada code and C
> > code do the same thing?
>
> Of course.
>
> >What switches did he use for both?
>
> None, for the tests.

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.

> > 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.

Precisely -- evidence that will stand up to scrutiny, however.

> 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!

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.

> 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.

That's exactly what I wanted you to do.  I wanted to hear the basis for your
assertion.

> I argue not that the speed matters, merely that there is a difference in
> speed.

And I'm trying to get to why you think that, above and beyond scant empirical --
and perhaps questionable -- data.  In particular, I want to know why **in terms
of the languages' definitions.**   What are the semantics that affect the
compiler itself, after the switches are set appropriately and the code is truely
comparable, such that, as you say, "there is a difference".  Otherwise we are
only comparing implementations and cannot generalize the result.

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.

> (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.)

Interesting.

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,
which is I hope an accurate interpretation of the prior posts, as illustrated by
the one above:   "> I argue not that the speed matters, merely that there is a
difference in speed."