[Beowulf] Stroustrup regarding multicore

[Perry E. Metzger]

"Lux, James P" <james.p.lux at jpl.nasa.gov> writes:
> But there's a lot of "hidden process" in building high quality
> software that the consumer (the physicist in this example) doesn't
> need to be aware of.  An engineer building a bridge needs to know
> the properties of steel, and have some understanding of how steel is
> made (so the properties of various kinds fit in a context), but does
> NOT need to know how to run a foundry or rolling mill.

True, and a physicist using computers need not understand things like
how to design processors or how to manufacture DRAM.

> Likewise, I wouldn't expect a scientist to have to know how to
> manage a software development project,

Here I disagree. The analogy is broken -- the engineer uses pre-made
steel and can just know its properties as sold. The scientist is not
using pre-made software and the way it gets made is intimately linked
to success.

The paradigm you are implicitly holding to is still one which detaches
the two fields of "computer people" and "science people", operating on
the assumption that we can have scientists that do not know computers
who are handing off requests to a computer team that does not
understand science. That is just not a recipe for success.

Tim Cutts mentioned in an earlier message that he has repeatedly
improved software performance by over two orders of magnitude and once
by seven. You don't get those sorts of fixes if everyone involved
doesn't understand what is going on. You can't just "specify" away the
issue.  You can to try to do all this as though you were writing an
RFP for real estate office management software, but only if you're
prepared to live with things being orders of magnitude more expensive
to run than they need to be, and often far less reliable and certainly
far less easy to use.

You say the scientist doesn't need to know how a software development
project works, but in the largest sense "managing a software
development project" is identical to designing software. There is no
clean distinction. Issues like whether to employ test driven design,
what languages to use, how to architect the system, and even how to
figure out what hardware is optimal for executing the architecture and
indeed how to co-select the proper hardware and software architectures
are all crucial to success.

Again, if you're building software for a real estate office it is
straightforward for the programmer to just learn what your business is
and in any case high performance isn't needed. If you are trying to
simulate supernova explosions and you can barely cram the
magnetohydrodynamics in a piss poor 2D version of the problem onto the
biggest machines in existence and would really, really like to do the
problem in 3D, I don't think you can operate on this model.

> For example, a scientist saying "you must use the PGI compiler" is
> like the bridge building engineer saying "you must use Pennsylvania
> coal in the blast furnace".

What if a particular compiler is known to generate floating point code
for certain kinds of inner loops that runs a factor of three faster
than another? Would it be silly then? The coal you use has no effect
on the resulting steel, but the compiler you use *does* alter the
resulting machine code by a lot!

By the way, I even argue that often it is important for the bridge
builder to know a bit about how the steel is made. Why? Because he
might falsely assume that certain kinds of characteristics are
impossible to achieve in the materials and thus not ask for them, and
the steelmaker might have no way of knowing that certain
characteristics would be desired by the market and thus won't offer to
sell the perfect material for the job.


Perry
-- 
Perry E. Metzger		perry at piermont.com