Re: naval systems

Re: naval systems

[David Gillon]

Andrew Swallow wrote:

> ADA, officially, did not have any Input/Output statements. 

So Chapter 14, Input-Output, of Mil-Std 1815A is a figment of my
imagination?

> ADA compilers were very large, which made them very slow.  

Early Ada compilers, maybe (a lot depended on how good a job you did of
designing your code). Later ones, definitely not.

>  The runtime support code
> needed more memory than most embedded computers had. 

Only if you didn't tailor it. And how has the embedded market reacted to
this supposed limitation? Gone all out for run-time operating
systems.....

> ADA is only used where cost and time scales are
> unimportant - such as cost plus contracts.

Nonsense. Boeing _chose_ to use Ada for it's development of the 777,
which had extremely tight schedules and where contracts were
risk-sharing, not cost-plus. The FAA couldn't have cared less what
language they used, so they gained nothing there, but Boeing saw enough
gains in the language to pursue it for its own sake. 

> ADA is a bureaucrat, the only things that ADA does not double
> check are those it triple checks. 

Pragma Suppress etc..... Ada checking is configurable and quite capable
of being turned off entirely.

> Hence, ADA is unsafe in any application that requires fast reaction
> times like missile guidance systems, airborne radars or nuclear
> reactor shut down systems.

This would be why it is the language of choice for nuclear reactor
safety systems and fly by wire, then? Ada is quite capable of generating
precisely the same machine code as C for the identical task, so
statements it is inherently slow fly in the face of reality. What it is
is markedly more maintainable and inherently safer to code.

-- 

David Gillon

Re: naval systems

[Marin David Condic]

"David Gillon" <david.gillon@baesystems.com> wrote in message
news:3C763746.CC8B2965@baesystems.com...
>
>
> Andrew Swallow wrote:
>
>
> > ADA compilers were very large, which made them very slow.
>
> Early Ada compilers, maybe (a lot depended on how good a job you did of
> designing your code). Later ones, definitely not.
>
Try one today. Most are as good or better than C compilers. Both in terms of
how fast they can compile code and how fast the code is that they compile.
This accusation may have at one time been true, but it is very, very, very
badly outdated.


> >  The runtime support code
> > needed more memory than most embedded computers had.
>
> Only if you didn't tailor it. And how has the embedded market reacted to
> this supposed limitation? Gone all out for run-time operating
> systems.....
>
Good point. I've built embedded systems with Ada that had nice, small RTKs
that could be cut down to just what you needed and no more. For very tiny
computers, you probably couldn't get the whole of Ada into them, but if you
made intelligent choices about what you needed, you could get all the way
down to *NO* RTK if necessary.

And compare that to the massive use of "Real Time" Linux systems for
embedded computers that are all the rage. Its a heck of a lot bigger and not
deterministic to boot. In many apps, it would be much more efficient to use
Ada with an appropriate RTK and maybe some I/O libraries than to try to
write C/C++ code running on top of Linux or other popular RTOS's.


> > ADA is only used where cost and time scales are
> > unimportant - such as cost plus contracts.
>
> Nonsense. Boeing _chose_ to use Ada for it's development of the 777,
> which had extremely tight schedules and where contracts were
> risk-sharing, not cost-plus. The FAA couldn't have cared less what
> language they used, so they gained nothing there, but Boeing saw enough
> gains in the language to pursue it for its own sake.
>
Absolutely. When I used to work at Pratt & Whitney, we used Ada to develop
real time engine controls - a *very* demanding application for real time
performance & reliability. We used Ada on the military side of the shop and
got to the point where we had metrics demonstrating that we doubled
productivity and cut defects by a factor of four. The evidence was so
indisputable that the commercial side of the shop adopted Ada and our
software development processes. They would not have done that if we didn't
*demonstrate* that we had cut costs, reduced defects and met schedules.

> > ADA is a bureaucrat, the only things that ADA does not double
> > check are those it triple checks.
>
> Pragma Suppress etc..... Ada checking is configurable and quite capable
> of being turned off entirely.
>
Checking things is a *bad* thing? Software should blithely run off into
illegal memory references, illegal instructions, overflows, etc? I suppose
we should all devoutly desire to never check anything - and while we're at
it throw away all those useless spelling and grammar checkers we attach to
word processors?

As you observe, the checks can - and frequently are- turned off whenever the
performance gets critical. Most of the time, they don't need to be disabled
and they help catch problems before things get fielded. Its often good to
leave the checks in on speed/size critical apps for initial testing and then
take it out once you've caught the problems.


> > Hence, ADA is unsafe in any application that requires fast reaction
> > times like missile guidance systems, airborne radars or nuclear
> > reactor shut down systems.
>
> This would be why it is the language of choice for nuclear reactor
> safety systems and fly by wire, then? Ada is quite capable of generating
> precisely the same machine code as C for the identical task, so
> statements it is inherently slow fly in the face of reality. What it is
> is markedly more maintainable and inherently safer to code.
>
I built a rocket engine control using a Mil-Std-1750a processor that was
slower than molassas in January. I had 64kwords of memory in which to work.
I had a 1.024mSec interrupt driving the whole thing with 5mSec, 10mSec and
20mSec outer loops. Failure was absolutely not an option. Not with a billion
dollar payload. Missed deadlines would be fatal. The delivery schedule was
extremely compressed. We did this control in Ada (With Tasking!!!) and it
performed flawlessly. The word "Flawlessly" was not applied just by me - but
by our customers.

The only reason Ada isn't used more in important, safety critical, high
performance real time and embedded systems is because there are too many
people out there who firmly believe with every fibre of their existence all
of the misinformation, rumor, hearsay, fabrication, slander, fear,
uncertainty and doubt that gets circulated about it. It pays to look at the
facts. It pays to investigate and experiment with Ada - and I mean it *pays*
in the pocketbook. Ada is a technology that when applied properly will
result in faster development time, lower costs, fewer defects and higher
customer satisfaction. It can't cure all your problems - no technology can.
But it *can* do a better job when you understand it and use it properly. It
*won't* do a better job for you if you approach it from a negative attitude
believing it must fail because that's all you've ever been told.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: naval systems

