[Caml-list] unboxing of unary datatypes

[Caml-list] unboxing of unary datatypes

[Hal Daume III]

Hi all,

I originally had a very calculation intensive program which used a data
type which looked like:

> type foo = Foo of float

I could just have easily used floats, but I wanted to ensure that I didn't
do anything stupid (like try to multiply a foo by a float), so I did this
boxing so the type-checker would help me out.

I had always assumed that once the code got past the typechecker, the
ocaml compiler would optimize away the constructor, so that the resulting
code would be as efficient as if I had just done

> type foo = float

But based on some non-scientific tests, it seems that this isn't the case,
and that the original foo type is actually represented using a
pointer-to-float.

I cannot imagine why this is the case (coming from a Haskell world, there
is a difference there between these two types due to laziness, but since
ocaml is strict, I figured this wouldn't be the case).

Can someone explain this to me?  Why doesn't the compiler optimize out the
constructor?

 - Hal

--
Hal Daume III

 "Computer science is no more about computers    | hdaume@isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

-------------------
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

Re: [Caml-list] unboxing of unary datatypes

[Nicolas Cannasse]

> Hi all,
>
> I originally had a very calculation intensive program which used a data
> type which looked like:
>
> > type foo = Foo of float
>
> I could just have easily used floats, but I wanted to ensure that I didn't
> do anything stupid (like try to multiply a foo by a float), so I did this
> boxing so the type-checker would help me out.

Hi,

What you might need here are shadow types.
You can define in your ML source file:

type foo = float
let mfoo f f' = f *. f' (* or better let mfoo = ( *. ) *)

and in your interface ( MLI file ) :

type foo
val mfoo : foo -> foo -> foo

then, other modules trying to work with your foo will have to use your set
of operators because they won't know what exactly is "foo".

> Can someone explain this to me?  Why doesn't the compiler optimize out the
> constructor?

Because they don't have the same C raw representation.
There is one more indirection when you use a constructor.
If you want to interface OCaml with C, you have to be sure that the compiler
won't try to optimize things in an incompatible way ( that goes for all
compilers I think... )

Nicolas Cannasse

-------------------
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

Re: [Caml-list] unboxing of unary datatypes

[Fabrice Le Fessant]

>  I originally had a very calculation intensive program which used a data
>  type which looked like:
>  
>  > type foo = Foo of float
>  
>  I could just have easily used floats, but I wanted to ensure that I didn't
>  do anything stupid (like try to multiply a foo by a float), so I did this
>  boxing so the type-checker would help me out.

In ocaml, there are no overloaded operations, not automatic
conversions to integers, so that if you don't need to do that at
all. The type system will always force you to use the operations on
floats, or to convert them to foo before multiplying them by foo. 

>  But based on some non-scientific tests, it seems that this isn't the case,
>  and that the original foo type is actually represented using a
>  pointer-to-float.
>  
>  I cannot imagine why this is the case (coming from a Haskell world, there
>  is a difference there between these two types due to laziness, but since
>  ocaml is strict, I figured this wouldn't be the case).

If you want to keep the interface with C simple, you need an
easy/efficient way to move ocaml values between caml functions and C
functions. This is done by specifying the internal representation of
ocaml values so that C functions know how to manipulate them. If you
let the compiler optimize the representation of values, C functions
won't be able to access ocaml values anymore (well, it will be more
complicated, since you need to attach by some way a description of the
representation of each value passed to a C function...).

Of course, it could be done by some annotation, telling the compiler
that the value will never be passed to a C function. But this would
introduce useless complexity into the language.

- Fabrice
-------------------
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

Re: [Caml-list] unboxing of unary datatypes

[Florian Hars]

Nicolas Cannasse wrote:
>>Can someone explain this to me?  Why doesn't the compiler optimize out the
>>constructor?
> Because they don't have the same C raw representation.
> There is one more indirection when you use a constructor.

