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 _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
