From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id AE679BBAF for ; Tue, 5 May 2009 16:59:20 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAJjx/0lQW+UCe2dsb2JhbACWdgEBFiIEqX8Ij3KCLhoIgTEF X-IronPort-AV: E=Sophos;i="4.40,297,1238968800"; d="scan'208";a="39487207" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 05 May 2009 16:59:01 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M1M6l-0004K6-Jz for caml-list@inria.fr; Tue, 05 May 2009 14:58:59 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 May 2009 14:58:59 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 May 2009 14:58:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Ocamlopt code generator question Date: Tue, 5 May 2009 14:58:47 +0000 (UTC) Message-ID: References: <90823c940904281236x61204451nac149ee15b5df73a@mail.gmail.com> <4A0005C8.8010609@inria.fr> <90823c940905050241y11f012e5xee8316e3e4337ff9@mail.gmail.com> <4A004A05.6040204@lexifi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/pre0.9.9-102 (Linux) Sender: news X-Spam: no; 0.00; le-gall:01 ocamlopt:01 lexifi:01 lexifi:01 mingw:01 xavier's:01 ocaml:01 ocaml:01 predictable:01 bytecode:01 donate:98 jeanmarc:01 eber:01 eber:01 wrote:01 On 05-05-2009, Jean-Marc Eber 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