C++ programming (was Newbie Alert: Beginning parallel program ming with Scyld)
James.P.Lux at jpl.nasa.gov
Fri Oct 18 15:31:58 PDT 2002
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"
>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>
>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
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"
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.
More information about the Beowulf