Re: [Caml-list] Ocamlopt x86-32 and SSE2

[Xavier Leroy <Xavier.Leroy@inria.fr>]

Dmitry Bely wrote:

> I see. Why I asked this: trying to improve floating-point performance
> on 32-bit x86 platform I have merged floating-point SSE2 code
> generator from amd64 ocamlopt back end to i386 one, making ia32sse2
> architecture. It also inlines sqrt() via -ffast-math flag and slightly
> optimizes emit_float_test (usually eliminates an extra jump) -
> features that are missed in the original amd64 code generator.

You just passed black belt in OCaml compiler hacking :-)

> Is this of any interest to anybody?

I'm definitely interested in the potential improvements to the amd64
code generator.

Concerning the i386 code generator (x86 in 32-bit mode), SSE2 float
arithmetic does improve performance and fit ocamlopt's compilation
model much better than the current x87 float arithmetic, which is a
bit of a hack.  Several options can be considered:

1- Have an additional "ia32sse2" port of ocamlopt in parallel with the
   current "i386" port.

2- Declare pre-SSE2 processors obsolete and convert the current
   "i386" port to always use SSE2 float arithmetic.

3- Support both x87 and SSE2 float arithmetic within the same i386
   port, with a command-line option to activate SSE2, like gcc does.

I'm really not keen on approach 1.  We have too many ports (and
their variants for Windows/MSVC) already.  Moreover, I suspect
packagers would stick to the i386 port for compatibility with old
hardware, and most casual users would, too, out of lazyness, so this
hypothetical "ia32sse2" port would receive little testing.

Approach 2 is tempting for me because it would simplify the x86-32
code generator and remove some historical cruft.  The issue is that it
demands a processor that implements SSE2.  For a list of processors, see
  http://en.wikipedia.org/wiki/SSE2
As a rule of thumb, almost all desktop PC bought since 2004 has SSE2,
as well as almost all notebooks since 2006.  That should be OK for
professional users (it's nearly impossible to purchase maintenance
beyond 3 years, anyway) and serious hobbyists.  However, packagers are
going to be very unhappy: Debian still lists i486 as its bottom line;
for Fedora, it's Pentium or Pentium II; for Windows, it's "a 1GHz
processor", meaning Pentium III.  All these processors lack SSE2
support.  Only MacOS X is SSE2-compatible from scratch.

Approach 3 is probably the best from a user's point of view.  But it's
going to complicate the code generator: the x87 cruft would still be
there, and new cruft would need to be added to support SSE2.  Code
compiled with the SSE2 flag could link with code compiled without,
provided the SSE2 registers are not used for parameter and result
passing.  But as Dmitry observed, this is already the case in the
current ocamlopt compiler.

Jean-Marc Eber:
>> But again, having better floating point performance (and
>> predictable behaviour, compared to the bytecode version) would be a
>> big plus for some applications.

Dmitry Bely:
> Don't quite understand what is "predictable behavior" - any generator
> should conform to specs. In my tests x87 and SSE2 backends show the
> same results (otherwise it would be called a bug).

You haven't tested enough :-).  The x87 backend keeps some intermediate
results in 80-bit float format, while the SSE2 backend (as well as all
other backends and the bytecode interpreter) compute everything in
64-bit format.  See David Monniaux's excellent tutorial:
  http://hal.archives-ouvertes.fr/hal-00128124/en/
Computing intermediate results in extended precision has pros and
cons, but my understanding is that the cons slightly outweigh the pros.

- Xavier Leroy