C++ programming (was Newbie Alert: Beginning parallel program ming with Scyld)

[Robert G. Brown]

On Wed, 16 Oct 2002 graham.mullier at syngenta.com wrote:

> compiler writers can no doubt correct me but I'm reasonably convinced that
> in many cases Fortran (77 rather than 90 or later) is sufficiently limited
> in the language constructs possible that the compiler is better able to
> optimise the code. That's better than a random sample of code written in,
> say, C, not code written really carefully knowing exactly how the compiler
> will map code onto the underlying hardware architecture.
> 
> (hitting send during one of these debates feels a lot like lighting the blue
> touchpaper and retiring...)

No, your point is well taken, and is, I think, what Mark and others were
saying but it should be still more general.

Different compilers are suitable for different kinds of tasks, and even
now it could easily be that fortran, written a certain way, e.g.
vectorizes better than C.  For one thing, C programmers (really speaking
only for myself, not necessarily ALL C programmers:-) tend to use
pointers a lot because we tend to use dynamic allocation of memory a
lot, and use this dynamic memory in lots of "interesting" ways to build
data structures (such as linked lists, trees, arrays of structs) that
defeat certain kinds of optimization, which like to be able to presume
that an array starts on a given index, is a given size, and can be
unrolled in a certain way to give optimal performance.  Even the single
layer of indirection represented by dereferencing a pointer (set) to
which you have dynamically malloc'd some sort of vector or array costs
you a few percent in raw speed of large vector operations relative to
the same vector or array statically allocated.

However, this can be written as "advantage/disadvantage" both ways -- I
can do very clever things in C that optimally conserve e.g. memory or
give me a very intuitive mapping between my data objects and their
references in code.  C can save me a LOT of time coding relative to
fortran, and with a bit of care regarding what and how it translates my
code into machine language one can be quite efficient as well.  I've
heard C described as "a thin veneer of platform independence established
between a programmer and the system they are programming for" and this
is actually not a bad description.

All languages have similar tradeoffs.  C++'rs often wish to minimize the
time they spend developing and maintaining code, but generally give up
the totality of access to their own data structures that is explicit in
C (at least if they are following the religious doctrine -- donning my
OWN asbestos suit:-).  Fortran is gangbusters for semiliteral
translation of math to computer (the purpose for which it was designed)
but tends to suck just a bit (my own opinion, mind you) in matters like
data structure flexibility and I/O -- where it has improved over the
years primarily to the extent that it has copied constructs from C.
Pascal persons (presuming that they still exist:-) love "discipline" to
the extent that I don't want to see inside their bedrooms.  APL is
lovely for doing matrices.  APL kinda sucks for doing things like
programming mastermind, which is the last big program I did on it (on an
IBM 5100) back in 1979 or so.

Before the OO vs procedural debate starts, it is worth pointing out that
OO programming (or not) is more a matter of programmer style than it is
elements of a language, although some languages certainly have better OO
constructs than others.  In C, sometimes I program in an OO fashion, at
others procedural.  I'm certain that C++ programmers do the same thing,
as not all programs are suitably cast in terms of "objects", especially
if you want to run efficiently.  I'd guess that by f90 one can even do
"OO" programming and work with pointers should the need arise, although
I passionately hope to never have to find out.

For the most part, programmers tend to learn a bunch of languages over
the course of a career and select one (or more) that particularly suit
them and get very good at using them.  They then tend to defend their
choices against those made by OTHER good programmers who made different
choices (for no particularly good reason, unless they are working on a
project together and trying to decide what to use).

That's why I did the "arr, matey" thing -- this particular debate has
been had so often, in so many venues, that it is a predictable war with
no useful resolution, and hence a good thing to poke fun at.  Basically,
it is nearly useless to promote any language over any other language
EXCEPT in the specific context of a specific advantage of a specific
language in application to a specific problem, and even then you're
certain to encounter disagreement.

With respect to beowulfery and parallel programming, I think that there
is no particular disadvantage to using any language that can link to the
primary parallel IPC libraries (e.g. PVM or MPI) or manage raw sockets
if the programmer has thick meaty arms and a hormone imbalance (or
particularly good reusable socket code handy and a lot of experience
using it:-).  Sure, one language might be marginally more efficient than
another in THIS particular problem using THIS particular library, but so
what?  The real cost is almost always the time it takes to code and
maintain, and this will clearly be minimized if you use your favorite
language instead of learning a new one (in which you will, inevitably,
suck for weeks to months).

> -----Original Message-----
> From: Robert G. Brown [mailto:rgb at phy.duke.edu]
> Sent: 15 October 2002 19:37
> 
> (ex-APL, ex-PL1, ex-Basic, ex-Fortran, ex-Pascal coder,
> ex-etc-that-I've-forgotten and then we start on scripting languages...)
> 
> wot, no Algol? Lisp? Lex/yacc? And shouldn't that have been FORTRAN rather
> than Fortran, or are you one of those latter-day F-90 chaps rather than F77
> or earlier...?

No algol, but formac, macsyma, and a few others.  No yacc.  No lisp
(thank god!).  And the fortran was FORTRAN IV: column 1 for
continuation, cols 2-6 for labels for all those gotos, cols 7-71 for
code, cols 72-80 for card lables, and yes, this was on punch cards where
the labels were very useful should you drop your 1000+ card deck.  Which
I did once, although fortunately not in the rain.

Pointers?  Case switches?  Simple I/O?  Hell no, give me Hollerith,
baby, and DO 10 I = 1,10... 10 CONTINUE every time...;-)

When I learned C in the early 80's somewhere (from the de Smet C
compiler, for any really old persons out there:-), I never looked back.

   rgb 

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