Related articles |
---|
[12 earlier articles] |
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) |
Re: is C necessarily faster than C++ tmb@netcom.com (1995-04-29) |
Re: is C necessarily faster than C++ jdean@pysht.cs.washington.edu (1995-05-09) |
Re: is C necessarily faster than C++ calder@mumble.cs.Colorado.EDU (1995-05-09) |
Re: is C necessarily faster than C++ schow@bnr.ca (stanley (s.t.h.) chow) (1995-05-09) |
Re: is C necessarily faster than C++ mike@vlsivie.tuwien.ac.at (1995-05-04) |
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-05-16) |
Re: is C necessarily faster than C++ itcp@praxis.co.uk (1995-06-23) |
[3 later articles] |
Newsgroups: | comp.compilers |
From: | tmb@netcom.com (Thomas Breuel) |
Keywords: | C++, performance, design |
Organization: | NETCOM On-line services |
References: | 95-04-044 95-04-153 |
Date: | Sat, 29 Apr 1995 12:16:45 GMT |
urs@engineering.ucsb.edu (Urs Hoelzle) writes:
| Actually, I don't buy that - I believe the proper conclusion from the
| paper is "current C++ compilers don't optimize C++ programs as well as
| current C compilers optimize C programs". In other words, much of the
| difference is in the compilers and not the languages.
The problem is really language complexity.
C++ is so complex that compiler implementors have to spend most of
their time on getting things like templates and exceptions right, time
that they cannot spend on getting better performance.
And C++ is so complex that sources of inefficiencies can be
difficult to track down, quantify, and fix.
C++'s object-oriented approach also encourages people to invest more
time in reusable and extensible code, but that time is wasted
(and unavailable for performance improvments) if the code is never
going to be reused or extended.
As a programmer, you can avoid the latter two sources of
inefficiencies by keeping code simple and to the point. But you can't
help suffering from compilers that aren't as high quality as they
could be if the language were simpler.
Thomas.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.