From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 09FBCBC88 for ; Tue, 8 Feb 2005 13:04:40 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j18C4dvm003763 for ; Tue, 8 Feb 2005 13:04:39 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA18672 for ; Tue, 8 Feb 2005 13:04:39 +0100 (MET) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j18C4bQP003760 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 8 Feb 2005 13:04:38 +0100 Received: from qrczak by qrnik.knm.org.pl with local (Exim 3.36 #1) id 1CyU6f-0001ZV-00 for caml-list@inria.fr; Tue, 08 Feb 2005 13:04:37 +0100 To: caml-list@inria.fr Subject: Re: [Caml-list] [Benchmark] NBody X-Face: OW>RV&gN+&b-aiNY|U)f=S%w+/rK!);f>/W9IXg})]&F>ht.1Up8@04+_!gOp(_/l_-+E^. 2\vI)1=D,%HWiq)r(M/V~dr^5T^KF/[w5YZ4<0Sus3+O>l3uA/&W_21m?.s,Po8{pb0@ References: <20050207.195724.87945401.Christophe.Troestler@umh.ac.be> <1107826151.13571.199.camel@pelican.wigram> <80eb59bd970cd828d562f79e8eb565bf@mit.edu> <1107855477.2555.95.camel@pelican.wigram> From: "Marcin 'Qrczak' Kowalczyk" Mail-Followup-To: caml-list@inria.fr Date: Tue, 08 Feb 2005 13:04:37 +0100 In-Reply-To: <1107855477.2555.95.camel@pelican.wigram> (skaller@users.sourceforge.net's message of "08 Feb 2005 20:37:58 +1100") Message-ID: <87zmyfjm0a.fsf@qrnik.zagroda> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: "Marcin 'Qrczak' Kowalczyk" X-Miltered: at concorde with ID 4208AAD7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 4208AAD5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 mutable:01 mutable:01 unboxed:01 ocaml:01 unboxed:01 sml:01 ocaml:01 optimise:01 optimise:01 behaves:01 surprising:01 writes:01 polymorphic:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: skaller writes: > But the types in your record are mutable, and so it can't > possibly work. It does work: mutable floats are unboxed too (if there are no non-float fields). It would be different if OCaml used standalone references instead of mutable fields. But mutable fields are not first-class entities, so they can be unboxed. I think this is actually the reason of their existence (instead of taking SML ref as a primitive, which is implemented with a record with a mutable field in OCaml). > Perhaps Ocaml is actually smart enough to optimise > > type r = { m: float; n: float }; > let x = Array.create 99 { m=0.0; n=0.0 } in > x.[2] = { x.[2] with m = m + 1.0 }; > > so x is represnted by an array of float, It does not optimize it, even though it theoretically could. It's not clear whether this would be an optimization. Having a large field unboxed requires boxing a large object if it's taken out of the array as a whole - this is an improvement only if memory savings (and thus cache usage and GC time) outweigh slower element access. And it is generally taken out as a whole, unless a particular operation could be applied to the copy inside the array directly. This requires analysis which I believe OCaml doesn't perform. Floats are small enough to be kept in registers. > and perhaps one could even optimise > > x.[2].m <- 22.0; > > even though it appears to be a type error (modifying > an immutable field), it actually isn't, since you could > always used functional update. Since with the generic polymorphic representation of the array the only way to implement it (in the absence of whole-program analysis) is functional update, and it behaves exactly as functional update, it's not surprising that OCaml doesn't allow this and requires to use functional update explicitly. > However it isn't clear Ocaml type system uses the most > expressive typing of 'constness', i.e. that it propages > 'mutable' ness correctly. There is nothing to propagate. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/