From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6864DD16D for ; Mon, 25 Jul 2005 08:45:21 +0200 (CEST) Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [213.186.42.179]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j6P6jKgS023500 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 25 Jul 2005 08:45:21 +0200 Received: (qmail 9858 invoked by uid 503); 25 Jul 2005 06:45:23 -0000 Received: (QMFILT: 1.0); 25 Jul 2005 06:45:23 -0000 Received: from b6.ovh.net (HELO mail30.ha.ovh.net) (213.186.33.56) by 26.mail-out.ovh.net with DES-CBC3-SHA encrypted SMTP; 25 Jul 2005 06:45:23 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 25 Jul 2005 06:45:19 -0000 Received: from mail30.ha.ovh.net (10.0.50.30) by mail30.ha.ovh.net with SMTP; 25 Jul 2005 06:45:17 -0000 Received: from b0.ovh.net (HELO queue-pre) (213.186.33.50) by b0.ovh.net with SMTP; 25 Jul 2005 06:45:17 -0000 Received: from adsl-69-108-234-194.dsl.scrm01.pacbell.net (HELO trantor.glondu.net) (postmaster%glondu.net@69.108.234.194) by ns0.ovh.net with SMTP; 25 Jul 2005 06:45:17 -0000 From: Stephane Glondu Organization: Crans To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] How to do this properly with OCaml? Date: Sun, 24 Jul 2005 23:45:12 -0700 User-Agent: KMail/1.7.1 Cc: skaller References: <200507241623.13705.Stephane.Glondu@crans.org> <1122251570.9027.362.camel@localhost.localdomain> In-Reply-To: <1122251570.9027.362.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507242345.13152.Stephane.Glondu@crans.org> X-Ovh-Remote: 69.108.234.194 (adsl-69-108-234-194.dsl.scrm01.pacbell.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Miltered: at concorde with ID 42E48A80.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 arrays:01 mutable:01 initialise:01 ocaml:01 trivial:01 datatype:01 ...:98 paging:98 ...:98 wrote:01 graph:01 typing:01 constructor:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 On Sunday 24 July 2005 17:32, skaller wrote: > Not if the collector is modified by INRIA to support variable > length arrays: this is some kind of tagged block with > a mutable length count which limits how far along the block > the collector looks for boxes: the length count is less > than or equal to the actual number of allocated slots. It would surely be interesting. But now, we have moved from "using Obj.magic for better efficiency" to "modifying to collector"... > I am not so sure: to initialise an array causes a store > in each slot, which forces the whole array to scroll > through your cache: if the array is big this means > disk paging/swapping activity. > > Why do all that when the values will never be read? > We do not even know in advance how much of the > array will actually be used. Consider an array > of length 10,000 elements, where only 100 are used. > We allocate space for 10,000 because we're conservative > and want the program to run on many sized data sets. I was just saying that the GC will go through all your array anyway, even if you use only the first 100 elements (as far as I understood). > BTW: this is a *real* issue an Ocaml user had. I agree. > Think of a class type, whose constructor function itself > takes other class values as arguments .. it can be quite > complicated to set up such values, and, worse, > Ocaml being imperative doing so may have side-effects. You can make a dummy class object with dummy methods without using your class definition (class typing is done only with the set of methods). However, I agree this is not satisfactory. > However that turned what in C is a trivial set of > library functions into a complex unreliable mess > and left me wondering whether the encoding was > properly transparent. I agree that strongly-typedness makes things more intricate sometimes, but it will not make me prefer C... :-) > Not just huge values: values that contain references > to other values .. such as in a graph .. occupy > a lot of memory. That is what I mean by huge values. BTW, for some purposes can also use another datatype such as a Map or a Set. They do not involve such problems, are quite efficient, and more enjoyable than in C... -- Stephane Glondu.