Re: Ada to C/C++ translator needed

["Tim Behrendsen" <tim@a-sis.com>]

Ian Ward <wardi@rsd.bel.alcatel.be> wrote in article
<52ttll$351@btmpjg.god.bel.alcatel.be>...
> In article 87ee6fce@timpent.a-sis.com, "Tim Behrendsen" <tim@a-sis.com> () writes:
> >
> >Well, now you throw in new information that the problem in question
> >was not able to be optimized due to constraints of the C language.
> >Of course, this is still not relevent to a large project that
> >presumably the original poster has.
> 
> Can I ask, are you agreeing with Richard here that, because of the
> flexibility of "C"'s semantics, "C" compilers have a more difficult
> optimisation task. (Or are you disagreeing.)

I agree with this.  This topic has flamed up so much from my
original simple assertion.  All I'm saying is that general
conclusions on the efficiency of a large project in different
languages can't be made from small test cases, particularly
numerical algorithms.

> >> >The real question that you refuse to come to terms with is, what
> >> >is the average case over a large set of compilers over a large set
> >> >of non-trivial programs over a large set of problem types?  And
> >> >this is a very difficult question to answer.
> >> 
> 
> This is very difficult, noone I know has ever done this experiment.
> I guess this is because it involves spending a lot of money.

And a lot of time, and even then the results are open to
interpretation.  This is why small specific examples implemented
into various languages do not give very much general purpose
information applicable to large projects.

> >No, if *you* have.  Since you haven't brought up any large-scale
> >comparisons, I have to conclude that you haven't done any.  If
> >there are any large-scale project comparisons, they may be valid.
> >
> 
> It is very difficult to do large scale comparisons, there are only
> two of which I know. The first is the well documented case by
> ? Dr. Stephen Ziegler ? (apologies if the name is incorrect.)
> 
> The second is the Boeing 777 flight software, where three separate
> projects (which was a really good idea,) were started to implement
> the software, one in "C", one in PL1, and one in Ada. The problem
> with comparing these languages in this situation was that a. Ada 
> was designed for writing big, and reliable, and embedded systems.
> Therefore it is unlikely that "C" was ever going to be at the 
> same stage of development to make sensible comparions. (In fact,
> that is exactly what happened, Byte described the projects of having
> "nuisance disconnects" which was the politically sensitive way of
> describing something else.) The end result was that "C" was being
> used for something it was not designed for, and understandably it
> was coping no better than it could have reasonably been expected
> to have. Thus it was canned, as was the PL1. (This is my
> interpretation of the printed word.)

I agree it is very difficult to make comparisons, which is why
we have to go anecdotal evidence such as these.  And it would
seem that they only made bug analysis comparisons rather than
performance comparisons (unless there was more to the article
than you are quoting).

To tell you the truth, I am reaching a stage in my programming
"maturity" to where I would be willing to give up some efficiency
for safety (within limits, of course).  Perhaps I won't have to
as compiler technology improves.

> >>[snip: lots of work in improving dispatching; dynamic mem alloc]
> >
> >You live in the ivory tower; I live in the real world.  You may want
> >to come out and get some fresh air once in a while.  If technology
> >comes along such that these problems get solved, then I will
> >embrace it.  Until then, why destroy my products in the name of
> >"progress"?
> 
> It am sure that if (at least) GNU Ada decides that a dispatch can
> be worked out at compile time, as it often can, then more likely than
> not, it will do a direct call instead. This one optimisation I 
> already know about, and I don't really know anything about the subject.
> So I have to go with the ivory tower here. Compilers (all compilers)
> really have come on, there are few low-level programmers that can
> now keep up with them (even given the five or six hundred thousand
> million times slower they are at writing assembler.)

I admit that compiler technology has been improving in recent years,
and will continue to improve.  I have been burned before by new
technology that ended up being dead ends, so I am somewhat cautious
when it comes to embracing the latest fads.  "The pioneers take the
arrows.  It's the people that follow the pioneers that build the
cities."  This is how I see OOP, as an example.  There is so much
admittedly anecdotal evidence of OOP performance disasters that I
take a very wait-and-see attitude.  It's all well and good if there
are solutions in the pipeline, but until I have an IBM part number
for AIX, it doesn't do me much good.

-- Tim Behrendsen (tim@a-sis.com)