[Beowulf] C vs C++ challenge

Robert G. Brown rgb at phy.duke.edu
Wed Jan 28 13:55:42 EST 2004

On Wed, 28 Jan 2004, Cristian Tibirna wrote:

> And once again C++ fills the expectation here, IMO. Paraphrasing you: "This 
> works just marvey... with C++ exactly because any... entity they need to sort 
> and the sort criterion can be fed to the subroutine successfully and the 
> subroutine will happily work with". This, of course, thanks to C++'s 
> templates. And the result is even highly readable and quite compact usually 
> (and this is the reason I am ready to cope with performance penalties, 
> because I can put out code 10-20 times faster than in C -- OK, this is a 
> subjective measure -- and that code will only run 2-3 times slower -- citing 
> another poster "that's what clusters are for" ;-).

Well, let's get serious here.  A cluster is a large and costly
instrument.  You don't really mean that you are willing to waste 1/2-2/3
of the practical capacity of up to a million dollars worth of hardware
by writing in C++'s generic objects in order to save a few weeks of
writing truly efficient code in C.  That makes no sense from a CBA point
of view -- especially when it requires one to purchase 2-3x as many
nodes to get the same time of completion of the job OR requires the
project to run 2-3x as long (3 year instead of one, for example).  You
can write and debug a hell of a lot of C code in a year.  You can also
avoid being burned in effigy by competing groups wanting access to the

Everything else you say, well, that's just precisely the attitude of
many C++ programmers and teachers of same and is perfectly OK with me.
In fact, it is the attitude of most perl and python coders as well --
why bother with all the overhead of a compiler when you can have
run-time checking, dynamically self-rewriting code (there's a clever
perl trick -- code that writes itself!) threads and more, especially
string parsing and regular expressions in conditionals), and never have
to actually manage memory at all?  For many tasks they are only a few
times slower than compilers (they effectively tokenize/"compile" and
then run library calls just like a compiled program) but they can make
developing various classes of applications must faster.  In fact, if I
were to actually want to write a word counter to parse stdin (where I/O
is already a rate limiter and speed is irrelevant) I'd almost certainly
use perl myself, just as others (who like a more OO interface) would use
python.  Neither perl nor python is suitable for use on a beowulf to do
real work; C++ doubtless is, but only if it is used "correctly" so that
parts and data structures that need to be in plain old C for reasons of
efficiency are.

This is why I'm ecumenical, however strong my own prejud-- I mean
"calmly reasoned and wise opinions":-).  There is a spectrum of
languages, and there are tradeoffs on ease of use and encapsulation
across the spectrum.  As computers get ever faster and larger, the
overhead cost associated with using interpreters and higher-level
languages and libraries goes down not in relative terms but in absolute
ones, often to the point of irrelevancy.  Notable exceptions include
HIGH PERFORMANCE COMPUTING (the principle topic of this list:-) where
performance is a PRIMARY focus, and a whole variety of tasks that tend
to be studied by computer scientists because of their unfavorable
scaling properties and consequent large demands on whatever system is
running them.  

These categories are far from static as Moore's Law does its thing --
the reason PL/1 is a vanished language is in part because it WAS a
high-overhead language for its era (IBM mainframe computing) and the
resource it wasted (CPU time at truly exorbitant rates) was EXPENSIVE.
The fact that the compiler would take monkeytype and turn it into SOME
sort of program with its syntax error correction probably didn't
help...given that one paid for the bad runs along with the good.;-)
Also, Real Computer Scientists work out algorithms and port code and
turn it into a library routine and suddenly a difficult problem DOES
have a pretty good and even efficient solution in a given
language/library.  And then there is ATLAS, where the library isn't just
good, it is dynamically self-optimizing.

So by all means, seek your own comfort level, and optimize tradeoffs in
accord with your own abilities and needs...

> Lippman's "C++ Primer".
> Thanks for listening.

Thanks for the pointer to the book.  I'll give it a look next time I'm
in B&N.


Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu

Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

More information about the Beowulf mailing list