Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
single-precision floats, etc.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-10-19 (11:33)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: single-precision floats, etc.
> Hi, I'm looking into the feasibility of using Caml for some
> high-performance numerically intensive video game stuff, and I had a
> couple questions:

You might be interested in François Pessaux's OCamlDoom and OCamlQuake
programs, available and described at
OCamlDoom is a purely software-based renderer for "pseudo 3D" scenes
as found in Doom.  OCamlQuake is a renderer for more general 3D scenes
as found in Quake, using the Glide library to leverage the hardware
support provided by 3DFX Voodoo cards.  Both deliver very decent

> Most importantly, is there any way to make the "float" type compile
> to single precision floating point numbers?  I looked briefly at the
> compiler source, but I didn't see the obvious "#define FLOAT_TYPE
> double" anywhere.  All of the asm generators seem to have 8 byte
> floats hard coded in to them.  The best thing would be to have a
> float32 built in type so I could still use doubles when necessary
> (rarely), but in lieu of that, just switching the float type to
> single precision when I compiled the compiler would be fine.  Has
> anybody looked at doing this, and/or do the compiler authors have
> any idea how hard this would be?  How hard-coded are doubles into
> the compiler?

Double-precision floats are hard-coded in a number of places in the
OCaml implementation, such as the native-code generators, but also
parts of the run-time system (e.g. the serializer and deserializer).
Substituting single-precision floats everywhere is feasible, but a
major undertaking.

I'm curious to why you need single floats.  It's certainly not for
speed, because most processors nowadays do not compute over single
floats any faster than over double floats.  Indeed, they convert
single floats to double or extended precision at load time, and do
all their arithmetic in double or extended precision.

So, the only reason for using single floats is to reduce the size of
large arrays or matrices of floating-point numbers, and this dovetails
into your next question:

> Another question, which is not as important, was the size limitation
> on arrays.  The biggest float array one can have is around 699000
> elements.  That's pretty small on today's machines.  I know there
> are bigarray packages, but from looking at the comments, it's
> unclear to me how well they're integrated.  It also looks like the
> accessor functions, because they're external, would be function
> calls and not inlined, which would hurt any inner loop doing math on
> the array.  Is the size limitation fixed, or is there any chance of
> increasing it?

The size limit for float arrays is 2^21-1 elements for a 32-bit
processor, and 2^54-1 elements for a 64-bit processor.  This is due to
the representation of heap blocks in the OCaml runtime system, where
each block has a one-word header containing 8 bits of "tag", 2 bits
for GC use, and the remaining 22 (or 54) bits for the size in words of
the block.

If you need larger arrays of numerical types, then the Bigarray
library is exactly what you need.  Not only it supports arbitrarily
large arrays (by allocating the data part outside the Caml heap), but
it also supports arrays of single-precision floating-point numbers
in addition to double floats and various integer types, all stored as
compactly as possible.

Bigarray accesses are a bit slow under the bytecode interpreter, but
the native-code compiler is able to inline and specialize accesses to
bigarrays of dimensions 1, 2 and 3 when their type and layout are
statically known.  For instance, my FFT benchmark runs at about the
same speed (+/- 10%) when using 1-dimensional bigarrays of double
floats and when using regular "float arrays".  So, don't dismiss
bigarrays on performance grounds!

> Finally, why aren't simple arrays of ints unboxed, like the arrays
> of floats?  Would that be a hard change to make as well?

Integers (type "int") are not boxed, just tagged, so a special
treatment of "int array" wouldn't make a significant speed difference.

Hope this helps,

- Xavier Leroy