Re: Will C++ compilers ever be better than C compilers?

mayan@watson.ibm.com (Mayan Moudgill) writes:
> My claim was that one would have to compile such programs with a C++
> compiler, and the compiler would not be as "optimizing" as a C compiler.
>
> My reasons were:


You definitely raise some valid points. In general, the larger the
language (in terms of features, a very subjective measurement of course),
the less man-power a vendor can devote to optimizations *in general*.


However, there are some mitigating factors that you did not mention:


    * Most vendors use a common back-end for all (or most) of their
        compilers. This allows all languages to benefit from the optimizations
        implemented in that common back end. Concurrent Computer, for example,
        uses a common back end for C, C++, Fortran, and Ada/Ada95. Therefore,
        our C++ compiler started out, day 1, with all the optimizations that
        our C compiler had.


    * Lots of C++ vendors are moving towards a model of supporting only one
        compiler for both C and C++, with a compile-time option to select the
        language. This makes it even more likely that the two languages will
        share the same optimizations.


> 1) In practice the ultimate size of a compiler is constrained,


Umm, well, that might be true, but if one considers a compiler *suite*
as the application, and the addition of a new front-end (for a new
language) as an add-on, what then?


> 2) The effort of implementing an optimization may be higher in C++,


Perhaps. The effort to add an optimization to a common back-end is
higher yet, but you get a lot more bang for the buck, so the added
effort is worth it. So far, I haven't seen any optimization that is
harder to do in C++ than it is for Ada, so I don't foresee us having a
lot of additional problems adding new optimizations for C++.


> it has to work correctly in more contexts (what happens if there
> is an exception? what if it is multiply inherited?)


Those things pretty much fall out if the front-end correctly describes
those constructs to the optimizer. Of course, they still need to be
tested (as you pointed out).


> 3) To get "OO"-ish written in C++ programs to work efficiently requires
> optimizations that are irrelevant in C (consider inter-procedural
> type propagation to convert virtual function calls to function
> calls).


Each language brings along its own requirements for optimization,
that's true. Ada, for instance, really cries out for range
propagation in order to reduce the number of constraint checks the
compiler must insert. C, C++, and Fortran benefit very little from
that optimization, but it is pretty much required for a
commercial-quality Ada compiler.


Fortunately for us, Ada95 has many features equivalent to those in
C++; Ada95 tagged types are very similar to classes with virtual
functions in C++, so Ada95 can benefit from the optimizations
implemented for C++.


> Consequently, the optimizations that are written may be irrelevant
> to the performance of "C subset" C++ code.


They might not have the same effect, but they are not necessarily
irrelevant. A large part of the inter-procedural analysis required to
optimize virtual function calls can also help optimize pointer
references in C. Consider the large amount of C code that uses unions
as a primitive kind of "tagged type", and you'll see lots of C code
that can benefit from the optimizations required to optimize virtual
function calls in C++. The same goes for C code that uses pointers to
functions.


The key to making this work efficiently is to generalize optimizations
whenever possible. If you implement an optimization specifically for
one language feature, you're not getting the best result for your
investment. That's true for one language or many.
--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.ccur.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.