Re: High Precision Arithmetic Benchmarks

hbaker@netcom.com (Henry Baker)
31 Jul 1996 19:18:57 -0400

          From comp.compilers

Related articles
Re: High Precision Arithmetic Benchmarks glew@ichips.intel.com (1996-07-28)
Re: High Precision Arithmetic Benchmarks hbaker@netcom.com (1996-07-31)
Re: High Precision Arithmetic Benchmarks Terje.Mathisen@hda.hydro.com (Terje Mathisen) (1996-07-31)
Re: High Precision Arithmetic Benchmarks jgk@jgk.org (Joe Keane) (1996-08-04)
| List of all articles for this month |
From: hbaker@netcom.com (Henry Baker)
Newsgroups: comp.arch,comp.benchmarks,comp.compilers
Date: 31 Jul 1996 19:18:57 -0400
Organization: nil
References: <4svpfb$ifq@news-rocq.inria.fr> 96-07-196
Keywords: arithmetic

glew@ichips.intel.com (Andy Glew) wrote:


> Certainly, bignum add looks easy. The key is using arrays, not
> pointers, and declarations that are relatively easy to disambiguate.


There are quite a few algorithms which use 'bignums', but for which the
distribution of sizes of integers fall off so quickly that pointer
arithmetic is to be preferred to array/vector arithmetic. In these
algorithms, if you want to get fast execution, you have to make sure that
the most common case -- single precision -- is handled as fast as possible,
but allow a graceful overflow into multiple precision arithmetic.


This is one of the reasons for the Lisp Machine's emphasis on 'immediate'
integers and floats, which did no storage allocation, but which allowed for
a graceful fallback to a representation involving 'lists' of big digits.


As has been suggested quite a number of times since IEEE floating point
representation was defined, one could do the same thing with 'Not-a-Numbers',
which would encode pointers to where the real information was being stored.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.