articles on design increases performance and test first?

[deanhiller]

I have read alot on the fact that a large program could potentially run
faster in C++ than C due to the fact that it can be organized
better/designed better. I can't seem to redig up these articles.
Anybody know of some. I tend to believe that it might be possible to
always have a faster large program in C++ than C due to this. I could
be wrong, but I don't think anyone has concrete proof either way. Yes
microbenchmarks might show C faster than C++ or C++ faster than C. I
could care less about a microbenchmark that really can't tell me if my
software will be faster in C or C++.

Our current development has a huge problem in quality. I am very
familiar with OO and test first in OO. I personally think it is much
easier to have unit tests with mockobjects in OO than procedural....I
could be wrong and be showing ignorance here as I don't have much
experience there. The reason I say this is test first is done with the
Dependency Injection Pattern(formerly known as Inversion of Control
Pattern) which I am not sure can be done in C programming....Can it?

I probably have a challenge coming up that from my teams that C is
faster than C++, and personally I don't care if it is always 10% slower
if it gives our products better quality with test first.

thanks for any thoughts,
dean

 

[george.priv]

Considering that it is usually less than 1% of code where program
spends 99% of CPU time, choice of C++ comes easy. When it comes to
that 1% one can simply avoid costly features or stick with C
functionality.

George

 

[Walter Bright]

I have read alot on the fact that a large program could potentially run
faster in C++ than C due to the fact that it can be organized
better/designed better. I can't seem to redig up these articles.
Anybody know of some. I tend to believe that it might be possible to
always have a faster large program in C++ than C due to this. I could
be wrong, but I don't think anyone has concrete proof either way. Yes
microbenchmarks might show C faster than C++ or C++ faster than C. I
could care less about a microbenchmark that really can't tell me if my
software will be faster in C or C++.

I've had some interesting experiences in trying to get programs in various
languages to run faster. The first place to start, of course, is picking a
fast algorithm. But often it doesn't become apparent if an algorithm is fast
or slow until after the program is built.

So a significant characteristic of a language that is performance oriented
is that it be easy to revise the algorithms implemented in it. A language
that is hard to revise an algorithm in I'd term "brittle", at the other end
would be "elastic". Isn't it odd that while most programmers would agree
that algorithm selection is the most important aspect of optimization, the
characteristic of "brittleness" or "elasticity" doesn't come up that often
in discussion of programming languages? When most programmers think of a
performance oriented language, they think of its low level
micro-optimization capabilities, rather than it's higher level elasticity.

I've written lots of projects, large and small, in assembler, C, C++, and
the D programming language. How do they fare in terms of elasticity?

Assembler has the most potential for micro-optimization, but any large
program in assembler is pretty well algorithmically cast in stone. I know of
an assembler implemented in assembler that is incredibly slow - it uses a
linear symbol table. But once you carefully micro-optimize the code, hand
schedule the instructions, etc., it becomes too expensive to even think of
changing the algorithm. Assembler is the most brittle language, and so
counter-intuitively one can wind up with pretty slow programs in it.

C, of course, is a huge step up from that. But it's still very brittle. How
many large C programs do you know of where it was possible (or in fact, if
anyone had) reimplemented fundamental algorithms in it for speed? C doesn't
have good modularization and abstraction capabilities, so dependencies on an
algorithm tend to be distributed throughout the program in subtle ways.

C++ does better. With OOP and templates, it gets more elastic. But I've
still found it to be resistant to algorithm rewrites. The problem is usually
traceable to explicit memory allocation. Always having to keep track of
memory ownership means that an implementation of an algorithm tends to
insert its tentacles all over the place.

