Browse thread
Efficency of varient types
[
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: | 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