Browse thread
Ocamlopt code generator question
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2009-05-05 (14:59) |
From: | Sylvain Le Gall <sylvain@l...> |
Subject: | Re: Ocamlopt code generator question |
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