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 OAA24007; Thu, 9 Sep 2004 14:31:12 +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 OAA23402 for ; Thu, 9 Sep 2004 14:31:11 +0200 (MET DST) Received: from [128.93.8.158] (macaque.inria.fr [128.93.8.158]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i89CVBw1025861 for ; Thu, 9 Sep 2004 14:31:11 +0200 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040909120845.GA26938@bourg.inria.fr> References: <200409090310.29295.jon@jdh30.plus.com> <16704.901.571258.566181@gargle.gargle.HOWL> <20040909082354.GA22512@annexia.org> <20040909.110850.59463842.oandrieu@nerim.net> <20040909120845.GA26938@bourg.inria.fr> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2106BF9A-025C-11D9-AAE1-00039310CAE8@inria.fr> Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Gripes with array Date: Thu, 9 Sep 2004 14:31:09 +0200 To: caml users X-Mailer: Apple Mail (2.619) X-Miltered: at nez-perce with ID 41404D0F.001 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 basile:01 pointers:01 chunks:01 tradeoff:01 bug:01 camlp:01 extensible:01 arrays:01 million:98 ocaml:01 garbage:01 doligez:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sep 9, 2004, at 14:08, Basile Starynkevitch [local] wrote: > The header layout remains the same (so only 22 bits for size on 32 > bits machine), but if the size is all bit ones, the block is > actually a fixed block, and the real array size is the word before > the header. The real size would have to be after the header, not before it, because you cannot store anything before the header. > If you have a huge array of > pointers, the garbage collector (even the minor one) has to scan the > full array - and this scan is "atomic" in the sense that it is not > interruptible (and I believe that designing a GC which incrementally > scans big values by chunks is not trivial, given Ocaml GC performance > needs). The minor GC will never scan such a huge array because you won't find it in the minor heap. What you say is still true of the major GC. > Regarding very big data structures, I tend to believe that they should > be more organized than just a single monster array (hence the current > array limits on 32 bits machine is a sensible tradeoff), even on 64 > bits irons. But I have no practical experience on these. I fixed a bug in a camlp4 lexer recently, where it needed an (extensible) array larger than 16 million entries. Implementing an array of arrays increased the code size by as much as 6 lines... -- 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