Re: there isn't any difference, is there, with unboxed tuples?
Stefan O'Rear wrote:
Semantically, you are absolutely correct. However, there is a very
subtle difference in sharing.
Consider these two functions:
foo (a,b) = (a,b)
bar tuple = tuple
These two functions are denotationally identical, but at runtime one
performs more allocations. If we use unboxed tuples, then the caller
must always allocate if a tuple is needed; thus effectively we always
get the allocation behavior of foo. That is, return unboxing is not
always an optimization! However, it *is* always safe if the tuple is
constructed in the function itself, for then it could not possibly be
shared with anything. Having explicit unboxed tuples in the language
allows this complexity to be moved out of the code generator, which is a
Good Thing. (Incidentally, this is what the CPR analysis is all about -
identifying places where a Constructed Product is Returned.)
hmm. so it might have to be some hypothetical syntax like (... -
{-#UNPACK#-} (a, b)) when in a data type (for some monad definition in
GHC's code, so I don't want to lose performance by boxing it). (Either
that or it might actually be more efficient if it were boxed!) Am I
right that CPR analysis can look at particular functions, but there's no
way for it to change the representation of a function stored in a
data/newtype?
~Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
there isn't any difference, is there, with unboxed tuples?
-- unboxed types in function results are automatically lifted... or what was the term meaning they could be _|_, failing to terminate, (because of the function-ness)? -- unboxed tuples are specially restricted to be only allowed, among useful places, in function results. Therefore (... - ( a, b, c ) ) and (... - (# a, b, c #)) are identical, assuming both are kind-correct (identical in terms of optimization and semantics, not type equality, of course). Is that right? If so, there's never an excuse to use unboxed tuples except to contain unboxed values (because then you don't have the choice of using boxed tuples, which can only contain boxed values of kind *). ~Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: there isn't any difference, is there, with unboxed tuples?
On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote: -- unboxed types in function results are automatically lifted... or what was the term meaning they could be _|_, failing to terminate, (because of the function-ness)? -- unboxed tuples are specially restricted to be only allowed, among useful places, in function results. Therefore (... - ( a, b, c ) ) and (... - (# a, b, c #)) are identical, assuming both are kind-correct (identical in terms of optimization and semantics, not type equality, of course). Is that right? If so, there's never an excuse to use unboxed tuples except to contain unboxed values (because then you don't have the choice of using boxed tuples, which can only contain boxed values of kind *). Semantically, you are absolutely correct. However, there is a very subtle difference in sharing. Consider these two functions: foo (a,b) = (a,b) bar tuple = tuple These two functions are denotationally identical, but at runtime one performs more allocations. If we use unboxed tuples, then the caller must always allocate if a tuple is needed; thus effectively we always get the allocation behavior of foo. That is, return unboxing is not always an optimization! However, it *is* always safe if the tuple is constructed in the function itself, for then it could not possibly be shared with anything. Having explicit unboxed tuples in the language allows this complexity to be moved out of the code generator, which is a Good Thing. (Incidentally, this is what the CPR analysis is all about - identifying places where a Constructed Product is Returned.) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
