[racket-dev] flonum vs. inexact-real

On Sat, Oct 2, 2010 at 7:48 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> With the current memory manager, I don't think there's any potential space
> gain from using 32-bit floats instead of 64-bit floats. Is there any
> other reason to use 32-bit floating point?

In theory one can get better performance with floats. For example, you
can pack more floats than doubles into the SIMD registers on Intel
chips. Anyone paying this much attention to performance isn't going to
be using Racket anyway, so I don't think this is a valid argument.

Regarding what Neil said: don't listen to him!!1! There is a better
representation: NaN boxing. E.g.:

  http://blog.mozilla.com/rob-sayre/2010/08/02/mozillas-new-javascript-value-representation/

IEEE floating point allows many representations for NaN but all
hardware only ever uses one. The idea with NaN boxing is you some of
these other representations for type tags. You get 32-bit ints, and
unboxed 64-bit  doubles. Presumably you rely on your tracing JIT to do
unboxing for non-float types (AFAIK LauJIT and Trace/JaegerMonkey are
the only VMs to use this representation). I believe on 64-bit machines
Mozilla are using 128-bit wide values in their JS VM. One could light
the Dave Herman signal (or just read the blog posts) for more info.

Cheers,
N.