RE: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary
| I'm confused. GHC of course unboxes strict fields of primitive data types.
|
| {-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-}
|
| ... but only when you give -funbox-strict-fields, as there, or UNPACK.
| The point is that it never loses sharing to unbox a strict Int field
| [1], so it should do that with -O, even without either of the above
| overrides.
|
| [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.
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary
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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary
Hello Andrew, Tuesday, May 20, 2008, 11:05:52 PM, you wrote: -funbox-strict-fields. I did try that, but it didn't seem to make any difference for me. [Maybe it may be that ghc just not recompiled program when you supplied this switch. as i wrote, this switch by itself made your original program 1.5x faster on my box. try to delete .o/.exe before rebuilding and, without this switch representation for !Int32 is the same as for Int32 - only difference is that when data is assigned to such field they are evaluated first (and then boxed) it is not enabled by default, because for *non-primitive* datatypes such as B below automatic unboxing of strict fields of this type may decrease sharing and thus memory/performance. imagine for example: data A = A !B !B data B = B !Int !Int !Int !Int !Int b = B 1 1 1 1 1 a = A b b jhc automatically unboxes strict fields of primitive datatypes, which is guaranteed to provide only positive effects. may be somesay the same will be added to ghc -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary
bulat.ziganshin:
Hello Andrew,
Tuesday, May 20, 2008, 11:05:52 PM, you wrote:
-funbox-strict-fields.
I did try that, but it didn't seem to make any difference for me. [Maybe
it may be that ghc just not recompiled program when you supplied this
switch. as i wrote, this switch by itself made your original program
1.5x faster on my box. try to delete .o/.exe before rebuilding
and, without this switch representation for !Int32 is the same as for
Int32 - only difference is that when data is assigned to such field
they are evaluated first (and then boxed)
it is not enabled by default, because for *non-primitive* datatypes
such as B below automatic unboxing of strict fields of this type may
decrease sharing and thus memory/performance. imagine for example:
data A = A !B !B
data B = B !Int !Int !Int !Int !Int
b = B 1 1 1 1 1
a = A b b
jhc automatically unboxes strict fields of primitive datatypes, which
is guaranteed to provide only positive effects. may be somesay the
same will be added to ghc
I'm confused. GHC of course unboxes strict fields of primitive data types.
{-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields #-}
data A = A !B !B
data B = B !Int !Int !Int !Int !Int
b = B 1 2 3 4 5
a = A b b
go :: Int - A
go 0 = a
go n = go (n-1)
main = print $ case go 10 of
A (B a b c d e) (B a' b' c' d' e') - a + b + c + d + e
+ a' + b' + c' + d' + e'
For example, go compiles to:
$wgo :: Int#
- (# Int#,
Int#,
Int#,
Int#,
Int#,
Int#,
Int#,
Int#,
Int#,
Int# #)
$wgo =
\ (ww_svf :: Int#) -
case ww_svf of ds_Xmw {
__DEFAULT - $wgo (-# ds_Xmw 1);
0 - (# 1, 2, 3, 4, 5, 1, 2, 3, 4, 5 #)
Values are passed in registers, the structures are entirely unpacked into
registers or stack for return.
Were you not aware of this Bulat?
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MD5 performance optimizations, and GHC -via-C producing segfaulting binary
isaacdupree:
Don Stewart wrote:
I'm confused. GHC of course unboxes strict fields of
primitive data types.
{-# OPTIONS -O2 -fvia-C -optc-O2 -funbox-strict-fields
#-}
... but only when you give -funbox-strict-fields, as there,
or UNPACK. The point is that it never loses sharing to unbox
a strict Int field [1], so it should do that with -O, even
without either of the above overrides.
[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?
See section 8.12.10. UNPACK pragma:
if the T constructor is scrutinised and the floats passed to a
non-strict function for example, they will have to be reboxed
That said, the strictness analyser is beefy enough, and strict data
structures commone enough, that this seems to almost ubiquitously be a
win.
Enabling it at -O or -O2 makes perfect sense.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
