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: Nicolas Cannasse <ncannasse@m...>
Subject: Re: [Caml-list] Efficency of varient types
Brian Hurt wrote:
 >
 >
 > On Sun, 27 Nov 2005, Michael D. Adams wrote:
 >
 >> I agree, which is why it was my hope that OCaml might do some of that
 >> for me.  Consider a home brew bool type, "type mybool = Mytrue |
 >> Myfalse".  If the compiler were smart enough, it could represent that
 >> as an unboxed type.
 >
 >
 > The compiler is smart enough to do that already- variants without
 > associated data are represented as ints.

Exactly.
So actually the custom bool can be "safely" casted to the corresponding 
real bool since they have same runtime representation.

 >> From there it might be a small step to
 >> semi-unboxed types such as the one I started this discussion with,
 >> "type value = Int of int | Bool of bool | String of string".
 >
 >
 > The problem here is that the variants take two words- one word which
 > says which variant it is, and the second word which is the unboxed int,
 > unboxed bool, or pointer to the boxed string.

It's a bit more complex.
A variant have a header storing :
  - it's tag
  - some GC bits
  - it's size (number of fields)
Then the data is followed by N fields which are the variant parameters.
That's why there is a semantical difference between

   Tag of int * int

and

   Tag of (int * int)

In the first case it's a 2 fields block, in the second it's a on-field 
block storing a 2 fields tuple.

I think that the compiler is pretty good at unboxing floats and maybe 
int32 when doing some numerical calculus. Other optimizations are more 
tricky.

Nicolas