On 05-05-2009, Jean-Marc Eber <jeanmarc.eber@lexifi.com> wrote:
> Hi Dimitry,
>
> LexiFi for instance _is_ clearly interested by a sse2 32bit code generator.
>
> One should probably have the following in mind and/or ask the following questions:
>
> - it is probably not a good idea to support both backends (sse2 and old stack fp 
> i386 architecture). It will be necessary to make a choice (especially taking in 
> account the limited INRIA resources and the burden of already supporting 
> different windows ports).
>

Maybe this point can be discussed. I think 3 ports for windows is a bit
too much... I don't know Dimitry point of view, but maybe INRIA can just
consider MSVC (or mingw). If this is a way to free INRIA resources, it
is a good option.

> - would INRIA be ok to switch to a sse2 code generator (based on Dimitry's patch 
>   supposing that he is ok to donate it to INRIA - or Xavier's work or whatever)?
>
> - I also guess that a sse2 code generator would be simpler than the current one 
> (that has to support this horrible fp stack architecture) and would therefore be 
> a better candidate for further enhancements.
>
> - what is the opinion on this list, as a switch to a sse2 backend would exclude 
> "old" processors from being OCaml compatible (I don't have a precise list at 
> hand for now) ?

I would like to say "go on", but SSE2 will limit OCaml to P4 on i386.
In Debian, this is the "low limit" of our build daemon. I think it is
quite dangerous not having the option of the older code generator...

If INRIA choose to switch to SSE2 there should be at least still a way
to compile on older architecture. Doesn't mean that INRIA need to keep
the old code generator, but should provide a simple emulation for it. In
this case, we will have good performance on new arch for float and we
will still be able to compile on old arch. 

>
> My opinion is that this support of legacy hardware is not important, but I guess 
> others are arguing in opposite directions... :-)
>

I would say that "the performance of legacy hardware is not important"
-- support is still important. 

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

Indeed.

Regards
Sylvain Le Gall