[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Clause 10, Expression Evaluation
"William Clodius,,," <wclodius@xxxxxxxx> wrote:
[ A large amount that I agree with, but can see no point in following
up. The following are a few niggles, which actually strengthen his
points. ]
Ok,you may rant that you are talking about number crunching with
parallel processors and supercomputers where only FORTRAN is
an option. Well, I will answer to that later.
Error of fact. That performance gains are only for those systems.
Memory hierarchies in todays desktops have affects on performance
similar to that of the hierarchies of the supercomputers of ten to
twenty years ago.
As I hope that we all know, medium-scale parallelism is coming to
personal computers within the next 5 years - which is surely within
the lifetime of IEEE 754R, unless it is still-born!
When someone challenges a quote chances are he has it right. Your
response was actually posted as a response to a message by Nick
MacLaren who did use the word "furthermore" followed by something
that (roughly) implies "it is not useful". ...
As people have commented for many decades, my use of English is
fairly distinctive :-)
So the inherent inability of FORTRAN
to come up with a strict evaluation order is apparently not the
reason he came up with this image.
The reference to "inability" is an error of fact. Fortran could
decide on an evaluation order, without changing the "defined"
semantics of existing code, but has chosen not to for performance
reasons. ...
Grrk. Not JUST performance reasons. It would be a foully complex
task, leading to a specification that would be incomprehensible to
most programmers, for a very dubious gain.
Even ignoring parallelism, specifying the precise order of the
evaluation of the finalization of the elements in a complicated,
pointer-based graph is a non-trivial task - most especially if
it has to be the same order in all implementations!
James R. McGraw has written an interesting paper named
"Parallel Functional Programming in Sisal: Fictions, Facts
and Future", Advanced Workshop: Programming Tools for Parallel
Machines, July 1993.
In this he ran Sisal solutions against FORTRAN ones on a Cray
YMP/864. While in single processor mode FORTRAN was faster, it
looses dramatically against Sisal during multi-processor mode.
He also explains what he is doing in the first-place so that
Sisal can achieve its speed.
... Are you certain
that the code generated by Sisal consistently imposed deterministic
floating point semantics? FWIW during most of Sisal's active period
it relied on C code compiled using gcc, gcc was largely a K&R
compiler, and K&R C had looser floating point semantics than Fortran
and C89.
One can argue whether C89 (or C99) is specified closely enough
to determine even whether a non-trivial program is legal, let alone
whether it will produce a deterministic result. Even if Sisal was
a gcc-only language, I have my suspicions that there would be a lot
of variation between versions of gcc.
Furthermore(!), none of the Cray YMP systems are at all typical of
most parallel computers, and the applications run on them are even
less so. It is certainly true that SOME applications can be run
in parallel to give efficient, deterministic results - but it is
also true that some can't, for fundamental reasons.
I can send the paper on interest.
Are you the copyright holder, or are you certain of the distribution
restrictions imposed by the copyright holder?
That was why I did not ask for a copy. If I could be sure that the
copy was kosher, I would be prepared to look at that paper, but am
not inclined to spend a lot of time on chasing it up.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@xxxxxxxxx
Tel.: +44 1223 334761 Fax: +44 1223 334679