From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 59A78BC58 for ; Tue, 4 May 2010 17:11:54 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.52,327,1270418400"; d="scan'208";a="62134479" Received: from peermanence.saclay.inria.fr (HELO [195.83.212.205]) ([195.83.212.205]) by mail4-relais-sop.national.inria.fr with ESMTP; 04 May 2010 17:11:54 +0200 Message-ID: <4BE03AA8.30408@inria.fr> Date: Tue, 04 May 2010 17:18:00 +0200 From: Fabrice Le Fessant User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Sylvain Le Gall Cc: caml-list@inria.fr Subject: Re: [Caml-list] Re: Subtyping structurally-equivalent records, or something like it? References: <602616.65342.qm@web111501.mail.gq1.yahoo.com> <4429.86797211251$1272970133@news.gmane.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; subtyping:01 ocamlopt:01 arrays:01 ffi:01 ocaml:01 specifies:01 compiler:01 rossberg:01 rossberg:01 le-gall:01 compiler:01 ocamlopt:01 beginner's:01 ocaml:01 bug:01 "ocamlopt" does optimize data representation: for example, it can unbox floats into registers, or into arrays of floats. However, there is a tradeoff between such optimizations and efficiency: when you do too much representation optimisation, you might end up performing a lot of tests because a given type can be represented in multiple formats, and performing a lot of transformations between the representations, especially as the FFI (Ocaml interface to C) specifies the representation of data. Of course, I am not saying it is not possible to do better: it requires a lot of energy, the compiler code becomes more complex, and the improvement on speed is not clear. --Fabrice Sylvain Le Gall wrote, On 05/04/2010 03:42 PM: > On 04-05-2010, rossberg@mpi-sws.org wrote: >> "Sylvain Le Gall" : >>> This is not about optimized compiler in this case but about data >>> representation. Even if you use an optimized compiler (which is not >>> really the case with ocamlopt), you won't change datastructure >>> representation to optimize. >> What do you mean? There is no reason in general why a compiler cannot >> optimize data representations, and some do in cases like this. >> > > Anyway, if it comes to data alignement and things like that, the > compiler should optimize data representations. But in this case, I > really don't think we are talking about data alignement. > > Regards, > Sylvain Le Gall > > _______________________________________________ > 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 > -- Fabrice LE FESSANT Chercheur, Equipe ASAP (As Scalable As Possible) http://www.lefessant.net/ INRIA-Futurs, Bat P - 112 Parc Orsay Université 2-4, rue Jacques Monod F-91893 Orsay Cedex, FRANCE