[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: 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.
Well, there is some truth in that, but I have extensive experience of
having such problems brought to me, reporting them to vendors,
adjudicating between vendors and users, and even advising vendors. In
Fortran, 85% of the time, there is a clear user or vendor error; in C
and POSIX, that is only 15% of the time.
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.
It isn't true for Fortran, and isn't for other languages - but I know
of few that do even as well as Fortran does (and perhaps only Ada).
C99 is merely an extreme case, with its appalling inconsistencies.
Or are you holding up Java as an example to be followed?
That isn't the point. What is the point is whether defining a set of
machine-code operations with bitwise-consistent semantics, and stating
that a language must define a canonical mapping into those, is the right
way to proceed. Fortran's disagreement should not be discounted, as
the cumulative experience and record of success of the Fortran community
(in this area) are probably larger than those of all other communities
combined.
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.
No - not merely does C99 not `standardise' IEEE 754 support in a way
that makes it useful in practical programs, even the base language of
C99 (i.e. without __STDC_IEC_559__) conflicts with many other, existing
implementations. Perhaps even worse, C99 is seriously incompatible
with C90 in this area.
Have I posted my ghastly example of how you have write a semi-portable,
semi-robust numeric code in C99?
"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.
I don't know what the author or Malcolm meant by that, but I read it
to mean that whether replacing (1+1) by 2 counts as an optimisation
or pessimisation is machine-dependent. And it is. Some architectures
have special operands or registers for the value 1. I have optimised
code by replacing 'load 2' by 'load 1' + 'add 1'.
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.
And, while it does not say so explicitly, it assumes a C-style abstract
machine, not a Fortran-style abstract model. I can think of languages
in which it would make even less sense (e.g. Prolog).
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.
It's been done. It's one HELL of a lot better than most languages.
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.
Or, far more likely, prefer identical results to correctness. Was nobody
else on this list active during the days when people were trying to get
IBM to improve their appalling transcendental functions in the 1970s?
Over a decade of badgering, often donating VASTLY improved code, and
with no effect - until Gustafson's work (primarily called for Fortran)?
Over the decades, I have lost count of the number of new boojums I have
asked developers whether they have fixed defect X in, to be told "we
did in the prototype, but marketing insisted on absolute compatibility."
That is, after all, the real reason that most people object to trapping,
even for the most serious errors, like division by zero and integer
overflow; they don't want to be forced to face up to the fact that their
results are meaningless.
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.
Almost entirely the latter. The reason that Fortran does VASTLY better
than C is because its fundamental design is so much more parallel
friendly. You can add features on to Fortran and parallelise it,
without breaking most serial code and without busting a gut. You can't
even start in C. Look at the differences between OpenMP Fortran and
OpenMP C/C++ for evidence.
I have spent a lot of time thinking about this over the years, and I
believe that you could produce a fairly traditional 3GL with good
parallel support that would be easier to debug than even a language
like Python. Its ancestry would be from Algol 68, Fortran, Ada and
(yes, seriously) SNOBOL, if I designed it. But I have failed dismally
to think of any way I could design one that would be less than utterly
evil to tune.
Almost every new language that 'integrates' parallel processing has
used the same, sick model - similar to POSIX threads. This is not the
place to describe the conceptual errors in their designs. If anyone
can point me at a competently designed one (i.e. from a engineer's
viewpoint), please do - I haven't seen one.
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