From weis Wed Feb 3 11:57:46 1999 Return-Path: weis 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 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BE4CA4.40DE98B0" 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 Content-Length: 4028 Lines: 98 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BE4CA4.40DE98B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_000C_01BE4CA4.40DE98B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have just finished developing a = layer called=20 "General_Array" on top of the "Array" library that = permits=20 unlimited sized arrays (up to 2^30 elements). I do it by noting that=20 Array.unsafe_get and Array.unsafe_set cannot distingish an actual heap = object=20 from a user allocated pointer to doubles. By puling some stunts in C I = can make=20 OCAML deal with this "arena" in a uniform manner between = arrays of=20 floats and my own large arrays. Hence the same code writtin with the=20 Array.unsafe_get/set works with either one, and I simply build my own = arrays=20 when the size would exceed the limits imposed by OCAML.
 
Note that the "alloc_final" function = allows me to=20 allocate my own large structures, and even though they appear as only a = single=20 heap word to OCAML, I can sensitize OCAML to my large allocations and = force a=20 more frequent GC cycle to help keep these foreign objects from = overwhelming the=20 paging system.
 
I will clean up the code and post it on my Web site = shortly. I=20 must say, that this was what I consider a major architectural change to = the=20 underpinnings of my OCAML image processing library. And yet, in spite of = this=20 major shift, the OCAML code worked perfectly well. I have never seen = anything=20 like it!  I did have one bug in my "C" code (a simple = 3-letter=20 typo), but the OCAML stuff was pristine!
 
 
David McClain
Sr. = Scientist
Raytheon=20 Missile Systems Co.
Tucson, AZ
http://www.azsta= rnet.com/~dmcclain/homepage.htm
------=_NextPart_000_000C_01BE4CA4.40DE98B0--