[Beowulf] Re: the comparison between OpenMP and MPI
Peter St. John
peter.st.john at gmail.com
Mon May 21 12:42:24 PDT 2007
These points are well-taken but I'd like to defend "naive compiler faith" a
The a-priori job of the compiler, translating n-GL to (n-1) GL, can be
reliably correct. A sufficiently expressive programming language will have
to have some possible expressions which are not, but for most use the
equivalent of eculidean geometry is just as reliable. But there are (at
least) two ways that actual compiler (implementations) disappoint us:
1. Warnings. That used to be a separate job, as when C Beautify was an app
we ran before CC. There is no limit to what we could like a computer to warn
us about, that can't be in the scope of provable correctness. When "cc
foo.c-o foo" returns "You don't have time for this, you're late for
will be really cool :-)
2. Optimizations. A literal optimization does something like maximize the
value of success in proportion to the cost of failure; so literally the
optimal solution to a problem may have bugs, because the cost of sporadic
bugs is smaller than the cost of avoiding them. An example would be the test
"if fopen()..." which may just waste a microsecond every call, in the
context that fopen() always succeeds unless the hard drive fails, when
everything would fail and there would be no value catching it at that point
in your app. A more theoretical example is probablistic primality; you can
spend tiny time getting a number that is almost certainly prime, and use it
in cryptography with very high (but not certain) safety. Or, you can spend
years of CPU time proving the number is prime first. The optimal solution
for most applications is to use the "buggy" probabilistic prime.
Surely some compiler suites provide cosier warnings (for your needs) and/or
better optimizations, and more reliable optimizations, but it's just the
strictly-compiling job that I (still) think of as highly reliable.
But the point is well-taken, I've been lucky to only need very few explicit
registers deep in nested loops, so I've never had to worry much about how
the compiler copes when availability is exceeded (although it's imaginable
to me that wrapping around could be desired behaviour but that would have to
be documented). You guys bang your machines pretty hard, I'm humbled.
On 5/21/07, Toon Moene <toon at moene.indiv.nluug.nl> wrote:
> Florent Calvayrac wrote:
> > Without optimization no registers were used so the code was giving
> > correct results and at O1 code was optimized on a line per line basis
> > and not procedure-wide.
> > So even commercial code can be wrong...
> As a former boss of mine put it, some 25 years ago: "You think the
> compiler is perfect ? Hah, it's just another large program with its
> own bugs !"
> Toon Moene - e-mail: toon at moene.indiv.nluug.nl - phone: +31 346 214290
> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
> At home: http://moene.indiv.nluug.nl/~toon/
> Who's working on GNU Fortran:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beowulf