Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Looking for a real array
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-04-28 (18:30)
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.


Eray Ozkural (exa) <>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project:
www:  Malfunction:
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: