Re: is C necessarily faster than C++

cliffc@crocus.hpl.hp.com (Cliff Click)
Mon, 17 Apr 1995 13:36:42 GMT

          From comp.compilers

Related articles
[5 earlier articles]
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++ beard@cs.ucdavis.edu (Patrick C. Beard) (1995-04-28)
is C necessarily faster than C++ ka@socrates.hr.att.com (1995-04-28)
Re: is C necessarily faster than C++ jplevyak@pink-panther.cs.uiuc.edu (1995-04-29)
[10 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: cliffc@crocus.hpl.hp.com (Cliff Click)
Keywords: C, C++, performance
Organization: Hewlett-Packard Laboratories, Cambridge Research Office
References: 95-04-044 95-04-077
Date: Mon, 17 Apr 1995 13:36:42 GMT

tbrannon@mars.mars.eecs.lehigh.edu (tbrannon) 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.


maccer@MT.net (Johnathon McAlister) writes:
> True. Message passing is either early-bound or late bound. In early
> binding, we know that the message will not be overridden, and thus know
> what code will be run at compile time. We can thus generate a direct
> sub-routine call to said code. In late-binding, we don't know what code
> will be used until run time. However, it appears that this is usually
> implemented by pointers to routines - overriding a message simply entails
> changing the value of the pointer. The actual call then is a jump vector,
> which is also pretty fast.


My general rule-of-thumb is: only replace large switch statements with
virtual function calls. They have roughly the same overhead (at least
on all the machines/compilers I've looked at) but the virtual call is a
more easily understood (modified/debugged/flexible) representation.


Of course, I understand compiler technology too well 8-P, so I tend to
use the coding styles and language features that I _know_ the compiler
will do well with. Next year's compilers will do better, so my old
code is more opaque than nessecary (for performance reasons that no
longer hold true!).


If there's a moral to this thread it's this: write clear code with the
best use of the language features you can, and trust the compiler to
sort out the mess. Then profile the dickens out of your code, to find
out where the compiler DIDN'T sort things out!


Cliff
--
Cliff Click Compiler Research Scientist
Cambridge Research Office, Hewlett-Packard Laboratories
One Main Street, 10th Floor, Cambridge, MA 02142
(617) 225-4915 Work (617) 225-4930 Fax
cliffc@hpl.hp.com http://bellona.cs.rice.edu/MSCP/cliff.html
--


Post a followup to this message

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