From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA08230 for caml-redistribution; Wed, 3 Feb 1999 11:57:46 +0100 (MET) 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 GAA02852 for ; Sun, 31 Jan 1999 06:59:45 +0100 (MET) Received: from pegasus.azstarnet.com (pegasus.azstarnet.com [169.197.56.194]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id GAA09848 for ; Sun, 31 Jan 1999 06:59:43 +0100 (MET) Received: from dylan (dialup16ip116.tus.azstarnet.com [169.197.37.244]) by pegasus.azstarnet.com (8.9.1a/8.9.1a) with SMTP id WAA11865 for ; Sat, 30 Jan 1999 22:59:21 -0700 (MST) X-Sent-via: StarNet http://www.azstarnet.com/ Message-ID: <000f01be4cde$ee8f1e00$210148bf@dylan> From: "David McClain" To: "Liste CAML" Subject: Array Size Limitations Overcome! Date: Sat, 30 Jan 1999 22:59:55 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: weis I have just finished developing a layer called "General_Array" on top of = the "Array" library that permits unlimited sized arrays (up to 2^30 = elements). I do it by noting that Array.unsafe_get and Array.unsafe_set = cannot distingish an actual heap object from a user allocated pointer to = doubles. By puling some stunts in C I can make OCAML deal with this = "arena" in a uniform manner between arrays of floats and my own large = arrays. Hence the same code writtin with the Array.unsafe_get/set works = with either one, and I simply build my own arrays when the size would = exceed the limits imposed by OCAML. Note that the "alloc_final" function allows me to allocate my own large = structures, and even though they appear as only a single heap word to = OCAML, I can sensitize OCAML to my large allocations and force a more = frequent GC cycle to help keep these foreign objects from overwhelming = the paging system. I will clean up the code and post it on my Web site shortly. I must say, = that this was what I consider a major architectural change to the = underpinnings of my OCAML image processing library. And yet, in spite of = this major shift, the OCAML code worked perfectly well. I have never = seen anything like it! I did have one bug in my "C" code (a simple = 3-letter typo), but the OCAML stuff was pristine! David McClain Sr. Scientist Raytheon Missile Systems Co. Tucson, AZ http://www.azstarnet.com/~dmcclain/homepage.htm