Performance of C++ [was Re: Embedded C++]

[Brendan Kehoe <brendan at cygnus dot com>]

> I personally see EC++ as the wrong direction: It is no guarantee at
> all that the compilers supporting it will produce efficient, compact
> code. Instead, they propose arbitrary restrictions on programs, based
> on what they consider "hard to implement".
> 
> As it turns out, some of the EC++ restrictions don't help at all in
> reducing code size or increasing execution speed. For example,
> multiple inheritance added significant overhead in g++ in the past,
> even if it was not used. The solution, of course, is to introduce
> thunks, and not to forbid the usage of multiple inheritance.


The EC++ spec itself is undergoing revision, taking steps like reintroducing
templates.  The new version isn't yet available, though.  Unsure when it will
be.  With templates back in, that means the library definition in the EC++
spec is also open for revision, to be closer to the final standard.

A new sub-group of the ISO C++ committee, adding to the current two, one for
core language issues and one for library issues, is undergoing creation to
focus on the use of C++ in Performance-critical areas.  That could include
places where code size matters (like embedded systems), or realtime systems
where it has to have good speed but be 100% reliable.

To that end, the sub-group (which I'll be chairing) is going to put together a 
technical report based on the ISO C++ standard that will, tentatively, focus
on four areas:

  - ways for users to make efficient use of C++
  - ways that vendors can use or implement features well for
    performance-critical systems
  - a section on "programmer-directed optimizations", like ways that
    tools can transform virtual calls into non-virtual ones,
    alternative approaches to exception handling, effects of
    restrictions on character types, et al.
  - a section about extensions that can be made to the C++ Library,
    like handling low-level storage allocation in operator new,
    fixed-sized data types (like in C9X's stdint.h), et al.

Companies that have representatives on the C++ committee can have their member 
take part in that sub-group.  (And are encouraged to seek it!)

There's also a mailing list, c++-embedded@cygnus.com, that can be used for
discussion of the use of C++ in the embedded arena.  (Write
c++-embedded-request@cygnus.com to join it, or just reply to me asking.)


Anyway, the gyst of this whole answer is that while it might be helpful for a
few people to heed the rules in the (now old) C++ Embedded Specification, it
might be more worthwhile to try to find ways to contribute to the standards
comittee's effort.  The idea will be to focus on ways that things can be
improved, but trying to also take into account that this technology is at an
amazing rate of change.  We could add stuff to the compiler to give such
errors (if you use namespaces, e.g., though those may be part of what's going
back in).  But the usability of it is uncertain, I think.  Rather, focusing on 
ways to improve what's created by g++ would be much more worthwhile.  Instead
of warning about the use of a feature that's known to cause code bloat (though 
there are fewer and fewer of late), we could identify those and figure out
ways to change, reimplement, or redesign them to get rid of that kind of
headache.

My $.02,
B

-- 
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Solutions, Sunnyvale, CA                                +1 408 542 9600

Web page: http://www.zen.org/~brendan/