No, I think he sees something different here: The compiler does in fact 
optimize out the constructor and then operates directly on the value (which, in 
this case, is a boxed float). But it does not perform the special float 
optimizations it does on values of the types float, float array and
records like { x: float; y: float; ... (* All fields are floats *)} (but not on 
tupels and sum types containing floats).

(Maybe something like the last part of 
http://caml.inria.fr/archives/200105/msg00174.html should be added to the 
efficiency part of the expert FAQ).

You can see the difference if you compile

type foo = Foo of float

let addpair x y = match x, y with
   (a,_), (b, _) -> a +. b

let addfoo  x y = match x, y with
   Foo x', Foo y' -> x' +. y'

let add x y = match x, y with
   x', y' -> x' +. y'

with ocamlc -dinstr -c foo.ml: The code for addfoo is exactly the same as the 
code for addpair and does not check any contructors, but accesses the values 
with getfield without checking their types or any constructors again (the 
compiler knows they are floats):

L2:     grab 1
         acc 1
         getfield 0
         push
         acc 1
         getfield 0
         ccall add_float, 2
         return 2

add, on the other hand, is treated specially by the float optimizer and gets 
away without the unboxig getfield calls:

L1:     grab 1
         acc 1
         push
         acc 1
         ccall add_float, 2
         return 2

Yours, Florian Hars.

-------------------
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

Re: [Caml-list] unboxing of unary datatypes

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

Fabrice Le Fessant wrote:
>> I originally had a very calculation intensive program which used a data
>> type which looked like:
>> 
>> > type foo = Foo of float
>> 
>> I could just have easily used floats, but I wanted to ensure that I didn't
>> do anything stupid (like try to multiply a foo by a float), so I did this
>> boxing so the type-checker would help me out.
> 
> 
> In ocaml, there are no overloaded operations, not automatic
> conversions to integers, so that if you don't need to do that at
> all. The type system will always force you to use the operations on
> floats, or to convert them to foo before multiplying them by foo. 
> 
> 
>> But based on some non-scientific tests, it seems that this isn't the case,
>> and that the original foo type is actually represented using a
>> pointer-to-float.
>> 
>> I cannot imagine why this is the case (coming from a Haskell world, there
>> is a difference there between these two types due to laziness, but since
>> ocaml is strict, I figured this wouldn't be the case).
> 
> 
> If you want to keep the interface with C simple, you need an
> easy/efficient way to move ocaml values between caml functions and C
> functions. This is done by specifying the internal representation of
> ocaml values so that C functions know how to manipulate them. If you
> let the compiler optimize the representation of values, C functions
> won't be able to access ocaml values anymore (well, it will be more
> complicated, since you need to attach by some way a description of the
> representation of each value passed to a C function...).
>
> Of course, it could be done by some annotation, telling the compiler
> that the value will never be passed to a C function. But this would
> introduce useless complexity into the language.

Or let the compiler produce a C header describing the representation
of the data type, when it is optimized !

It would be nice if Data type with one unary constructor and many 
constant constructors could be optimized by using the fact that pointer
are always even (and non zero), so we can use the zero and/or the odd 
numbers to represent the constant
constructor.

This would optimize a lot the 'a option type.

> - Fabrice
> -------------------
> 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

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] unboxing of unary datatypes

[Nicolas Cannasse]

> No, I think he sees something different here: The compiler does in fact
> optimize out the constructor and then operates directly on the value
(which, in
> this case, is a boxed float). But it does not perform the special float
> optimizations it does on values of the types float, float array and
> records like { x: float; y: float; ... (* All fields are floats *)} (but
not on
> tupels and sum types containing floats).
>

Yes, of course.
What I wanted to say here is that such representation compiler optimisations
have to be documented and somehow normalized in order to be able to
interface OCaml with C. As for floats array, there is a description of how
they are handled in the Manual chapter 17.3.3.
As the case of only-one-constructor is not documented, then there is no
optimisation :)

Nicolas Cannasse

-------------------
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