* [Caml-list] unboxing of unary datatypes @ 2003-01-14 0:08 Hal Daume III 2003-01-14 4:38 ` Nicolas Cannasse 2003-01-14 9:57 ` Fabrice Le Fessant 0 siblings, 2 replies; 6+ messages in thread From: Hal Daume III @ 2003-01-14 0:08 UTC (permalink / raw) To: Caml Mailing List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] unboxing of unary datatypes 2003-01-14 0:08 [Caml-list] unboxing of unary datatypes Hal Daume III @ 2003-01-14 4:38 ` Nicolas Cannasse 2003-01-14 11:17 ` Florian Hars 2003-01-14 9:57 ` Fabrice Le Fessant 1 sibling, 1 reply; 6+ messages in thread From: Nicolas Cannasse @ 2003-01-14 4:38 UTC (permalink / raw) To: Hal Daume III, Caml Mailing List > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] unboxing of unary datatypes 2003-01-14 4:38 ` Nicolas Cannasse @ 2003-01-14 11:17 ` Florian Hars 2003-01-14 15:15 ` Nicolas Cannasse 0 siblings, 1 reply; 6+ messages in thread From: Florian Hars @ 2003-01-14 11:17 UTC (permalink / raw) To: Nicolas Cannasse; +Cc: Hal Daume III, Caml Mailing List 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] unboxing of unary datatypes 2003-01-14 11:17 ` Florian Hars @ 2003-01-14 15:15 ` Nicolas Cannasse 0 siblings, 0 replies; 6+ messages in thread From: Nicolas Cannasse @ 2003-01-14 15:15 UTC (permalink / raw) To: Florian Hars; +Cc: Hal Daume III, Caml Mailing List > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] unboxing of unary datatypes 2003-01-14 0:08 [Caml-list] unboxing of unary datatypes Hal Daume III 2003-01-14 4:38 ` Nicolas Cannasse @ 2003-01-14 9:57 ` Fabrice Le Fessant 2003-01-14 11:19 ` Christophe Raffalli 1 sibling, 1 reply; 6+ messages in thread From: Fabrice Le Fessant @ 2003-01-14 9:57 UTC (permalink / raw) To: Hal Daume III; +Cc: Caml Mailing List > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Caml-list] unboxing of unary datatypes 2003-01-14 9:57 ` Fabrice Le Fessant @ 2003-01-14 11:19 ` Christophe Raffalli 0 siblings, 0 replies; 6+ messages in thread From: Christophe Raffalli @ 2003-01-14 11:19 UTC (permalink / raw) To: fabrice; +Cc: Hal Daume III, Caml Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-14 18:38 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-01-14 0:08 [Caml-list] unboxing of unary datatypes Hal Daume III 2003-01-14 4:38 ` Nicolas Cannasse 2003-01-14 11:17 ` Florian Hars 2003-01-14 15:15 ` Nicolas Cannasse 2003-01-14 9:57 ` Fabrice Le Fessant 2003-01-14 11:19 ` Christophe Raffalli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).