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 UAA30747; Mon, 28 Apr 2003 20:30:03 +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 UAA31056 for ; Mon, 28 Apr 2003 20:30:02 +0200 (MET DST) Received: from eposta.kablonet.com.tr ([62.248.102.66]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h3SITxT29142 for ; Mon, 28 Apr 2003 20:30:00 +0200 (MET DST) Received: (qmail 39060 invoked by uid 0); 28 Apr 2003 18:37:20 -0000 Received: from unknown (HELO 195.174.169.185) (exa@195.174.169.185) by 0 with SMTP; 28 Apr 2003 18:37:20 -0000 From: Eray Ozkural Reply-To: erayo@cs.bilkent.edu.tr Organization: Bilkent University CS Dept. To: Brian Hurt Subject: Re: [Caml-list] Looking for a real array Date: Mon, 28 Apr 2003 21:29:27 +0300 User-Agent: KMail/1.5.9 Cc: OCaml List References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200304282129.27582.exa@kablonet.com.tr> X-Spam: no; 0.00; eray:01 ozkural:01 caml-list:01 book-keeping:01 amiga:01 pointers:01 advisor:99 gurr:01 bigarrays:01 unboxed:01 erayo:01 bilkent:01 ankara:01 kde:01 malfunction:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi Brian, On Monday 28 April 2003 19:40, Brian Hurt wrote: > Having a reference in addition to the data structure is a little bit of > overhead. But optimization is a tricky thing- often times, what you gain > in the straights you lose in the curves. For example, what happens when > some other peice of code keeps a pointer to a single element of the array, > when the pointer to the rest of the array- and all the other elements- are > gone? In ocaml, the array and all the other elements become garbage, and > the last, lone object that is not garbage stays around. Also, copying > becomes a big issue in my experience. > I will happily agree that asymptotic complexity is more important than constant gains and that there are other book-keeping tasks that might make the programming more complex than necessary. > Personally, I find one extra level of dereferencing isn't that big of a > deal. If you're too the point where it is a big deal, you are already > talking about hand-tuned assembly language. My advice: stop worrying > about minutia. Permature optimization is the root of all evil. Yes, I'm coming from the land of evil optimizers. :) I spent a large portion of my youth hand-optimizing 68k assembly! I was really shocked when I found out about 2 years ago that some FORTRAN compilers could do the tricks I spent hours on the Amiga to perform! To be serious, I was concerned about this fact because I have, if you recall, started writing a graph library. Unfortunately, it makes a big deal of space and time difference when I use pointers to integers rather than simply integers! In fact, my advisor would shoot me if I did the former. Space loss is evident. But the worse case comes from losing "cache coherence", a fine point that can change the speed 5 fold sometimes!!!!! Memory hierarchy is like magic! Thanks to Brian Hurt and David Gurr who wrote off-the list that bigarrays would work for me. It looks like Bigarrays can do unboxed arrays of integers. Cheers, -- Eray Ozkural (exa) Comp. Sci. Dept., Bilkent University, Ankara KDE Project: http://www.kde.org www: http://www.cs.bilkent.edu.tr/~erayo Malfunction: http://mp3.com/ariza GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C ------------------- 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