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

[Jim Lux]

At 03:29 PM 10/18/2002 -0400, you wrote:
>On Thu, 17 Oct 2002, Gerry Creager N5JXS wrote:
>
> > Strictly speaking, an accomplished Fortran programmer (OK.  I see you
> > out there.  Stop giggling!) goes through 3 phases of accomplishment when
> > learning about parallelization.
> >
>
><rgb type="rant" category="ignorable" on_topic_index="somewhat"
>affect="semihumorous">
>
>And just what does any of this have to do with Fortran?  Especially
>number 3?  Is it that Fortran programmers take two steps to get to step
>3, while C programmers already live on TJC, trust no compiler, and
>recognize that they'd damn well better learn what to do to parallelize
>code because no silly-ass compiler be able gonna do it for them?  Heck,
>C compilers won't even >>serialize<< code for you...I put instructions
>out of order all the time;-)

<monster snip of  a fine dissertation>

></rgb>
>
>Robert G. Brown                        http://www.phy.duke.edu/~rgb/

I think a lot of the discussion really centers around the question:

Is it cheaper to
1) use more faster processors and accept some inefficiency in the code
OR
2) use more programmer labor and make more "efficient" use of the processor(s)


This harkens back to the "Hand tuned assembler" vs "full tilt interpreter" 
discussion

For instance, are you better off spending an hour using Matlab  (or APL) 
and waiting overnight for the answer, or spending all night coding, and 
having the answer in 1 hour.

Or, how about debugging from core dump vs printf ...

I maintain, philosophically, that since processor power is continuously 
getting cheaper than programmer power, the trend should be to less "tuning" 
and more use of massive processing (which is what Beowulfs are all about in 
the first place, or we'd be agitating for personal Crays, right?).


BIG Exception... where there is some inherent limitation on available 
processor power, or an economic anomaly.  Example of the first: computing 
on a spacecraft for deep space.. power and size are severely constrained, 
and hence, very expensive (perhaps even of infinite marginal cost).. you 
gotta hand code, to eke out every last operation per second.

Example of the second: A university researcher, who is severely capital 
constrained, but has no fixed deadline to finish the calculation, and has 
"quasi-free" labor in the form of interested grad students who are willing 
to slave for nearly free in exchange for future, speculative glory.

In both these cases, the relatively high cost of the computer (compared to 
the labor), shifts the equilibrium back to the older, more labor intensive, 
but capital light, approach.

Jim Lux