Re: Ada to C/C++ translator needed

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

"Tim Behrendsen" <tim@a-sis.com> writes:

>I would conclude that for that *specific* problem, the C compiler
>did a bad job of optimization.  As I frequently point out (and
>I frequently get abuse for it), optimizers are very imperfect
>beasts at best.

Well, it all depends on what you mean by a "bad" job of optimisation.
I actually tried several compilers, and the Sun C compiler was one
of the *best*.  If you call being 3rd out of 10 "a bad job", if you
call taken 1.2x the time of the very best but 0.2x the time of the
very worst "a bad job", then you have made your point.

>Do you doubt that if we brought the writers of the Sun compiler
>and had them fix their optimizer, they couldn't make it produce
>*exactly* the same code as the Ada compiler (or Fortran compiler,
>for that matter)?  Of course they could.

You are wrong.  Of *course* I doubt it, and so does anyone who understands
how compilers work.  Compilers have to respect the semantics of the
languages they compile.  They cannot take shortcuts that might produce
incorrect results.  Until the 'restrict' keyword is a standard part of C,
which it soon will be, but currently isn't, a C compiler will not be
*allowed* to pull the kinds of tricks that the Fortran compiler did in
this example.

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

I refuse to come to terms with it, because there can be no useful or
meaningful answer to it.  

 - tests over a wide range of problem types are of absolutely no
   interest to the person who started this thread; that person has
   ONE program and was considering converting from Ada to C.
   Suppose your impossible average were that Ada was 1.2 times
   faster than C.  Would that tell the person who has a specific
   problem whether to use Ada or C?  OF COURSE IT WOULDN'T.

 - tests over a wide range of compilers are of absolutely no interest.
   I can bias the results any way I want by insisting on the inclusion
   of enough bad compilers.  And the results are of no interest at all
   to the original poster who simply isn't concerned with _all_ Ada
   compilers or _all_ C compilers.  

 - insisting on a wide range of compilers is a profoundly dishonest
   thing for you to do.  My claim is that there is *one* free Ada
   compiler which in my admittedly limited experience routinely does
   as well as or better than the *best* C compiler I have available to
   me.  (Believe me, the Sun C compiler has a *good* optimiser, and if
   I were trying to develop graphics code exploiting the VIS opcodes
   I couldn't ask for a better.)  This fact *is* of interest to the
   poster who started the thread:  there is a *free* Ada compiler
   which does very well; it doesn't *MATTER* what other Ada compilers
   do.  I have been trying very hard to stick to the topic of this
   thread, which has nothing to do with whethere Ada is *always*
   better than C or not, but only with whether it would make
   economic sense to convert from Ada to C when there is a very good
   free Ada compiler.

 - tests over a large set of non-trivial programs would be of interest
   *in the general case*.  But I am concerned with the person who was
   thinking about converting *one* program to C.

   Again, you can get any results you want by insisting on suitably
   biassed programs.  There is a lot of seriously inefficient code
   out there.

Can you not get it through your head that I was not stating any
general proposition, but simply saying that I saw no obvious reason
why _one_ program should be converted from Ada to C, and giving a
*supporting example*?

>Your suggestion that comparing compilers on one platform for
>one program tells you something significant is laughable at
>best.

You may not think it significant that a free compiler for a robust
language outperforms a non-free compiler for a less expressive and
less robust but more popular one.  I do.  If you don't think the
obvious implication (get GNAT and try it on _your_ program and see
if you like the performance), then laugh away, but the laugh's on you.

>Sounds like it's a crappy C optimizer to me, especially considering
>the wide disparity between the C results and the other languages.

What "wide" disparity?  The smallest time in the set was 25 seconds.
The largest time was 141 seconds.  The C time was 30 seconds.  (And
to the best of my belief, it uses the *same* optimiser as the
Fortran compiler!)

The machine where I did the tests has been upgraded.  
    gcc -O6		14 seconds
    Sun cc -xO4		12 seconds
If you want to call the SPARCompiler optimiser "crappy", what words
will you find for the GCC one?

>*This* is a reasonable conclusion.

Your conclusion that the SPARCompiler C optimiser is "crappy"
is not a reasonable one.  *You* will have to provide some data if
you want to make _that_ claim.

>If you have bothered to write
>other programs in C and Ada, that would indicate to me that they
>were trivial algorithms, and therefore your conclusions invalid.

I see.  If someone *does* do head to head comparisons, they
are necessarily trivial and therefore invalid.

>Look at it this way; if I implement an algorithm in two languages,
>C and C++, and compare the results, they will probably be very
>similiar (if not identical).

The GCC compiler's output is as much slower on this platform as
the Sun C compiler's output is slower than the Sun Fortran 77 compiler's.
You called 20% a "wide disparity" and the sign of a "crappy" optimiser.
But there is as much difference between compilers for the *same*'
language as there is between good compilers for *different* languages.

Let this stand as a generalisation I *would* be prepared to defend:

   if a head to head comparison between compiler A for language X
   and compiler B for language Y on the platform of interest to you
   does not find a difference in excess of 20%, it is not worth
   your while converting from the _apparently_ slower language to
   the _apparently_ faster language.  (There are of course exceptions
   in embdedded and real-time programming.)

I can see no reason to expect C++ performance to be as good as C
performance in general.  Compiler writers have enough on their hands
trying to cope with an extremely complex language which has historically
been changing faster than compilers could keep up, I count it a miracle
when a C++ compiler generates _working_ code for a C++ program.

Let's just get a data point:
	cc	12 seconds		\ from Sun
	CC	13 seconds		/ from Sun (NOT cfront)
This is comparable to the difference I reported between C and Ada,
and it's the _same_ source file.

>However, let's take a very large
>project with two teams of people, and have 1 implement the project
>using C, and one implement it using C++.

As soon as you have a very large project, you have extremely great
variations between programmers.  As soon as you deal with C++, you
have to cope with immature compilers, severe porting problems, and
other problems.

>I have no formal study for this, but speaking to many people who
>have gone through the process, and reading a lot about many
>manager's experiences, I have heard a common theme: Projects
>implemented using OOP within the C++ language have experienced
>significant performance problems because of the overhead of class
>structures, heavy dependance on dynamic memory allocation, and the
>difficulty in designing good object classes.

I have no quarrel with this, except to note that
(a) it has absolutely no relevance to the originator of this thread,
    who was thinking of *converting* an existing Ada program to C.
    What would that do to performance, portability, and price of
    maintenance?  Those are relevant questions for this thread.

(b) you have only given us half the story:
	  Did not use OOP  Did use OOP
	+----------------+----------------+
    C	| Fewer problems |  ????????????  |
    C++ | ?????????????? | More problems  |
	+----------------+----------------+

    What about programs that used OOP in C?  It's often enough done.
    What about programs in C++ that didn't use OOP?  That's supposedly
    a selling point of C++, that it's a "better C".

>This is not because of optimization; this is because of the
>language and style in which projects are implemented.

Now _there_ is a non-sequitur, if ever there was one.  Can it be that
you are totally unaware of the work that has been done on link-time
optimisation of OOP programs to reduce the cost of dispatching?  (Not
only does this often eliminate dispatching, but that then enables
inlining, which permits more optimisations.)  As for the costs of
dynamic memory allocation, that can be extremely cheap, so why do
you think it might not be?  Are you unaware of the work on region-
based analysis?

As for the difficulty of designing good classes, good design is always
hard, but having conceded that, what is this supposed to tell the
originator of this thread, who was concerned about converting an
*EXISTING* program from Ada to C.  We have not been told whether it
used OOP or not, but if it did, any design has _already_ been done.

>Now, this is a significant debatable question.

What is?

- overhead of class structures?
  Compared with what?
  One of the *achieved* design goals of C++ is that you don't have any
  memory overheads compared with C if you don't explicitly ask for them.
  Such overheads as may exist depend a great deal on compiler technology.

- heavy dependence on dynamic memory allocation?
  But dynamic memory allocation can be very cheap.
  UNIX C malloc() implementations have traditionally been very expensive,
  unless you use mallopt().
  A *lot* of work has been done on reducing the costs of dynamic memory
  allocation, with excellent results, but you would dismiss this as
  compiler optimisation, and therefore as not worth talking about when
  it doesn't lead to the result you want.

  C++ has the notational resources to admit very efficient (but still
  "manual" and therefore not entirely trustworthy) memory management.
  
- difficulty of good design?
  What's to debate?  Of course it's hard, that's why design patterns
  and reuse libraries are so important.

>Comparing the output
>of optimizers is completely worthless to the central question
>of whether REAL WORLD projects can be implement efficiently in
>a particular language or not.

That may be *your* central question, but it was *not* the topic of
this thread.  Just to say it once again: the initial question was
about converting Ada to C, and my question was "why bother? is there
any reason to expect it to buy you anything? I don't think so."

Can real world projects be implemented efficiently in Ada?
Well, if you insist that anything I can write must be trivial and
my conclusions invalid, I shall have to leave that to other people
to answer.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.