MD5 performance optimizations, and GHC -via-C producing segfaulting binary

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary

Isaac Dupree
Simon Peyton-Jones wrote:
> | [1] I'm not sure if this is true... if it has to rebox the Int, you get
> | another copy floating around, not the original, right?
>
> Correct.  If you have
>
>         data T = MkT {-# UNPACK #-} !Int
> then given
>         case x of { MkT y -> h y }
> then GHC must re-box the 'y' before passing it to h.  That's why unpacking strict fields isn't an unambiguous win.  Perhaps it should be the default, though, which can be switched off, rather than the reverse.

perhaps there are certain types that the compiler almost always manages
to pass around unboxed -- Ints, for example?  (Or at least that the
extra copies aren't likely to persist for a long time, wasting some
memory. Especially not if they're always unboxed in strict fields --
except for strict polymorphic fields, unfortunately.) And other types
that aren't usually passed around unboxed?  If this is clear, then maybe
it's useful to do it by default for those types.  Perhaps there should
be a {-# NOUNPACK #-} pragma just in case someone wants to make sure a
strict field isn't represented unboxed (not even if you give
-funbox-strict-fields).

-Isaac
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12