Re: ocamlopt LLVM support (Was: [Caml-list] OCamlJIT2 vs. OCamlJIT)

[Benedikt Meurer <benedikt.meurer@googlemail.com>]

On Dec 5, 2010, at 22:21 , Benedikt Meurer wrote:

> On Dec 5, 2010, at 21:12 , Jon Harrop wrote:
> 
>>> Using a different data representation within OCaml would indeed be
>>> possible, but one has to ask what it's worth? You'd get better floating
>>> point performance (most likely)
>> 
>> And faster tuples, ints, chars, complex numbers, low-dimensional
>> vectors/matrices, hash tables and so on. More types (e.g. int16 and
>> float32). Even arbitrary-precision arithmetic can benefit by keeping small
>> numbers unboxed when possible. Bigarrays disappear. The FFI gets simpler,
>> easier to use and more powerful (e.g. you can generate AoS layouts for
>> OpenGL). The benefits are enormous in the general case but that is beside
>> the point here. Moreover, this would never be accepted either because it
>> would degrade the performance of applications like Coq. If it is done at
>> all, such work must be kept separate from the OCaml compilers.
> 
> ocamlopt already supports float32 and int16, tho they are not exploited to the upper layers (don't know why, but I also don't know why one would need them).

To be exact, you could load/store float32 and int16 values. At least for int16, computations would be less efficient on modern CPUs, since the partial register reads/writes would create false dependencies and therefore result in less efficient instruction scheduling (similar for float32 with SSE2, i.e. "divss" leaves the three higher doublewords of the target register unchanged, thereby introducing false dependencies on previous instructions).

Benedikt