Browse thread
[Caml-list] Looking for a real array
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Eray Ozkural <exa@k...> |
| Subject: | Re: [Caml-list] Looking for a real array |
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) <erayo@cs.bilkent.edu.tr> 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