[David Starner]

On Fri, 22 Feb 2002 09:55:35 -0500, Marin David Condic wrote:
> Try one today. Most are as good or better than C compilers. Both in terms of
> how fast they can compile code and how fast the code is that they compile.
> This accusation may have at one time been true, but it is very, very, very
> badly outdated.

Really? At least in a comparison between GNAT and gcc on similar, small
pieces of code (< 2000 lines), I've found gcc to be virtually
instanteous, whereas GNAT took a number of seconds to process the code.

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

Re: naval systems

[martin.m.dowie]

> Something over ten years ago, I took an Ada training class at Texas
> Instruments.  (It was really a review for me, but I needed the review.)
One
> of the features of the class was a videotape of a Q&A session with Jean
> Ichbiah and two other Ada luminaries.
>
> Ichbiah was asked that precise question, about the size of the runtime,
and
> how it seemed that it would be too big for anything practical.
>
> His answer was that a just-about-fully-compliant Ada runtime module had
been
> written in 4K words.  Note well his choice of words:  not "could be" but
> "HAD BEEN" (emphasis added).
>
> Not long after that, I had occasion to check that answer, for the Tartan
> Labs toolset for the TI 320C30 32-bit floating point digital signal
> processor.  The Ada runtime module for that processor was, indeed, about
4K
> words.  This rather shocked my supervisor at the time; he'd just assumed
it
> would be prohibitively big and NEVER LOOKED.
>
> I don't know very many embedded systems that can't scratch up 4K words of
> code space for a runtime kernel.

From what I can gather this is the same size a non-tasking Ravenscar-profile
RTK - for tasking add another 9 or 10K, but still not exactly huge is it?

Re: naval systems

[John R. Strohm]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:a55m56$6mk$1@nh.pace.co.uk...
> "David Gillon" <david.gillon@baesystems.com> wrote in message
> news:3C763746.CC8B2965@baesystems.com...
> >
> >
> > Andrew Swallow wrote:
> > >  The runtime support code
> > > needed more memory than most embedded computers had.
> >
> > Only if you didn't tailor it. And how has the embedded market reacted to
> > this supposed limitation? Gone all out for run-time operating
> > systems.....
> >
> Good point. I've built embedded systems with Ada that had nice, small RTKs
> that could be cut down to just what you needed and no more. For very tiny
> computers, you probably couldn't get the whole of Ada into them, but if
you
> made intelligent choices about what you needed, you could get all the way
> down to *NO* RTK if necessary.

Something over ten years ago, I took an Ada training class at Texas
Instruments.  (It was really a review for me, but I needed the review.)  One
of the features of the class was a videotape of a Q&A session with Jean
Ichbiah and two other Ada luminaries.

Ichbiah was asked that precise question, about the size of the runtime, and
how it seemed that it would be too big for anything practical.

His answer was that a just-about-fully-compliant Ada runtime module had been
written in 4K words.  Note well his choice of words:  not "could be" but
"HAD BEEN" (emphasis added).

Not long after that, I had occasion to check that answer, for the Tartan
Labs toolset for the TI 320C30 32-bit floating point digital signal
processor.  The Ada runtime module for that processor was, indeed, about 4K
words.  This rather shocked my supervisor at the time; he'd just assumed it
would be prohibitively big and NEVER LOOKED.

I don't know very many embedded systems that can't scratch up 4K words of
code space for a runtime kernel.

Re: naval systems

[Marin David Condic]

In the days when the first validated Ada compiler was running at speeds that
compiled code in the single-digits-of-lines-per-second, you might make
compilation speed an issue. But if you're looking at one compiler that takes
a half a second and another that takes two seconds for a similar program, is
that really something that anyone wants to care about?

Besides, I'd suggest that in real applications that typically involve
hundereds of source files, Ada is likely to *buy* you time over something
like C because it can tell what needs to be recompiled and what doesn't. It
works faster by not working at all. :-)

In general, I just don't see compilation speed as a big deal these days and
Ada is competitively fast when compared to C. More important is the quality
of the resultant code (and even this is not a big deal in most applications)
and there I think Ada does as well or better than C in producing highly
efficient code. Or at least it can - compiler implementations do vary. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a57ar5$aai1@news.cis.okstate.edu...
>
> Really? At least in a comparison between GNAT and gcc on similar, small
> pieces of code (< 2000 lines), I've found gcc to be virtually
> instanteous, whereas GNAT took a number of seconds to process the code.
>

Re: naval systems

[Marin David Condic]

And, typically, you can pare it down as needed. If you've got a really small
box and don't need tasking & want to stick to some subset of the language in
your coding practices, you can get the runtime down to nothing at all.

Of course, one then needs to be careful that after having removed many of
the language's services that one doesn't just turn around and reproduce them
in some other way in the code. I've seen this done often - especially with
respect to tasking. Someone will get rid of tasking because its "too
inefficient" then just inefficiently juggle code all over the place to fill
up idle time or reinvent tasking in some other form.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"John R. Strohm" <strohm@airmail.net> wrote in message
news:CB534AA00A46FA5E.AAAB490398694730.BDDDDEA65B01C997@lp.airnews.net...
>
> I don't know very many embedded systems that can't scratch up 4K words of
> code space for a runtime kernel.
>
>
>

Re: naval systems

[Larry Kilgallen]

In article <a5djrr$m65$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> Besides, I'd suggest that in real applications that typically involve
> hundereds of source files, Ada is likely to *buy* you time over something
> like C because it can tell what needs to be recompiled and what doesn't. It
> works faster by not working at all. :-)

C compilers do this in conjunction with external tools.

On VMS the CC command qualifier /MMS_DEPENDENCIES creates (in addition
to any output specified by other qualifiers) an MMS description file
suitable for describing the conditions under which this file should
be compiled again (based on modification dates of included files as
well as the mail file).

C compilers are likely not so equal to each other as Ada compilers
in this regard, but I think that at decision-points regarding ease
of use, comparisons will be made between a particular Ada compiler
and a particular C compiler, rather than the field in general.

