From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA04710; Sat, 11 Sep 2004 22:53:45 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA09541 for ; Sat, 11 Sep 2004 22:53:44 +0200 (MET DST) Received: from [192.168.0.2] (planar.net0.nerim.net [213.41.168.102]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i8BKrhfS028177 for ; Sat, 11 Sep 2004 22:53:43 +0200 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200409111536.10902.jon@jdh30.plus.com> References: <200409090310.29295.jon@jdh30.plus.com> <200409091758.05679.jon@jdh30.plus.com> <200409111536.10902.jon@jdh30.plus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Gripes with array Date: Sat, 11 Sep 2004 22:53:42 +0200 To: caml users X-Mailer: Apple Mail (2.619) X-Miltered: at nez-perce with ID 414365D7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 2004:99 raffalli:01 runtime:01 extensible:01 initialized:01 off-line:99 initialized:01 off-line:99 sweeping:01 run-time:01 slower:01 synthetic:99 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sep 11, 2004, at 16:36, Jon Harrop wrote: > On Friday 10 September 2004 06:56, Christophe Raffalli wrote: >> You could also lie in the tag about the size of array (if the way the >> runtime finds free block of memory does not use it). It will cost an >> increment of integer at each step in the initialisation process which >> should not be much since the beginning of array may stay in the cache >> if >> the initialisation function is simple and this will be neggligeable >> if not. > > What is the trickiest/most-error-prone part of doing this and could > this be > used to implement amortised extensible arrays within the compiler? I > would > like to see such a thing in the compiler (not that I distrust Markus > ;-). The "if" part is false... I suppose it might be possible to change representations (true length in header and initialized part stored off-line / initialized part in header / true length off-line) when the GC switches between sweeping and marking. We would also need several additional primitives to create, update, and destroy the "off-line" part. Frankly, I find it hard to imagine that it would give a noticeable run-time improvement on any program. Most likely, it would make them all a fraction of a percent slower, except for the most synthetic of benchmarks. > On Friday 10 September 2004 14:45, Damien Doligez wrote: >> An intermediate solution would >> be to make a "Array.unsafe_make" primitive, which would use memset >> instead of initialising the array properly. If you enter this as >> a feature wish in the BTS, I'll look into it. > > No, I don't think the performance improvement would justify your time > or the > loss of safety. No loss of safety if we don't export that primitive and use it only in Array.init. After all, it only breaks type safety, and only if you use it wrong. > Could you add a memset to String.create though? :-) String.make > An array_init2 function which specialises the array type but uses an > external > "f" function betters the time taken by Array.init by ~36% (perhaps not > significantly different): That's from getting rid of the float/non-float test. Nothing to do with the cost of initializing twice. -- Damien ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners