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
caml: camlp4 revised syntax
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-07-15 (11:42)
From: Basile STARYNKEVITCH <basile@s...>
Subject: Re: unboxed scalars - was [Caml-list] caml: camlp4 revised syntax wrote:
> Hello,
> First of all, thanks to all people who develops this language and 
> related tools, and to people who supports them using it.
> I decided to use it in several developments. When finished, the 
> developed modules will be made public, if they are enough generic (best 
> place to publish it?)
> Two points still causing some troubles:
> 1) The internal integer coding:
> It seems that an integer of value "x" is internally stored like "2x*1" ( 
> x shift 1 or 1 ). That is a loss of performance, not only when doing 
> calculations, but also, by example, when using the integer as index of a 
> string character, ... . Usage of native-int doesn't improves the subject.

This is unlikely to change any soon. It is (nearly) required by polymorphic functions (like

Changing it would require a very major change of the compiler, which should specialize all polymorphic functions for 
such unboxed scalar types. If it was done, it would require either a whole program compilation, or a possible 
(exponential) bloat of generated code size (basically for each polymorphic function, you would have to generate all the 
scalar forms in addition of the polymorphic one).

I'm not an Ocaml implementation expert, so I could be wrong, and I would be delighted to be confirmed or infirmed by the 
Ocaml guru implementors (e.g. Xavier Leroy).

IIRC, the ML/Ton implementation is rumored to do this kind of unboxing.

Besides, I am pretty sure than on current processors, unboxing scalars is probably more a win because of memory & cache 
issues than because of the additional shift & add required to transform a 2n+1 into n or vice versa. Such ALU operations 
are very cheap today.

email: basile<at>starynkevitch<dot>net | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***