I've had much better success with the D programming language, because D has
C++'s OOP and template features, but has automatic memory management
(garbage collection). Garbage collection is needed to make really reusable
and replaceable algorithms. Many languages share D's flexibility by also
being gc languages, so they make it easy to reimplement algorithms. (Is it a
coincidence that one of Java's strengths is its vast panopoly of libraries?
I don't think so.) Where they fall down, though, is that once one has the
algorithm right, there's no way to do the micro optimization. D retains
C++'s ability to micro-optimize, and even adds to it with support for inline
assembler.

I've done a complete rewrite of one large project (DMDScript, a javascript
compiler/interpreter) from heavilly optimized C++ into D. I was able to get
it to run faster in D - not because any detail of D produced better object
code than C++, but because it was easy to make changes to the algorithms and
try out different ways. I then micro-optimized that result.

Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Bob Hairgrove]

I've had some interesting experiences in trying to get programs in various
languages to run faster. The first place to start, of course, is picking a
fast algorithm. But often it doesn't become apparent if an algorithm is fast
or slow until after the program is built.

An algorithm can be, and should be, analyzed independently of the
implementation and/or programming language. But it is possible that
one algorithm, which is not obviously vastly inferior to another,
could perform better than the supposedly superior algorithm depending
on various optimizations of implementation. Choice of hardware and OS
are obviously factors as well. And then there is the distribution of
data -- for example, how the data is layed out statistically can
dictate the most appropriate sorting algorithm.

For best performance, algorithms should be "pluggable" (i.e. Strategy
design pattern).

So a significant characteristic of a language that is performance oriented
is that it be easy to revise the algorithms implemented in it. A language
that is hard to revise an algorithm in I'd term "brittle", at the other end
would be "elastic". Isn't it odd that while most programmers would agree
that algorithm selection is the most important aspect of optimization, the
characteristic of "brittleness" or "elasticity" doesn't come up that often
in discussion of programming languages? When most programmers think of a
performance oriented language, they think of its low level
micro-optimization capabilities, rather than it's higher level elasticity.

Exactly, and brilliantly said IMHO.

I've written lots of projects, large and small, in assembler, C, C++, and
the D programming language. How do they fare in terms of elasticity?

Assembler has the most potential for micro-optimization, but any large
program in assembler is pretty well algorithmically cast in stone. I know of
an assembler implemented in assembler that is incredibly slow - it uses a
linear symbol table. But once you carefully micro-optimize the code, hand
schedule the instructions, etc., it becomes too expensive to even think of
changing the algorithm. Assembler is the most brittle language, and so
counter-intuitively one can wind up with pretty slow programs in it.

C, of course, is a huge step up from that. But it's still very brittle. How
many large C programs do you know of where it was possible (or in fact, if
anyone had) reimplemented fundamental algorithms in it for speed? C doesn't
have good modularization and abstraction capabilities, so dependencies on an
algorithm tend to be distributed throughout the program in subtle ways.

C++ does better. With OOP and templates, it gets more elastic. But I've
still found it to be resistant to algorithm rewrites. The problem is usually
traceable to explicit memory allocation. Always having to keep track of
memory ownership means that an implementation of an algorithm tends to
insert its tentacles all over the place.

Have you had a look at the Strategy pattern (GoF)?

 

[Walter Bright]

An algorithm can be, and should be, analyzed independently of the
implementation and/or programming language. But it is possible that
one algorithm, which is not obviously vastly inferior to another,
could perform better than the supposedly superior algorithm depending
on various optimizations of implementation. Choice of hardware and OS
are obviously factors as well. And then there is the distribution of
data -- for example, how the data is layed out statistically can
dictate the most appropriate sorting algorithm.

For best performance, algorithms should be "pluggable" (i.e. Strategy
design pattern).

True. But I tend to adopt the iterative style of development, which means
that what the algorithms are and where the "pluggable" lines need to be
often isn't clear until after the program is developed. But even with best
efforts, some things remain brittle.

For example, in C++, suppose I want to change a type used all over the place
from being a value type to a reference type. I've got two problems that
pervade the uses of the type - changing all the dots to arrows, and then
trying to retrofit a memory management strategy. I've got fewer problems
here with D, since member access for both reference and value types is dot,
and with gc, memory management is much less of a problem.

For another, consider the lack of an 'auto' declaration type (though this
will be fixed in C++0x).

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers