Performance Performance Performance (was: pi and LIA)

[Samuel A. Figueroa]

In a previous message, dghavalidgh.com (David G. Hough at validgh) wrote:
  >A useful arithmetic standard to address these current problems in computer
  >arithmetic would prescribe the DEFAULT:
  >1)	expression evaluation: what happens when the language does not
  >	specify the order of evaluation of (a op b op c), or how mixed-mode
  >	arithmetic is to be evaluated, or the precision of variables in
  >	registers or storage, and related issues.
  > ...
  >Thus conforming implementations built upon
  >IEEE 754 arithmetic would provide identical
  >results for identical types; identical conforming implementations upon VAX,
  >IBM 370, or Cray arithmetic would provide identical results among their
  >brethren, and any discrepancies would be immediate evidence of some kind
  >of hardware or software problem instead of "normal roundoff variation".

I see three possibilities: define a default mode that favors RISC-based
workstations, but that would perform quite poorly on IBM-compatible PCs,
which are more numerous.  (Maybe in the technical marketplace as well?
I don't know.)  Or define a mode that favors IBM-compatible PCs, but is not
optimal for RISC-based workstations.  Or define a mode that is not optimal
on IBM-compatible PCs or RISC-based workstations.  If one is running a
floating-point intensive application, which of these choices is the best?

In a previous message, uunet!sdiv.cray.com!tamauunet.uu.net (Tom MacDonald)
wrote:
  >Jim Thomas has written an excellent document on floating-point C
  >extensions.  He has carefully separated strict IEEE conformance from other
  >floating-point concerns.  I wonder if attempting a two tier approach is
  >appropriate?  A vendor might have concerns about testing and supporting
  >multiple environments (though most vendors have a strictly Standard C
  >mode) but it lends itself to the "experiment your brains out" mode and
  >"portability is on the pedestal" mode.  We still need the hardware
  >engineers to provide a reasonable implementation to a strictly
  >portable mode.

Perhaps my following comments reflect my lack of experience doing actual
numerical computing.  The one criticism I would have of Thomas' document is
that if one happens to be on a platform that is not IEEE-compatible, this
document is not very helpful in determining if an algorithm will work on that
platform.  I guess I would like to see a three-tiered approach:

1) A performance-oriented mode (maybe the default?).  It should still be
   possible to establish (possibly pessimistic) error bounds.  This mode
   might be the only mode available on some (performance-oriented) computers.
   Dare I suggest that the LIA-1 might provide inspiration for describing
   the behavior of this mode?

2) Languages, or at least their implementations, ought to provide access to
   the underlying hardware's capabilities.  With respect to IEEE-conforming
   floating-point engines, Thomas' document is such an attempt.  That way,
   if a particular algorithm works only if a particular operation is performed,
   say, according to the specifications in the IEEE Standard, there will be
   a way to point this out to the language translator.  Most of one's program
   might run in mode 1) above, but the computer could "slow down" for the
   critical parts of the algorithm.  A good numerical analyst should be able
   to determine what those critical parts are, and code them appropriately,
   if the means to do so were provided.

3) A portable mode, such as Hough advocates above.  This can be useful for
   debugging a program, if for nothing else.  Another use for this could be
   in running different parts of a program on different machines networked
   together.  Whether this should be the default mode is not clear to me.