Re: naval systems

[David Starner]

On Mon, 25 Feb 2002 10:05:30 -0500, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> Besides, I'd suggest that in real applications that typically involve
> hundereds of source files, Ada is likely to *buy* you time over something
> like C because it can tell what needs to be recompiled and what doesn't. It
> works faster by not working at all. :-)

I don't think it makes much difference when comparing make-driven C code
base and gnatmake-driven Ada. You should get the same results either
way, except the first is much more work and much more powerful - any
sufficently large project will need a makefile, to build docs if for
nothing else.
 
> In general, I just don't see compilation speed as a big deal these days and
> Ada is competitively fast when compared to C.i 

But GNAT is noticably slower than gcc, and you can't claim that Ada
compilers are as fast as C compilers, and then argue that it doesn't
matter when someone pushes the point. Be honest; point out that Ada
compilers are fast enough, instead.

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

Re: naval systems

[Pat Rogers]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a5ghiq$9281@news.cis.okstate.edu...
> On Mon, 25 Feb 2002 10:05:30 -0500, Marin David Condic
<dont.bother.mcondic.auntie.spam@[> wrote:
<snip>
> > In general, I just don't see compilation speed as a big deal these days and
> > Ada is competitively fast when compared to C.
>
> But GNAT is noticably slower than gcc, and you can't claim that Ada
> compilers are as fast as C compilers, and then argue that it doesn't
> matter when someone pushes the point. Be honest; point out that Ada
> compilers are fast enough, instead.

I don't understand this.  GNAT *is* gcc.

Re: naval systems

[Ray Blaak]

"Pat Rogers" <progers@classwide.com> writes:
> "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> news:a5ghiq$9281@news.cis.okstate.edu...
> > But GNAT is noticably slower than gcc, and you can't claim that Ada
> > compilers are as fast as C compilers, and then argue that it doesn't
> > matter when someone pushes the point. Be honest; point out that Ada
> > compilers are fast enough, instead.
> 
> I don't understand this.  GNAT *is* gcc.

Well no. The machinery that reads in Ada sources and performs the static
analysis is (often) included in the gcc suite and invokes the common gcc code
generation abilities.

It is not gcc itself, it is GNAT.

If one means gcc to mean the suite of language specific compilers using a
common code generation backend, then GNAT is a part of gcc.

If one means gcc to mean the C/C++ compiler only, then of course it is not the
same -- they compile different languages.

At any rate, it should come as no surprise that an Ada compiler is slower than
a C compiler -- an Ada compiler is doing far more work, plain and simple.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: naval systems

[Pat Rogers]

"Ray Blaak" <blaak@telus.net> wrote in message news:u3czoxbjm.fsf@telus.net...
> "Pat Rogers" <progers@classwide.com> writes:
> > "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> > news:a5ghiq$9281@news.cis.okstate.edu...
> > > But GNAT is noticably slower than gcc, and you can't claim that Ada
> > > compilers are as fast as C compilers, and then argue that it doesn't
> > > matter when someone pushes the point. Be honest; point out that Ada
> > > compilers are fast enough, instead.
> >
> > I don't understand this.  GNAT *is* gcc.
>
> Well no. The machinery that reads in Ada sources and performs the static
> analysis is (often) included in the gcc suite and invokes the common gcc code
> generation abilities.
>
> It is not gcc itself, it is GNAT.
>
> If one means gcc to mean the suite of language specific compilers using a
> common code generation backend, then GNAT is a part of gcc.

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?  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?  Did this Ada code and C
code do the same thing?  What switches did he use for both?

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?

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

Re: naval systems

[Pascal Obry]

Ray Blaak <blaak@telus.net> writes:

> If one means gcc to mean the suite of language specific compilers using a
> common code generation backend, then GNAT is a part of gcc.

GCC means "GNU Compiler Collection" now, the C compiler is GNU/C the Ada
compiler is GNU/Ada (aka GNAT).

> If one means gcc to mean the C/C++ compiler only, then of course it is not
> the same -- they compile different languages.

GCC should not be used for GNU/C compiler these days.

> At any rate, it should come as no surprise that an Ada compiler is slower
> than a C compiler -- an Ada compiler is doing far more work, plain and
> simple.

Indeed. I see nothing really surprising. Marin point was just that with today
computer speed (we all have a mainframe on our desk these days) it is not an
issue as important as 20 years ago.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: naval systems

[Ray Blaak]

"Pat Rogers" <progers@classwide.com> writes:
> "Ray Blaak" <blaak@telus.net> wrote in message news:u3czoxbjm.fsf@telus.net...
> > If one means gcc to mean the suite of language specific compilers using a
> > common code generation backend, then GNAT is a part of gcc.
> 
> 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? 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?  Did this
> Ada code and C code do the same thing?  What switches did he use for both?

Hmm. I am not sure what was meant by the other poster, but my observation is
that an Ada compiler would be inherently slower, almost by definition, since
it does fundamentally more work than a C compiler. Even given similar source
inputs and compiler settings, there will be more verification happening for
the Ada source, and that extra work has a time cost.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@telus.net                                The Rhythm has my soul.

Re: naval systems

[Pat Rogers]

"Ray Blaak" <blaak@telus.net> wrote in message news:uzo1vx3w2.fsf@telus.net...
> "Pat Rogers" <progers@classwide.com> writes:
> > "Ray Blaak" <blaak@telus.net> wrote in message
news:u3czoxbjm.fsf@telus.net...
> > > If one means gcc to mean the suite of language specific compilers using a
> > > common code generation backend, then GNAT is a part of gcc.
> >
> > 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? 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?  Did this
> > Ada code and C code do the same thing?  What switches did he use for both?
>
> Hmm. I am not sure what was meant by the other poster, but my observation is
> that an Ada compiler would be inherently slower, almost by definition, since
> it does fundamentally more work than a C compiler. Even given similar source
> inputs and compiler settings, there will be more verification happening for
> the Ada source, and that extra work has a time cost.

Then let's look at it this way -- the OP asserted that all Ada compiler are
slower than all C compilers, on the evidence garnered from submitting "similar"
programs to a single compiler.  I'm saying that isn't enough.

Re: naval systems

[David Starner]

On Tue, 26 Feb 2002 19:49:42 GMT, Pat Rogers <progers@classwide.com> wrote:
> I don't understand this.  GNAT *is* gcc.

Technically, GNAT is the Ada compiler in GCC (the GNU Compiler
Collection.) gcc is the C compiler in GCC. 

I wasn't try to be technical, though. I just assumed everyone would
understand what I meant.

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

Re: naval systems

[David Starner]

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.

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

Re: naval systems

[David Starner]

On Wed, 27 Feb 2002 00:02:49 GMT, Pat Rogers <progers@classwide.com> wrote:
> Then let's look at it this way -- the OP asserted that all Ada compiler are
> slower than all C compilers, on the evidence garnered from submitting "similar"
> programs to a single compiler.  I'm saying that isn't enough.

The person to whom I was responding claimed that most Ada compilers were
as fast as, or faster than most C compilers. I merely pointed out that
this wasn't true for a common Ada compiler and the associated C
compiler, and expressed skepticism in the general case. I _never_ said
anything about all Ada compilers or all C compilers. 

I have provided test data supporting my conclusion, with programs that
for the most part have correspond on a line to line level. If you wish
to claim that most Ada compilers compile as fast as, or faster than,
most C compilers (in comparable conditions), you're welcome to write
your own testcases and run them through your compilers and come back
with the results, and I will be interested in hearing the answers. But
please stop the fact-free rhetoric.

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

Re: naval systems

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> a �crit dans le message news: a5hp7k$8q61@news.cis.okstate.edu...
> The person to whom I was responding claimed that most Ada compilers were
> as fast as, or faster than most C compilers. I merely pointed out that
> this wasn't true for a common Ada compiler and the associated C
> compiler, and expressed skepticism in the general case. I _never_ said
> anything about all Ada compilers or all C compilers.
>
Everybody is right here.
If you just compare compilation time, C is certainly faster.
If you consider the time between the first submission to the compiler and when your program is working correctly (which IMHO is what
really matters), then I take the bets that Ada is faster!

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: compiler benchmark comparisons (was: naval systems)

[Wes Groleau]

It would not surprise me if the _average_ C compiler
is faster than the _average_ Ada compiler.  The Ada
compiler 

 - must generate machine code for constraint checks,
   elaboration checks, and stack checks
 - must check for initialization and finalization
   and the need for exception handlers.
 - will do a lot more type checking (if the program
   was not poorly designed)
 - may do a lot more optimization
 - and (to exaggerate for effect) the Ada compiler
   will pedantically examine your syntax and semantics
   with the proverbial fine-toothed comb and harass
   you unmercifully for the smallest pecadillo, while
   the C compiler will happily generate code for almost
   anything produce by leaning on the keyboard.

It would not surprise me, either, if the range of speeds
for C compilers in general and for Ada compilers in general
is far wider than the average difference.  This depends
more on the algorithms used for parsing, analyzing, code
generation, and optimizing than it does on the language.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: naval systems

[Pat Rogers]

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

Re: compiler benchmark comparisons (was: naval systems)

[Pat Rogers]

"Wes Groleau" <wesgroleau@despammed.com> wrote in message
news:3C7D37FD.F67F7067@despammed.com...
>
> It would not surprise me if the _average_ C compiler
> is faster than the _average_ Ada compiler.  The Ada
> compiler
>
>  - must generate machine code for constraint checks,
>    elaboration checks, and stack checks
>  - must check for initialization and finalization
>    and the need for exception handlers.
>  - will do a lot more type checking (if the program
>    was not poorly designed)
>  - may do a lot more optimization
>  - and (to exaggerate for effect) the Ada compiler
>    will pedantically examine your syntax and semantics
>    with the proverbial fine-toothed comb and harass
>    you unmercifully for the smallest pecadillo, while
>    the C compiler will happily generate code for almost
>    anything produce by leaning on the keyboard.

What I'm trying to get to is what the OP thought was inherent in the language,
such that compile-time (not total time to produce the executable) would always
be different, and by "different", I believe it is clear he meant "slower".
Meaningful comparison requires that we have comparable language semantics and
comparable compiler behavior (as determined by the switch settings).  That means
the list of differences you cite above -- good ones in general -- would not be
in play for the code in question.

I'm not arguing that Ada compilers are faster in the general case, I'm looking
for the OP's language-oriented reasons that would apply to any compiler.

Re: compiler benchmark comparisons (was: naval systems)

[Gary Barnes]

Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3C7D37FD.F67F7067@despammed.com>...
> It would not surprise me if the _average_ C compiler
> is faster than the _average_ Ada compiler.  The Ada
> compiler 
> 
>  - must generate machine code for constraint checks,
>    elaboration checks, and stack checks

Most compilers are limited by the I/O speed of the machine rather than
by what they have to do to compile the language or by the machine code
they have to generate.  In the case of a C module, the compiler has to
open/read/close numerous .h files.  The number of .h files that are
read simply by doing an include on something "simple" like stdio.h can
be amazing on some systems; measuring in the dozens, on others it may
be a handful.  In the case of an Ada module, the compiler has to
open/read/close some number of files (GNU => every spec in the WITH
closure of the module, Rational => every directly WITH'ed spec of the
module).  The number varies depending on the compiler.  This is the
reason that C compiler for older "slow" machines, such as the Amiga or
the M68000 had options for creating pre-digested collections of .h
files.  It reduced the number of opens and reads and greatly increased
the perceived performance of the compiler.

If you strip away the open/read times for the source code, and the
open/write times for the output, there isn't a great deal of reason
for an optimizing C compiler and and optimizing Ada compiler to be
greatly different in the time they take for comparable source code. 
The open/write time will be dominated by the open.

If "average" compilation times for Ada compilers is larger than that
for "average" C compilers, it more likely because Ada compiler writers
spend a great deal of time worrying about "correct" and less time
worrying about "fast".  As a conjecture, the average Ada compiler also
tends to have a "large" number of targets (for cross compilation)
whereas the average C compiler may not (GCC is a noted exception!).

As a user of both GCC and GNAT, they seem to be comparably fast.  That
is strictly a "How long do I seem to have to wait and do I get
impatient." comparison.

Also, as a user of both Rational Apex Ada and the C compilers from
many Unix vendors, Rational's Ada would seem to compile similar
numbers of units per unit of time.  At least, I don't get any more
impatient compiling a mound of Ada than I do a mound of C.  If
anything, compiling a large Ada program seems to be faster; which is
again a seat-of-the-pants impression rather than formal results of
some sort of benchmark.

Re: compiler benchmark comparisons (was: naval systems)

[Dan Andreatta]

OK, just to be into this benchmarck craze, I did a few tests w/ gcc
and family.
These are the results, using GCC 2.95 (mingw) and gnat 3.13p on a PII
666MHz w/ NT 4.0:

GNAT    11.0 sec
g77      4.0
gcc      1.4
g++      3.3
obj-c    2.6  (writing a "cout" class)
gcc 2.8  1.0  (gnat gcc)
gpc 2.8  1.1

The programs are 1000 loops like:

for i in 1..100 loop
  ada.text_io.put_line( Integer'Image(i) );
end loop;
for i in 1..100 loop
  ada.text_io.put_line( Integer'Image(i) );
end loop;
....

or

for (int i=0; i<100; ++i)
  cout << i << endl;

and so on...
OK, GNAT is slower... and so? Anybody cares?

                  Daniele Andreatta

Re: compiler benchmark comparisons (was: naval systems)

[Jerry van Dijk]

> and so on...
> OK, GNAT is slower... and so? Anybody cares?

Well, I checked all my sources carefully, and none of them write out a
million integers in a tight loop, so no, I do not care.

Benchmarking compilers is very useful but also very difficult to do right,
especially if you want to compare different languages with different 
compilers.

To get an idea you can find on my homepage a package that contains a number
of small "standard" benchmarks such as dhrystone, whetstone, etc. in both
their C and Ada incarnations. Notice here the attempt to make sure that
the compiler switches for the different languages are as equivalent as
possible.

-- 
--  Jerry van Dijk   | email: jvandyk@attglobal.net
--  Leiden, Holland  | web:   users.ncrvnet.nl/gmvdijk

Re: compiler benchmark comparisons

[Georg Bauhaus]

Dan Andreatta <andreatta@mail.chem.sc.edu> wrote:

I'm not sure whether I understand this comment.
Is it about runtime performance of generated code
using some specific library functions? I thought this was
about the time it takes to compile a program?

(Incidentally, a similar test revealed that GNAT produced
x86 fpt code is surprinsingly fast, when tested against similar
attempts in C using the same backend. )



:  ada.text_io.put_line( Integer'Image(i) );

:  cout << i << endl;

Re: compiler benchmark comparisons (was: naval systems)

[Wes Groleau]

Distributed compilation is another point.

Most C compilers and GNAT can compile multiple
source files simultaneously in separate processes.
Apex can do that with limitations.  Can any other
Ada compilers do it?  I would think that the 
library model used by some would prevent it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: compiler benchmark comparisons (was: naval systems)

[Wes Groleau]

> GNAT    11.0 sec
> g77      4.0
> gcc      1.4
> g++      3.3
> obj-c    2.6  (writing a "cout" class)
> gcc 2.8  1.0  (gnat gcc)
> gpc 2.8  1.1
> 
> OK, GNAT is slower... and so? Anybody cares?

Hmmm.  Hit return, take a slow sip of coffee,
and start typing the next command.  I guess
I don't really care.  :-)

Actually, it does matter when you have
20,000 Ada files to compile.  Which is
why my point about distributed compilation.

But it also reminds me of another point.
With large C collections, to avoid unnecessary
recompilations, one generally runs a tool to 
generate Makefiles (or painstakingly does it by
hand).  With Ada, part of this job is done by
writing with clauses in the code, and the rest
of this job is part of the compile.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: compiler benchmark comparisons (was: naval systems)

[Ted Dennison]

andreatta@mail.chem.sc.edu (Dan Andreatta) wrote in message news:<338040f8.0202271819.373f733a@posting.google.com>...
> OK, just to be into this benchmarck craze, I did a few tests w/ gcc
> and family.
> These are the results, using GCC 2.95 (mingw) and gnat 3.13p on a PII
> 666MHz w/ NT 4.0:
...
> The programs are 1000 loops like:
> 
> for i in 1..100 loop
>   ada.text_io.put_line( Integer'Image(i) );
> end loop;
> for i in 1..100 loop
>   ada.text_io.put_line( Integer'Image(i) );
> end loop;
> ....

So basicly you are testing the speed of the program's I/O facility? I
suppose someone somewhere might care about that, but I/O is already so
slow compared to everything else that it doesn't really make much
difference to anyone. Add to that the fact that Ada has many other
options when it comes to I/O (including using C's I/O), and it means
less than nothing.

Re: compiler benchmark comparisons (was: naval systems)

[Larry Kilgallen]

In article <3C7E3C33.17E60A7D@despammed.com>, Wes Groleau <wesgroleau@despammed.com> writes:

> With large C collections, to avoid unnecessary
> recompilations, one generally runs a tool to 
> generate Makefiles (or painstakingly does it by
> hand).  With Ada, part of this job is done by
> writing with clauses in the code, and the rest
> of this job is part of the compile.

When the tool that generates the makefiles is the previous run of
the C compiler itself, the difference from Ada seems quite small.

Re: naval systems

[tony gair]

>
> Nonsense. Boeing _chose_ to use Ada for it's development of the 777,
> which had extremely tight schedules and where contracts were
> risk-sharing, not cost-plus. The FAA couldn't have cared less what
> language they used, so they gained nothing there, but Boeing saw enough
> gains in the language to pursue it for its own sake.
>

I was present on the project  testing phase of the 777 ada fly by wire
system, and my understanding of Boeings choice for Ada was the following

1) The systems functions and procedures needed testing at a component level,
Most Ada programmers I've met have experience of rigourous testing.

2) The contract for the fly by wire system was completed by Marconi Avionics
in Elstree, UK, who are mainly Ada programmers and normally do Big Guns
projects. This probably decided the project language. The ready availability
of design, and test tools used on Big Guns projects was possibly also a
deciding factor.

There were initially three different languages that were going to be used
for the project, but this idea was scrapped in favour of exclusively using
Ada.

Incidently the growling red faced project testing manager was rumoured to
whilst in work time  regularly partake in the abuse of certain columbian
exports.

Would you fly on this aircraft?

Re: naval systems

[David Gillon]

tony gair wrote:

> I was present on the project  testing phase of the 777 ada fly by wire
> system, and my understanding of Boeings choice for Ada was the following
> 
> 1) The systems functions and procedures needed testing at a component level,
> Most Ada programmers I've met have experience of rigourous testing.
> 
> 2) The contract for the fly by wire system was completed by Marconi Avionics
> in Elstree, UK, who are mainly Ada programmers and normally do Big Guns
> projects. This probably decided the project language. The ready availability
> of design, and test tools used on Big Guns projects was possibly also a
> deciding factor.

This is almost completely inaccurate. The only thing you have right is
that the contract was to MAv/GMAv, but even here it was in fact at
Rochester. On the initial prototype development two out of three teams
were non-Ada and the engineers reflected that. The decision to focus on
Ada across the entire aircraft, not simply the FCS, was Boeing's. Their
decision to go for single design/common code on the production FCS was
driven by certain decisions out of the FAA and came very late in the
day. MAv were only the sub-contractor on the FCS, and couldn't, for
instance, drive the choice of language on the AIMS which was being
written by Honeywell, or on any of the other systems. For the Boeing
perspective on their adoption of Ada for 777 there's a rather good
article in the Crosstalk archives.

> Would you fly on this aircraft?

In an instant. And I was on the project from before formal launch of the
777 to entry into service so I know precisely what went on during
development.

-- 

David Gillon

Re: compiler benchmark comparisons

[Dan Andreatta]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<a5lbnd$jsn$6@a1-hrz.uni-duisburg.de>...
> Dan Andreatta <andreatta@mail.chem.sc.edu> wrote:
> 
> I'm not sure whether I understand this comment.
> Is it about runtime performance of generated code
> using some specific library functions? I thought this was
> about the time it takes to compile a program?

Compile time, indeed. Yesterday I was running late, and missed some
explanations. I took the idea from the other thread, where this issue
was introduced. There a guy tried with random gotos, but it is easier
and faster to build a program with repeated blocks.
The times reported are without switches. I tried also some combination
of options, such as -gnatp, but the time was almost identical. The
main change in timing was due to optimizations. In that case, with
-O2, the gap between Ada and the rest widens, yelding these times to
compile the same code:

GNAT     250 sec
g77       13
gcc        5

The run times were around 0.2 sec for gcc and 0.5 sec for GNAT
(dumping the output).

Dan

Re: compiler benchmark comparisons (was: naval systems)

[Dan Andreatta]

Those are the times to compile the source code. The execution times
were much closer (0.2 sec gcc vs. 0.5 sec gnat, dumping the output).
If you meant the compiler I/O, the sizes of the source files were
around 45kb for C and 82 kb for Ada. So if the I/O is the limiting
factor, I would expect gnat to be slower by only a factor of 2, not
10, provided that the parsing routines have similar efficiency.
The bottleneck is not in the checkings, since the use of -gnatp does
not modify the times.

I don't pretend this is a good test, after all I did it in 10 minutes
yesterday night.

Dan

Re: compiler benchmark comparisons (was: naval systems)

[Wes Groleau]

> So basicly you are testing the speed of the program's I/O facility? I

No, she's testing code to compile IO calls.  Or compile and link.
I think.  Maybe.  It's starting to get confusing....

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: naval systems

[Wes Groleau]

> Incidently the growling red faced project testing manager was rumoured to
> whilst in work time  regularly partake in the abuse of certain columbian
> exports.

I partake of certain Colombian exports on work time.
My doctor might call it abuse.

But my coffee _is_ legal--I suspect you refer to
a different Colombian export.  ??

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: compiler benchmark comparisons (was: naval systems)

[David Starner]

On Wed, 27 Feb 2002 21:51:48 GMT, Pat Rogers <progers@classwide.com> wrote:
> What I'm trying to get to is what the OP thought was inherent in the language,

How about you stop assuming that you know what I think? 

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

Re: naval systems

[David Starner]

On Wed, 27 Feb 2002 21:44:32 GMT, Pat Rogers <progers@classwide.com> 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."

Re: compiler benchmark comparisons (was: naval systems)

[Pat Rogers]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a5mnim$9281@news.cis.okstate.edu...
> On Wed, 27 Feb 2002 21:51:48 GMT, Pat Rogers <progers@classwide.com> wrote:
> > What I'm trying to get to is what the OP thought was inherent in the
language,
>
> How about you stop assuming that you know what I think?

That I am assuming I know what you think does not follow from what you quoted.
Please address the issues I brought up if you want to continue.

Re: compiler benchmark comparisons

[Robert Dewar]

andreatta@mail.chem.sc.edu (Dan Andreatta) wrote in message news:<338040f8.0202281012.31593a2@posting.google.com>...
> In that case, with -O2, the gap between Ada and the rest 
> widens, yelding these times to
> compile the same code:
> 
> GNAT     250 sec
> g77       13
> gcc        5
> 
> The run times were around 0.2 sec for gcc and 0.5 sec for 
> GNAT (dumping the output).

First of all I think you mean gnu-c here (or you can just
say c in this context if you like), gcc is the GNU compiler
collection, and includes all three of these languages as
well as many others.

Second, if the gnu-c code runs 2-3 times as fast as the
C code it is simply NOT the same code. Usually when we look at
examples like this in detail, we discover that what
people think are "identical" programs are in fact totally
different and apples and oranges are being compared (*)

An odd phrase, what's so wrong about comparing oranges on
apples. I think I prefer oranges in general :-) :

Re: naval systems

[Pat Rogers]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:a5mqqo$9283@news.cis.okstate.edu...
> On Wed, 27 Feb 2002 21:44:32 GMT, Pat Rogers <progers@classwide.com> wrote:

<snip>

This is going nowhere.  Let's put it to bed.  I have no interest in generating
ill-will over something we apparently cannot communicate usefully about.

Re: compiler benchmark comparisons

[Dan Andreatta]

> First of all I think you mean gnu-c here (or you can just

Yes. My apologies.

> Second, if the gnu-c code runs 2-3 times as fast as the
> C code it is simply NOT the same code.

Yes and no. In this particular example the execution time is
determined mainly by performance of the I/O library. And the GNU/Ada
I/O library is slower than the GNU/C library. For fun I wrote some of
the "shootout" programs in Ada and the result was that the execution
times were comparable, except the ones that used heavily text I/O,
where the Ada times were 2-3 times higher. I admit I am a newby, so my
code was not so good, but, as I said, where the I/O wasn't the main
part of the program, I wrote pretty fast code.

> examples like this in detail, we discover that what
> people think are "identical" programs are in fact totally

Well, the core of the code was a repeated series of for loops:

for i in 1..100 loop
  ada.text_io.put_line( Integer'Image(i) )
end loop;

for Ada and for C:

for (i=0; i<100 : ++i)
  printf("%d\n",i);

What are the differences between the two?

BTW, the test was ment to test the compiler speed, not the quality of
the produced code. Maybe it wasn't clear in my previous posts.

Dan

Re: naval systems

[Jeffrey Carter]

David Starner wrote:
> 
> 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.

No, a few seconds difference in compiling large source files does not
matter.

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

No, the interesting question is the confidence you have in the resulting
executable. Ada is optimized for large systems with multiple modules.
Ada does type checking across separately compiled modules and handles
tasking, exceptions, and generics. To get the same level of confidence
in a large, multiple module system is faster in Ada than C since Ada
automates so much of what must be done manually in C.

If you're only interested in toy, single module systems, or you're
willing to accept the behavior your typos produce, then C is faster.

-- 
Jeffrey Carter

Boeing 777 (WAS: naval systems)

[Simon Pilgrim]

tony gair wrote:

> 2) The contract for the fly by wire system was completed by Marconi Avionics
> in Elstree, UK, who are mainly Ada programmers and normally do Big Guns
> projects. This probably decided the project language. The ready availability
> of design, and test tools used on Big Guns projects was possibly also a
> deciding factor.

As Dave stated in another reply, you are a bit wide of the mark there. 
Marconi Avionics has been through a few name changes and a merger, but
the flight controls has always been based in Rochester, Kent, UK.  We
are now part of BAE SYSTEMS, Avionic Systems Division.

We have been making civil and military flight control systems for many
years for aircraft such as Concorde, Eurofighter, Canadair RJ, Airbus
A320, UAVs and many more.  I believe it was this system knowledge and
our well-established relationship with Boeing, rather than any specific
language experience that influenced Boeing to select us.

> There were initially three different languages that were going to be used
> for the project, but this idea was scrapped in favour of exclusively using
> Ada.

The three languages were originally: C, Ada and PLM.  We now use a
subset of Ada, running on three different targets.

> Would you fly on this aircraft?

I have and I loved it.  I even stood under the flight path at the
airfield perimeter when the 777-200 took off for first flight (along
with several hundred other proud people).

The Boeing 777 was probably tested more than any other previous aircraft
before it left the ground, thanks to the enormous amount of simulation
work done.  You say you were present on the project testing phase, so
must have seen the huge investment Boeing made in the IASL (Integrated
Avionics Systems Laboratory?).  Also the huge amount of dedication and
professionalism from those involved.

If you wouldn't fly on the 777 because of safety concerns, you must live
in a bunker with a tin-foil beanie hat ;-)

-- 
Regards,
Simon Pilgrim
Civil Flight Controls, Rochester, UK
All views expressed are my own and not necessarily those of my employer.

Re: compiler benchmark comparisons (was: naval systems)

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<TgAW8WWqYgP5@eisner.encompasserve.org>...

> When the tool that generates the makefiles is the 
> previous run of the C compiler itself, the difference
> from Ada seems quite small.

Well it is in practice quite large in most environments. 
Very few C environments update the makefile on every
compilation (using tools like make depend), and one of
the most important differences is that it is perfectly
possible to link an inconsistent C program if your
hand crafted procedures to prevent this go astray.

So in practice, most Ada programmers find this a significant advantage
of Ada over C, but of course
your mileage may vary (after all there is nothing
that requires an Ada environment to have decent tools,
although there is still something that requires it to
check for inconsistencies, unlike the case with Ada).

Actually in most Ada compilers, it is hard to make the
automatic recompilation 100% accurate anyway, e.g. many
Ada systems end up with the amount of inlining depending
on the order of compilation. So there is no magical
guarantee here (one of the advantages of the source based
approach to compilation is that in fact it is feasible to
give a 100% guarantee on dependencies and recompilation,
since you can compile clients before you compile the packages they
need, so you do know what's needed before
compiling it.

Re: compiler benchmark comparisons (was: naval systems)

[Randy Brukardt]

Wes Groleau wrote in message <3C7E384C.A19AC609@despammed.com>...
>
>Distributed compilation is another point.
>
>Most C compilers and GNAT can compile multiple
>source files simultaneously in separate processes.
>Apex can do that with limitations.  Can any other
>Ada compilers do it?  I would think that the
>library model used by some would prevent it.


Janus/Ada can do it. It does use a project manager, but the projects are
locked only about 15% of the compilation time. And the compiler retries
to get a locked project for 30 seconds before giving up.

But the facility wasn't really intended to run multiple compilations on
the same project; it really was designed to allow network users to work
on separate projects with shared subsystems (like Claw).

Before we had the project manager, you could run as many compiles as you
wanted at once; but there was no protection against problems. Thus, if
two compiles chose the same output file name (which depended on the unit
name and a hash value), things could have gotten pretty messed up.
[Output files were limited to 8.3 names because that was the limit on
MS-DOS.] Which is why we introduced the project manager, so that file
name choices couldn't conflict.

            Randy.

Re: compiler benchmark comparisons

[Dan Andreatta]

> examples like this in detail, we discover that what
> people think are "identical" programs are in fact totally different

Er... you are right. (At this time Google hasn't reported any reply). 
I did some more experiments, and the bottleneck for the compiler was
in the genration of the code for Integer'Image(). I modified the loop,
and now it look more like the C version, relying on the I/O library
(using Ada.Integer_Text_IO).
Amazingly, now it compiles in about 2 seconds. Summarizing, these are
the data (below are the fragments of the codes used):

                      GNU/C      GNU/Ada (1)      GNU/Ada (2)    
GNU/Ada (3)
Source size (kB)       45           82              103             
97
Object size (kB)       63          503              503            
109

time to compile (s)   1.4         11.0              8.0            
2.2

compiled with gcc -c file.adb (no switches)

In conclusion... draw your own conclusion. 

Memo for me: next time don't spare resources, use at lest 2 neurons
:-)

The codes for the loops (repeated 1000 times) were:

GNU/C
for (i=0; i<100; ++i)
  printf("%d\n",i);

GNU/Ada (1)
for i in 1..100 loop
  ada.text_io.put_line( Integer'Image(i) );
end loop;

GNU/Ada (2)
i := 0;
while i<100 loop
  ada.text_io.put_line( Integer'Image(i) );
end loop;

GNU/Ada (3)
for i in 1..100 loop
  ada.integer_text_io.put( i );
  ada.text_io.new_line;
end loop;

Re: compiler benchmark comparisons

[tmoran]

> and now it look more like the C version
> ...
> for (i=0; i<100; ++i)
>   printf("%d\n",i);
  Seems to me a closer approximation to the C would be

procedure printf(s : in string; i : in integer) is
begin null;end printf;
-- then lots of copies of
for i in 1..100 loop
  printf("%d\n", i);
end loop;

Making two function calls, whether they are in separate statements, or,
worse, one is a variable length string-returning parameter to the other,
likely takes the compiler more time than just one call, and, if IO time is
a consideration, then having a source file that is twice as large is also
a disadvantage.

Re: compiler benchmark comparisons (was: naval systems)

[Pascal Obry]

dewar@gnat.com (Robert Dewar) writes:

> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<TgAW8WWqYgP5@eisner.encompasserve.org>...
> 
> > When the tool that generates the makefiles is the 
> > previous run of the C compiler itself, the difference
> > from Ada seems quite small.
> 
> Well it is in practice quite large in most environments. 
> Very few C environments update the makefile on every

And this can be said for many points. In almost all discussions I have with
co-workers about programing languages features, each time I show on advantage
in Ada I got something like "but this is also possible with XYZ language" !

And of course it is possible, everything is possible with every programing
language... The fact is completly different. If the language does not have a
built-in tools to support the feature then it is not addressed. Because the
dead-line is comming, because money, because time... everything that require
some more work to setup the environment, tools is most of the time skipped.

To goes even farther I find the GNAT -gnaty option very nice. You can write
on paper rules about laying out of code and syntax but if the compiler does
not check that who will ????

> So in practice, most Ada programmers find this a significant advantage
> of Ada over C, but of course
> your mileage may vary (after all there is nothing
> that requires an Ada environment to have decent tools,
                   ^^^^ C here I think
> although there is still something that requires it to
> check for inconsistencies, unlike the case with Ada).

In theory there is no difference in theory and practice... in practice 
there are :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: compiler benchmark comparisons (was: naval systems)

[Simon Wright]

Pascal Obry <p.obry@wanadoo.fr> writes:

> To goes even farther I find the GNAT -gnaty option very nice. You
> can write on paper rules about laying out of code and syntax but if
> the compiler does not check that who will ????

I quite agree, it saves endless disagreement about style. Our project
has accepted my recommendation that we use it (plain -gnaty, no fancy
messing, why write -gnaty3abcefhiklmprst !!)

Re: compiler benchmark comparisons (was: naval systems)

[Richard Riehle]

Pascal Obry wrote:

> And this can be said for many points. In almost all discussions I have with
> co-workers about programing languages features, each time I show on advantage
> in Ada I got something like "but this is also possible with XYZ language" !

The first time I encountered this argument, circa 1969, we were a Fortran shop
with a new contract from the Navy for a specialized inventory control system.
I was assigned project leader, and I suggested we do the project in COBOL
instead of Fortran.    There was no end of grumbling from the Fortranners who,
every time I would identify a key benefit of COBOL for this project, would
exclaim, "I can do that in Fortran."

Nearly any problem that can be solved in one programming language can also
be solved in any other language.   That is, the solution for every programming
problem is ultimately expressible in every other language.     To defend one's
choice of programming language using this rationale simply overlooks the
more important question.    Is language K more expressive of the problem
to solution mapping than language P?

Expressiveness is a far more important criterion than expressibility.  In Ledgard's
little diagram of soution-space mapped to problem-space, we see this issue
in broad relief.

There are, of course, trade-offs.   One language may be more expressive than
another, but may have insufficient built-in safeguards;  or it may not have the
critical mass in usage (e.g. Erlang), or it may have some other drawback.  However,
to say, "I can do that in my favorite language too," simply fails to recognize
the deeper issues one must consider in selecting a programming language
for a given project.

Richard Riehle

Re: naval systems

[David Starner]

On Fri, 1 Mar 2002 17:22:08 GMT, Jeffrey Carter <jeffrey.carter@boeing.com> wrote:
> David Starner wrote:
> [...]
> 
> No, a few seconds difference in compiling large source files does not
> matter.
> 
>> 
>> 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.
> 
> No, the interesting question is the confidence you have in the resulting
> executable. 

An answer of a sophist. The few seconds difference was on compiling the
null program; the large source file took 6 minutes longer. And while
the reliability of the program is important, it's not the only question,
or Dewar wouldn't still be telling us how fast his COBOL compiler was.

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