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) |
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.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.