On Sat, Oct 2, 2010 at 7:48 PM, Matthew Flatt <mfl...@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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
