-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of David
Hough 754R work
Sent: Wednesday, July 11, 2007 8:20 AM
To: stds-754@xxxxxxxxxxxxxxxxx
Subject: Re: Languages, languages ... (was: 754R and Reproducibility)
No, this is intentional. Too much of 754 was specified at a
level that
could not be used by the intended target, which is
developers of PORTABLE
libraries and applications, rather than developers of
machine-specific
software, including compiler implementers. The latter class
is indeed
important to system vendors, who are well advised to provide all the
low-level elements needed to build a conforming implementation... for
the benefit of their compiler implementers and systems
software people --
but they shouldn't expect ISV's to be much interested.
I should clarify that I meant mathematical software ISV's here,
who generally want to build applications portable to all
important platforms...
developed as quickly as possible (in higher level languages,
with little gratuitous delay due to porting
problems) and that run as quickly as necessary (some are willing to
sacrifice some performance for portability, others aren't).
On the contrary, system vendors (by which assume we mean vertically
integrated vendors that produce hardware as well as the software that
runs on it) benefit from the bundling, assuming they are not interested
in selling the hardware unbundled. (Please note that this is
a personal
comment and may not reflect IBM's position.) That's because it offers
flexibility about where to provide the support for conformance.
Indeed, the essence of system architecture is determining where
to implement
in hardware and where in software. This is a complicated
tradeoff that
has led to varying choices: should division and sqrt have
hardware support?
The advantage of an integrated system vendor is that it can keep some of
those interfaces private and thus malleable as systems change.
In principle,
more often than in practice, such flexibility should lead to a
competitive
advantage compared to systems that integrate layers from
different sources
with necessarily more fixed boundaries of functionality. The
competitive
advantage of the latter approach is that fixed boundaries allow multiple
sources of components leading perhaps to a cost advantage.
But how much internal interface somebody wants to document for internal
or external consumption is an individual choice. Most mathematical
software providers don't want to know about internals and resent having
to learn so much to get portable performance now. So 754R should keep
its focus on the programming environment, which makes it a kind of
meta-standard for languages that choose to support it.
fact, this may well apply to ISVs too, which after all operate on many
different levels as well: some provide operating systems (and
depend on
the properties of the hardware), and some provide compilers
and run-time
environments (and depend, in addition, on the underlying OS).
These are
vendors that *provide* IEEE 754R support at the language
level. What can
they assume from the underlying levels on which they depend?
This kind of support is inherently platform-dependent and very
important,
but what does it have to do with 754R?
compiler developers would be stymied. The IEEE 754(1985)
standard had the
effect that vendors *did* supply the programming details
necessary to do a
complete 754-conforming job, and I gave some examples of how
IBM did this
nine years ago.
That's the 754 problem right there: ISV's who didn't want to
know had to learn
about platform-specific implementation features.
So -- what do I mean by a language-independent specification?
For most operations, the standard specifies a certain function
that is to
be performed. An implementation would be conforming if it
documented the
means of achieving this: it could be a single instruction, or
recipe for
combining instructions into a function that performs the complete job.
I think this is encompassed in 754R now:
"Because this standard requires facilities that are not
currently available in common programming languages, such
languages might not be able to fully support this standard if
they are no longer evolving themselves as standards. If the
language can be extended by a function library or class or
package to provide a conforming environment, then that extension
should define all the language-defined behaviors that would
normally be defined by a language standard."
A system-vendor programming interface at a very low level would be
conforming here. It just wouldn't be of very wide interest.
The system vendor gets to define all the language-defined stuff:
"IBM System Z 754R Programming Environment" would be completely
conforming
and a hot item for the few with a need to know,
and of no interest to everybody else. What it might have in
common with
the "UltraSPARC 754R Programming Environment" and
"IA32 754R Programming Environment" would be kind of hard to usefully
standardize, I think.
As far as parallelism is concerned, the same should be done for
at least OpenMP Fortran (probably the most widespread shared-memory
paradigm, and certainly one of the best defined). While I believe
that it might be feasible, I believe that the effect would be to
eliminate the usefulness of many OpenMP facilities.
In terms of number of floating-point programs in the world
today, I suspect
Excel vastly exceeds OpenMP. Most Excel programmers would be
far better
off with decimal floating point arithmetic and reproducible results than
what they have today...
In terms of number of IMPORTANT floating-point programs, though, measured
by number of fp ops executed per day or economic value at stake, I would
still expect OpenMP to win for a while.
I don't expect OpenMP programmers to ask for
reproducible results except perhaps during preliminary debugging stages.
But the presumption is that they will be experienced enough to be
able to debug the programs they finally produce.
More generally, the challenge in computer science is to find a
way to debug
programs that exploit massive concurrency - possibly on heterogeneous
computing elements - and the most effective way to solve such problems is
to engineer them out of the way as much as possible by effective
higher-level
language design. (Hence 754R's emphasis on language definitions.)
When it's not possible to engineer them away,
the first step at least is to get the program debugged in a
reproducible mode. Floating-point programs have the
additional challenge
of gratuitous platform-specific variations in results even with no
parallelism. Expecting most programmers to be able to debug programs
with variable behavior due both to parallelism and
floating-point variations
seems to be asking a lot. It should be possible to disable both of
these sources of confusion first, then enable them one at a time when and
where needed.