Version française
Home     About     Download     Resources     Contact us    
Browse thread
Efficency of varient types
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Brian Hurt <bhurt@s...>
Subject: Re: [Caml-list] Efficency of varient types


On Sun, 27 Nov 2005, Michael D. Adams wrote:

> I should clarify what I am proposing because it also only requires one
> word.  The bottom one or two bits of that word would say which variant
> it is.  The remaining bits representing any data with that variant.
> (Obviously this would only work if the associated data is small
> enough, but fortunately most of the primitives are small enough (e.g.
> int (31 bits), bool (1 bit), char (8 bits).))

Except that this runs into the problem of knowing the subtle details of 
the GC- not only how it works now, but what (if any) gaurentees are being 
given for future development.  For example, is it gaurenteed that the GC 
will recognize words with the low two bits being 10 as not pointers?  Or 
does the low bit being 0 means the GC may (or may not) assume it's a 
pointer, and weird word values would cause the GC to segfault?  Even if it 
works now, will it continue to work with Ocaml 3.10, 3.20, 4.0, etc.  I 
don't know- I don't work at INRIA.  This is exactly what I was warning 
about earlier.

The other thing I'll throw in here is a warning against premature 
optimization.  OK, so method A is 15x slower than method B.  But how big 
of an effect will this have on the overall program?  If method B is one 
clock cycle, and method A is 15 clock cycles, probably not much.  15 clock 
cycles is about the cost of one mispredicted branch, and much, much 
cheaper than a cache miss.  If you're doing anything at all interesting, 
the most likely case is that the 14 clock difference will be minor 
compared to the costs of the rest of the program.

Brian