[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
once was: a question about formatOf operations
The "literal meaning" is what programs get, full stop.
Barring software and hardware faults of course.
Who's to say that any particular behavior represents a fault?
Certainly not a language standard that won't define arithmetic.
And indeed some vendors (hardware and software) seem to
like to keep floating-point arithmetic as difficult as possible so that
any issues with it can be blamed on the user, who is apt to know less and
less about it as time goes on.
Whether or not this is right tradeoff for Fortran users,
it certainly isn't for many other languages.
Optimized code may well deviate from the "literal meaning" due to the
difference between floating-point arithmetic and real numbers.
In my experience programs without optimisation also use floating-point
arithmetic that differs from real numbers.
That is correct. What I should have said was that "optimizations that would
not change the values of real numbers from the literal meaning of the source
code might change the values in floating-point arithmetic"
Fortran is not about standardising computer arithmetic, it is about
standardising a programming language. Limiting a general programming
language to one particular computer arithmetic does not seem like an
obviously good thing to do.
Didn't C manage to allow standardized 754 implementations of C without
excluding non-754 implementations of C? That's all that's required.
"There is no such thing as a "machine-independent" optimization!
Not one! People who use the phrase don't understand the problem!"
It's hard to see how replacing (1+1) by 2 could fail to be an optimization
on any plausible machine with integer arithmetic. Moving to floating-point
arithmetic, there are still at least some fairly easy cases, but many
which require knowledge of target hardware to decide e.g. what's the best way
to
compute x+x or 2*x.
So the optimization directives recommended in 754R are in the nature of
licenses: they license an implementation to perform all or a particular
value-changing optimization if the implementation deems it advantageous.
I think that the confusion here is that David Hough is assuming that
the "literal meaning" is what would happen if the code were interpreted
by a C-style, machine-code-level abstract machine. I.e. the semantics
of the language are specified in such terms. That is why I said that
it makes some sense in C.
754R recommends that languages define a literal meaning and require
implementations to provide it. That it be the default is a separate
recommendation. Languages might define such a literal meaning for 754R
implementations without excluding a different level of conformance from
other implementations.
I believe that one person implemented a Fortran 77 compiler that used
fixed-slash arithmetic for reals, but I never tracked down whether it
had actually been done (and, if so, finished). There was certainly
no reason why not, because that is an equally good approximation to the
mathematical reals, and there are some very good reasons to prefer it.
There might be some very good reasons why not: it might be very hard to put
into fast pipelined hardware, and whatever they might feel at other times,
when they want to go really fast, Fortran users really want to go fast.
Computing cn/cd = an/ad + bn/bd seems apt to remain expensive compared
to normal floating-point addition hardware.
Symbolic algebra systems are another matter entirely, and efficiency is measured
rather differently, since often only exact results from exact initial
data are interesting.
I can't imagine that Fortran would be a particularly congenial environment
to integrate support for symbolic algebra.
There were definitely compilers that produced code for IBM PCs that
ran with a variety of coprocessors, and they mostly had differences in
their arithmetic.
Nowadays the main x86 implementations are Intel and AMD, and as far as I know,
in their common instruction sets
they only differ numerically in their transcendental function cores,
which are equally good but slightly different and could be avoided if one
preferred identical results to maximum performance. The latest instruction
set extensions are sometimes not quite common but tend to converge over time.
The OpenMP people would disagree with you, but your colleagues that use
it (and I) would not! OpenMP is pretty bad, hard to use (and EXTREMELY
hard to debug, tune and support), and is the BEST of the bunch.
How much of this is due to its nature as an add-on rather than an integral
part of the language? And how much is due to the general fact that parallel
programming is hard? Brand-new languages nowadays often try to integrate
parallel processing.