Time and memory performance of C versus C++

[Matthias Buelow]

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

The amount of time/money spent on maintenance and extending the
software.

Shoddy code begets more shoddy code because improving it would take a
lot of time and everyone wants to get fingers off the program asap.

(Obviously I put more importance on elegance than on raw performance
although there is a strong correspondence between the two in non-toy
projects. As a rule of thumb, the lower-level a programming language is,
the better small programs can be made to perform, and the higher-level a
language, the easier it is to write well-performing large-scale
programs, where I go with Alan Perlis' definition of "level" that a
language is low-level if its programs need to pay attention to
irrelevant details.)

 

[Matthias Buelow]

For instance frequently you know from the
program logic that an array bounds error cannot happen.

If the compiler would just trust programmers, we wouldn't have any
segfaults. Oh, wait a minute...

Since the vast majority of code
is not in the inner loop, and thus not time critical, that's often a
reasonable trade off. But not always.

For the few cases where it matters, one can use a profiler to identify
these and, if needed, write some more specialized code.

 

[Alex Vinokur]

A lot of research has been done to prove that the contention that C
code is more efficient and more compact than equivalent C++ code is a myth.

[snip]

Look at C/C++ Program Perfometer
http://groups.google.com/group/perfo?lnk=sg

Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

 

[user923005]

code is more efficient and more compact than equivalent C++ code is a myth.

[snip]

Look at C/C++ Program Perfometerhttp://groups.google.com/group/perfo?lnk=sg

In this bit of code:

template <typename T>
static T templated_foo (const T&) { T t; return t; }

static int ordinary_foo (int) { int t; return t; }

Uninitialized data is returned:
q:\perfo-2-9-0--1-19\src\t_call.cpp(60) : warning C4700: uninitialized
local variable 't' used
q:\perfo-2-9-0--1-19\src\t_call.cpp(62) : warning C4700: uninitialized
local variable 't' used

I cannot find a clear answer in the C++ standard, but I think that
this may be a case of undefined behavior.

I do not understand how this code is supposed to compare C and C++
because the code is 100% C++ and so there is nothing to compare
against.

 

[Alex Vinokur]

code is more efficient and more compact than equivalent C++ code is a myth.

[snip]

Look at C/C++ Program Perfometerhttp://groups.google.com/group/perfo?lnk=sg

In this bit of code:

template <typename T>
static T templated_foo (const T&) { T t; return t; }

static int ordinary_foo (int) { int t; return t; }

Uninitialized data is returned:
q:\perfo-2-9-0--1-19\src\t_call.cpp(60) : warning C4700: uninitialized
local variable 't' used
q:\perfo-2-9-0--1-19\src\t_call.cpp(62) : warning C4700: uninitialized
local variable 't' used

I cannot find a clear answer in the C++ standard, but I think that
this may be a case of undefined behavior.

Those local variable can uninitialized as follows

template <typename T>
static T templated_foo (const T&) { T t = T(); return t; }

static int ordinary_foo (int) { int t (0); return t; }

I do not understand how this code is supposed to compare C and C++
because the code is 100% C++ and so there is nothing to compare
against.

The Perfometer is supposed to compare different construction
* in C++ (i.e., C++ vs. C++); for instance, file t_call.cpp
* in C and C++ (i.e., C vs. C++); for instance, file t_string.cpp


Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

 

[Ivanna Pee]

These days with 3ghz computers with more than 1 gbyte RAM what is so
important about elegant, efficient code?

Embedded software. Try programming a micro running at 1Mhz, with 32Kb
flash and 256 bytes(yes bytes) RAM.

 

[David Thompson]

That's true. Although C++ _also_ has builtin C-style arrays. And C++
allows (in practice, nearly demands) that methods written in the class
declaration are inlined when used, and code specialized to an inline
context often optimizes better, sometimes to nothing.

Exactly, in OO languages, you can opt to bounds check or not to bounds
check, or even both for debug/non-debug builds. With non-OO languages,
you don't have that choice. <snip>

Unless, as above, it's done in the language -- and thus the compiler.

PL/I and Ada have (standard, documented) syntax to turn on or off
certain categories of checks, one of which is array bounds.

Fortran definitely doesn't have syntax, and AFAIR neither does
standard Pascal, but I have seen compilers for each with such options.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Chris Hills]

Yes, but typically embedded processors do jobs which are utterly
trivial. Like turn on a few lights in a washing machine.

Most cars are run by embedded systems as are elevators, all industrial
plant, aircraft, ships, missiles, satellites, mobile phones,
communications systems, the internet smart cards, etc... in fact
almost anything with electrical power "near" it that is not a PC.....

I know of many embedded systems with several millions lines of code in
them

If all the worlds PC's stop it would be inconvenient. If all the worlds
embedded systems stop the world would stop and it would be fatal to
millions.

BTW since a PC is nothing but a collection of embedded systems you might
be surprised to know, last time I looked, the x86 family made up about
5% of the processors in the world... the other 95% are embedded from 8
bit to 128 bit..... The embedded world had 32 and 64 bit systems years
before they got into PC's

 

[Chris Hills]

"Typically" means there will be a few counter-examples.

There are more counter examples there you think.

 

[Chris Hills]

There are more ARM processors deployed in the world than any other
CPU.

Really where did you get that from? Last time I looked (about 3 years
ago) 30% of the worlds MCU were 8051's I know that ARM is selling well
but that is a LOT of MCU to shift to overtake the 8051 in that space of
time.