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 EAA13319; Mon, 2 Aug 2004 04:37:22 +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 EAA12224 for ; Mon, 2 Aug 2004 04:37:20 +0200 (MET DST) Received: from invasion.mail.pas.earthlink.net (invasion.mail.pas.earthlink.net [207.217.120.254]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i722bHEV009817 for ; Mon, 2 Aug 2004 04:37:19 +0200 Received: from 168-103-58-16.tcsn.qwest.net ([168.103.58.16] helo=dylan) by invasion.mail.pas.earthlink.net with asmtp (Exim 4.34) id 1BrShQ-0000sC-5V; Sun, 01 Aug 2004 19:37:16 -0700 Message-ID: <002101c47839$c9c55bc0$0201a8c0@dylan> From: "David McClain" To: "Brandon J. Van Every" , "caml" References: Subject: Re: [Caml-list] Wish List for Large Mutable Objects Date: Sun, 1 Aug 2004 19:38:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-ELNK-Trace: 7a0ab3eafc8cf994b22988ad1c62733440683398e744b8a46e1d74e7f4ffdfdba8b2dec3b7602e3f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 168.103.58.16 X-Miltered: at nez-perce with ID 410DA8DD.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; mcclain:01 dmcclain:01 caml-list:01 offsets:01 pointers:01 acquisitions:99 mcclain:01 brandon:99 caml-list:01 2004:99 bigarrays:01 posts:01 permutation:01 unboxed:01 priorities:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Okay now... not trying to start any flame wars, but you "guys in the trenches" so to speak seem a bit short on real life experience outside of your own field. I have a perfectly good running VM as user process library running right now in C++ that allows for mixed array files, arbitrary offsets into the file for various array pointers, and this is all transparent to the user just as I indicated in my wish list for OCaml. In more than 20 years of scientific data access and analysis I have only seen uniform arrays, one per file, generated by neophytes. In just about every case I can remember; NetCDF, HDF, FITS, RIF Wave Files, MPEG, etc., these are all compound object files. The trouble with the simple minded approach of one array per file is that most data acquisitions will then end up with dozens of component data files and it becomes a tracking nightmare to keep them all coordinated. Not so if you permit compound document files. With a language as rich and wonderful as OCaml, I really can't understand your hostility to useful additions to the language. If you don't want to play, you don't have to join my sandbox -- find another. David McClain Senior Corporate Scientist Avisere, Inc. +1.520.390.7738 (USA) david.mcclain@avisere.com ----- Original Message ----- From: "Brandon J. Van Every" To: "caml" Sent: Saturday, July 31, 2004 21:06 Subject: RE: [Caml-list] Wish List for Large Mutable Objects > David McClain wrote: > > > > Something I would like to see appear in the OCaml libraries, > > and I don't have it yet myself, is the use of Copy-on-Write > > and Scatter-Gather applied to large mutable objects such as > > BigArrays. > > > > [and some other things in other posts] > > OCaml is not a lazy language. Is it reasonable to expect Bigarray to > perform lazy copies, under any permutation of complexity you have in > mind? > > It seems like what you really want is to design the memory management of > an Operating System. If your files are so huge that they don't fit in > main memory, why aren't you willing to use virtual memory? > Scatter-Gather DMA is a device driver level capability that's hardware > dependent. I don't see why a high level language like OCaml should be > exposing that kind of functionality, and I'm not entirely sure if it > should be doing it under the hood either. If your OS doesn't have the > kind of memory management you want, maybe you should modify an open > source OS, like Linux or BSD Unix, to do what you want? > > You ask why Array1, Array2, Array3 should be special cases. Well, > clearly because they're the most common, and you can perform access > optimizations for each of these common cases. It seems that you are > only thinking of ***BIG*** arrays, i.e. your problems and nobody else's. > Lotsa people don't have your notion of 'big'. Indeed, I don't > personally care about arrays being particularly big. 100MB would be > pretty darn big for what I do in game development right now. I do care > about their contents being unboxed. If someone wanted to rename > Bigarray to UnboxedArray, that would suit my own priorities just fine. > > I don't understand the "starting from zero" complaint, with respect to > arbitrary file formats. If the file format is arbitrarily structured, > it is not an array. You will have to read it some other way. Arrays > are, generally speaking, composed of uniform elements. At least, that's > how all of us pedal-to-the-metal guys view them. I suppose high level > language guys often define the word 'array' to mean anything they want, > like a list or a hash table or a map or whatever, but I don't think they > should. > > I don't see why your Scientific notion of an 'infinite array' should be > a basic language interface. What would be so difficult about building > your favorite array windowing scheme on top of the basic fixed length > components, and calling that a library? Like 'InfiniteArray' or > something. Then you'd write some access functions in some syntax you > like, it would behave the way you like, and for your problems you'd be > good. I've done similar things to perform addressing on icosahedrons, > to try to regularize the mathematics of a tiling of it. I don't bother > the user about it, my functions just do some computing to make it all > work under the hood. > > I do wish Bigarray handled heterogeneous C structures. Homogeneous > arrays impose some design and interop constraints. > > Finally, I'm told that the "%" in the names of called functions in the > sources means that ocamlopt generates different, better code. The C > routines are ignored, they're only used for ocamlc. > > > Cheers, www.indiegamedesign.com > Brand*n Van Every S*attle, WA > > Praise Be to the caml-list Bayesian filter! It blesseth > my postings, it is evil crap! evil crap! Bigarray! > Unboxed overhead group! Wondering! chant chant chant... > > ------------------- > 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 > ------------------- 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