Re: Fast floats

[bill@cambridge.apple.com (Bill St. Clair)]

At 11:09 AM 9/22/93 +0100, Arnoud Verdwaald wrote:
>Hi,
>
>I am having a bit of a problem speeding up computation for floats. Recently
>there have been some demonstrations from contributors of this group how to
>get runtime down rather dramatically for fixnums.
>How about floats? Things seem to be all right for short-floats

MCL will do in-line computations for arithmetic on declared fixnums and
for simple list operations on declared lists and conses. It never in-lines
floating point computations. They always go out-of-line to the generic
arithmetic code. Hence, declaring variables to be a subtype of float
will not effect the generated code.

Short floats help if they have enough dynamic range and precision for
your application. They help because they are stored as immediates, hence
they require no consing. Double floats (same as single floats in MCL)
are always consed. Every arithmetic operation on double floats conses
a double float result (8 bytes). This causes (double) floating point code
to spend lots of its time in the garbage collector.

Creating an array with an element-type of short-float does nothing.
You'll get a general array that can hold any type of object.

Creating an array with an element-type of double-float (or single-float)
does have an effect. The 64 bits of each double float entry are stored
directly in the array rather than storing a double-float tagged pointer
to 64 bits as would be done in a general array. This has two important
properties:

1) A double-float array uses 2/3 as much storage as a general array.
   A double-float array requires 8 bytes per entry.
   A general array used to store double floats requires 12 bytes per
   entry (assuming that none of the entries are EQ to other entries).

2) AREF on a double-float array conses a double float.
   AREF on a general array used to store double floats does not cons.