Re: is C necessarily faster than C++

ruiter@ruls41.fsw.leidenuniv.nl (Jan-Peter de Ruiter)
Thu, 20 Apr 1995 04:23:31 GMT

          From comp.compilers

Related articles
[4 earlier articles]
Re: is C necessarily faster than C++ t.hulek@imperial.ac.uk (1995-04-18)
Re: is C necessarily faster than C++ A.McEwan@lpac.ac.uk (Alistair McEwan) (1995-04-18)
Re: is C necessarily faster than C++ Marianne.Mueller@Eng.Sun.COM (1995-04-07)
Re: is C necessarily faster than C++ kohtala@laurel.trs.ntc.nokia.com (1995-04-09)
Re: is C necessarily faster than C++ rdo@elt.com (1995-04-10)
Re: is C necessarily faster than C++ tmb@netcom.com (1995-04-20)
Re: is C necessarily faster than C++ ruiter@ruls41.fsw.leidenuniv.nl (1995-04-20)
Re: is C necessarily faster than C++ cliffc@crocus.hpl.hp.com (1995-04-17)
Re: is C necessarily faster than C++ gardner@pink-panther.cs.uiuc.edu (1995-04-28)
Re: is C necessarily faster than C++ urs@engineering.ucsb.edu (1995-04-28)
Re: is C necessarily faster than C++ quanstro@hp-demo1.minerva.bah.com (1995-04-28)
Re: is C necessarily faster than C++ - comp.compilers #7069 det@sw.stratus.com (David Toland) (1995-04-20)
Re: is C necessarily faster than C++ beard@cs.ucdavis.edu (Patrick C. Beard) (1995-04-28)
[12 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: ruiter@ruls41.fsw.leidenuniv.nl (Jan-Peter de Ruiter)
Keywords: C, C++, performance
Organization: Compilers Central
References: 95-04-044 95-04-073
Date: Thu, 20 Apr 1995 04:23:31 GMT

tbrannon <tbrannon@mars.mars.eecs.lehigh.edu> wrote:
>This guy in my lab keeps refusing to use C++ in our program intended
>to simulate somatosensory neural circuits because he says it is slower
>than C. My (uninformed) response was that most of what you see as
>overhead (ie, message routing, value accessing, type checking) is
>optimized away at compile-time.
>
>Any pointers to more empirical studies?


Well, in principle the only factor that could significantly slow down
C++ relative to C is the overhead attributed to virtual functions.
However, in practice, because every complex object has both a constructor
and a destructor, there is an additional function overhead cost.


It is said that these can be inlined, but not all compilers do so,
and it's not always possible either. More importantly, constructing
and destructing local complex objects takes a lot of malloc-ing and
free-ing. Experienced C programmers having to write efficient code
usually avoid many calls to malloc by fooling around with pointers
and keeping track of allocation themselves.


Take a C program that manipulates strings. Experienced C programmers
will keep track of what string resides where, avoiding unneccesary
copying. Now using a good string library in C++ relieves you of the
burden of keeping track of your memory, but it adds the overhead of
constructing and destructing them. In a way it's like the shortcuts
one can take using assembler. Using assembly language can give you
a certain performance advantage, but you have to pay more attention
to the dirty details.


Hope this helps,


Jan
--


Post a followup to this message

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