I totally agree. Getting the value of the field should just evaluate x and then use a pointer indirection; there should be no conditional jumps involved in getting the value. GHC is just doing the wrong thing. -- Lennart On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead wrote:

On Wednesday 15 October 2008 10:48:26 you wrote:

...

Strictness does not imply unboxing.

To see why not, think about the fact that unboxing breaks sharing. By keeping the pointer-indirection in place, we can share even strict fields between related values.

I believe I realize that. What I was wondering about was the fact that it seemed to think the pointer might be to a thunk (instead of constructor closure). Doesn't the strictness flag mean the following assembler would work

sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) jmp snj_info

(which could be cleaned up further by combining it with snj_info) instead of

sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx)

(i.e., the whole test if it is a thunk and conditionally evaluate it bit is unnecessary due to constructor the strictness flag).

Cheers! -Tyson _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

True, if there can be indirections then that's bad news. That would make strict fields much less efficient. But I don't see why indirections should be needed. Simon? On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen wrote:

On Oct 15, 2008, at 11:08 AM, Lennart Augustsson wrote:

...

I totally agree. Getting the value of the field should just evaluate x and then use a pointer indirection; there should be no conditional jumps involved in getting the value. GHC is just doing the wrong thing.

Can indirection nodes occur in this context? [I'd think not, but it depends on what pointer we're storing when we force the thunk in the constructor.] I could see the need for the test if indirection handling is required.

-Jan

...

-- Lennart

On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead wrote:

...

On Wednesday 15 October 2008 10:48:26 you wrote:

...

Strictness does not imply unboxing.

To see why not, think about the fact that unboxing breaks sharing. By keeping the pointer-indirection in place, we can share even strict fields between related values.

I believe I realize that. What I was wondering about was the fact that it seemed to think the pointer might be to a thunk (instead of constructor closure). Doesn't the strictness flag mean the following assembler would work

sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) jmp snj_info

(which could be cleaned up further by combining it with snj_info) instead of

sni_info: movq 7(%rbx),%rbx movq $snj_info,(%rbp) testq $7,%rbx jne snj_info jmp *(%rbx)

(i.e., the whole test if it is a thunk and conditionally evaluate it bit is unnecessary due to constructor the strictness flag).

Cheers! -Tyson _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

| I totally agree. Getting the value of the field should just evaluate | x and then use a pointer indirection; there should be no conditional | jumps involved in getting the value. | GHC is just doing the wrong thing. You're right. As Simon says, GHC's Core language has no type distinction between an Int that is evaluated and an Int that might be a thunk, so we generate conservative code. However, even for strict functions we do not *guarantee* to pass evaluated arguments. Consider f x y = if y==0 then g x else 0 g x = x+1 Here g is strict, but f is not (in x). The code that GHC generates for 'f' simply passes 'x' along to 'g'. It does not evaluate 'x' and then pass it. So the fact that 'g' is strict is used to *allow* the caller to use call by value; it does not *require* the caller to do so. So that means that 'g' cannot rely on getting an evaluated argument. One could change that, but that's the way it is right now. For strict *constructors*, on the other hand, we *do* guarantee to evaluate the argument before building the constructor. We generate a wrapper thus wC = \ab. case a of { a' -> C a' b } (Remember 'case' always evaluates in Core.) So for strict constructors we could take advantage of the known evaluated-ness of the result to avoid the test. BUT people who care probably UNPACK their strict fields too, which is even better. The time you can't do that is for sum types data T = MkT ![Int] Whether this case is important enough to be worth the complexity cost, I'm not sure. If someone felt like creating a ticket for this thread, and pasting in the payload of the messages, that'd help us not to forget it. As of now, it doesn't look like a terribly big win to me. But I could be wrong -- intuition is not always a good guide. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Lennart Augustsson | Sent: 15 October 2008 16:09 | To: Tyson Whitehead | Cc: GHC users | Subject: Re: Strictness in data declaration not matched in assembler? | | I totally agree. Getting the value of the field should just evaluate | x and then use a pointer indirection; there should be no conditional | jumps involved in getting the value. | GHC is just doing the wrong thing. | | -- Lennart | | On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead wrote: | > On Wednesday 15 October 2008 10:48:26 you wrote: | >> Strictness does not imply unboxing. | >> | >> To see why not, think about the fact that unboxing breaks sharing. By | >> keeping the pointer-indirection in place, we can share even strict | >> fields between related values. | > | > I believe I realize that. What I was wondering about was the fact that it | > seemed to think the pointer might be to a thunk (instead of constructor | > closure). Doesn't the strictness flag mean the following assembler would work | > | > sni_info: | > movq 7(%rbx),%rbx | > movq $snj_info,(%rbp) | > jmp snj_info | > | > (which could be cleaned up further by combining it with snj_info) instead of | > | > sni_info: | > movq 7(%rbx),%rbx | > movq $snj_info,(%rbp) | > testq $7,%rbx | > jne snj_info | > jmp *(%rbx) | > | > (i.e., the whole test if it is a thunk and conditionally evaluate it bit is | > unnecessary due to constructor the strictness flag). | > | > Cheers! -Tyson | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

| > BUT people who care probably UNPACK their strict fields too, which | > is even better. The time you can't do that is for sum types | > data T = MkT ![Int] | | You also can't do it for polymorphic components. I've used code like: | | data T a = MkT !a | | foo :: T (a,b) -> a | foo (MkT (x,y)) = x | | Here, unpacking doesn't work but foo could still access the components | of the pair directly. Excellent point Roman. S

twhitehead:

On Thursday 16 October 2008 07:03:05 Roman Leshchinskiy wrote:

...

On 16/10/2008, at 21:34, Simon Peyton-Jones wrote:

...

BUT people who care probably UNPACK their strict fields too, which is even better. The time you can't do that is for sum types data T = MkT ![Int]

You also can't do it for polymorphic components. I've used code like:

data T a = MkT !a

foo :: T (a,b) -> a foo (MkT (x,y)) = x

Here, unpacking doesn't work but foo could still access the components of the pair directly.

This is actually the situation I was originally looking at. I just simplified it for the sake of posting readable core and assembler.

Specifically, I was looking at some of the assembler GHC was generating for some array code to see if it could do a clean enough job to be used instead of C, and was finding this sort of thing because STUArrau is defined as

data STUArray s i a = STUArray !i !i !Int (MutableByteArray# s)

FWIW, I get much nicer code with uvector (which uses type families to select monomorphic instances of things, and aggressive inlining, to yield much better code in practice). The DPH arrays library uses a similar method. So you might make some progress by taking that direction. -- Don

twhitehead:

On Thursday 16 October 2008 14:34:01 Don Stewart wrote:

...

FWIW, I get much nicer code with uvector (which uses type families to select monomorphic instances of things, and aggressive inlining, to yield much better code in practice). The DPH arrays library uses a similar method.

Thanks for the hint Don! : )

I've had a look at the documentation, and I'll hopefully give it a try soon.

Cheers! -Tyson

PS: Is the document still up-to-date with regards to recommending via c?

Yep, but you can always experiment with -fasm -- Don