Enabling float unboxing on 64-bit systems

In many high-level languages, it’s desirable that all data be represented with the same size word (usually a system word, 32- or 64-bits) so that polymorphic functions need not perform run-time dispatch, nor be type-specialized at compile time, to work with data of different sizes. This is usually done by “boxing” non-word-size data by storing it in the heap and passing around a word-sized pointer to the data.

Of course for “small” data boxing entails the performance overhead of an extra pointer indirection. (For “large” data boxing is usually a performance win since it reduces the amount of data which must be copied; this is also why in C structures are usually passed by reference.) For this reason anything smaller than or equal in size to a word will usually be stored unboxed. On 32-bit systems, this means characters, integers, enumerations, and single-precision (32-bit) floating-point numbers, but not double-precision (64-bit) floating-point numbers. On 64-bit systems, all of the above including doubles can be stored unboxed.

Mercury follows these same conventions, which does not bode well for scientific computations on 32-bit systems, since all doubles will be boxed. (This is actually special-cased for arrays and structures in OCaml.)

Fortunately Mercury does store doubles unboxed on 64-bit systems, with one gotcha: Double-precision floats will only be stored unboxed if the compiler is built with an existing compiler, and not bootstrapped! This means that after you first install Mercury, you must make realclean, ensure that mmc and friends are in your PATH, and repeat the installation (including ./configure). You can check that configure enabled float unboxing with grep unboxed config.log; you will see messages indicating its status.

If you are doing any sort of scientific calculations on a 64-bit machine it’s important to ensure that this optimization is enabled; it can easily double the performance of any float-heavy computations.