Re: Which of the following PrimTyCons have a pointer-sized representations
On 11/12/12 21:31, Johan Tibell wrote: On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | data T = MkT !S | data S = MkS Int | | then my impl will unbox the S field of MkT because the result is only one field | wide, namely an Int. | | Wouldn't Johan's have unboxed S too? (if not, I misunderstood what he did) No, that would change the semantics! We don't want to do that. I think Simon M meant that my change would have unpacked the field of *type* S in the MkT constructor. We must not unpack the field in the MkS constructor. Correct, sorry for not being clear enough. | I'm happy to call this -funbox-strict-small-fields. However, I'd like | the documentation to talk about pointer-sized things as that, even | though a bit operational sounding, has a clear meaning in my mind. I'm somewhat inclined to *change* the current flag so that -funbox-strict-fields means unbox small fields -funbox-all-strict-fields means unbox ALL strict fields Lets go with -funbox-small-strict-fields to avoid unnecessary breakages. If we end up enabling this flag by default eventually it doesn't really matter what the name is as people will never type it out explicitly. +1 There are lots of users of the existing flag, we don't want to change its meaning. Cheers, Simon ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
Re: Which of the following PrimTyCons have a pointer-sized representations
On Wed, Dec 12, 2012 at 5:27 AM, Simon Marlow marlo...@gmail.com wrote: On 11/12/12 21:31, Johan Tibell wrote: On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | I'm happy to call this -funbox-strict-small-fields. However, I'd like | the documentation to talk about pointer-sized things as that, even | though a bit operational sounding, has a clear meaning in my mind. I'm somewhat inclined to *change* the current flag so that -funbox-strict-fields means unbox small fields -funbox-all-strict-fields means unbox ALL strict fields Lets go with -funbox-small-strict-fields to avoid unnecessary breakages. If we end up enabling this flag by default eventually it doesn't really matter what the name is as people will never type it out explicitly. +1 There are lots of users of the existing flag, we don't want to change its meaning. Simon PJ, do you want me to rename the flag to -funbox-small-strict-fields or do you want to do it? If you do it, don't forget to update the documentation as well. -- Johan ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
Re: Which of the following PrimTyCons have a pointer-sized representations
On 11/12/12 12:29, Simon Peyton-Jones wrote: Johan, Well, I started to review your patch. And then I re-discovered how horribly messy that code is; with independent decisions taken in the desugarer, MkId, and TcTyClsDcls, all of which must line up. So I totally refactored everything which cost me a couple of days (because it has quite wide span). I'm validating now. I realise that unbox-strict-fields means unbox it if it's strict, whereas your new unbox-strict-primitive-fields is the same but a bit less aggressive: unbox it if it's strict, AND the unboxed version is at most one word wide Where a Float or Double count as one word. So I changed it to ...AND the unboxed version is at most one field wide. That is we get one field not 2 or 10. So consider What is a field? data T = MkT !S data S = MkS Int then my impl will unbox the S field of MkT because the result is only one field wide, namely an Int. Wouldn't Johan's have unboxed S too? (if not, I misunderstood what he did) It would be easy to also restrict to *primitive* types, but it seems mildly beneficial not to. However the flag is then a mis-nomer. Right, I had been wondering whether -funbox-strict-small-fields or something would make a better name, since it isn't restricted to primitive types. Cheers, Simon I'll commit shortly and you can look Simon | -Original Message- | From: Johan Tibell [mailto:johan.tib...@gmail.com] | Sent: 07 December 2012 22:10 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users | Subject: Re: Which of the following PrimTyCons have a pointer-sized | representations | | On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell johan.tib...@gmail.com | wrote: | On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones | simo...@microsoft.com wrote: | You can use TyCon.tyConPrimRep, followed by primRepSizeW | | Looking at primRepSizeW I see that the only PrimRep that is bigger | than one word is Doubles, Int64s, and Word64s on 32-bit platforms. | Manuel (I think wisely) suggested that we should make an exception for | these types and unpack them on 32-bit platforms if | -funbox-strict-primitive-fields is set, even thought technically they | will occupy more space than a pointer. The reasoning is that we want | to avoid surprising behavior when users move code between 32-bit and | 64-bit platforms, as e.g. unpacking vs not-unpacking Doubles can make | a large difference in certain tight loops. | | But this means that checking the size in can_unbox_prim is no longer | necessary, so I could remove that check. This does mean that if we | ever add a new PrimTyCon that has a size that's larger than a pointer, | the implementation of -funbox-strict-primitive-fields has to change. | | The alternative would be for me to add | | primRepSizeForUnboxW :: PrimRep - Int | primRepSizeForUnboxW IntRep = 1 | primRepSizeForUnboxW WordRep = 1 | primRepSizeForUnboxW Int64Rep = 1-- [Note: Primitive size | exception] | primRepSizeForUnboxW Word64Rep= 1-- [Note: Primitive size | exception] | primRepSizeForUnboxW FloatRep = 1-- NB. might not take a full word | primRepSizeForUnboxW DoubleRep= 1-- [Note: Primitive size | exception] | primRepSizeForUnboxW AddrRep = 1 | primRepSizeForUnboxW PtrRep = 1 | primRepSizeForUnboxW VoidRep = 0 | | And use that function in can_unbox_prim. That way we'd get a pattern | match warning if we ever add a new PrimRep (and thus need to evaluate | if PrimTyCons with that PrimRep should be unpacked by | -funbox-strict-primitive-fields). | | I went with the latter approach as it seems safer. | | -- Johan ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
Re: Which of the following PrimTyCons have a pointer-sized representations
Simon, On Tue, Dec 11, 2012 at 4:29 AM, Simon Peyton-Jones simo...@microsoft.com wrote: So I totally refactored everything which cost me a couple of days (because it has quite wide span). I'm validating now. Yay for code clean-ups! So I changed it to ...AND the unboxed version is at most one field wide. That is we get one field not 2 or 10. So consider data T = MkT !S data S = MkS Int then my impl will unbox the S field of MkT because the result is only one field wide, namely an Int. This is the behavior I desired. If it didn't work that way in my implementation it was an oversight. Another way to define the desired behavior is to say it preserves the size of the constructor (if we ignore the Double/Int64/Word64 special case of 32-bit architectures). This property is what I hope will make it possible to enable this by default (after extensive testing). I'm happy to call this -funbox-strict-small-fields. However, I'd like the documentation to talk about pointer-sized things as that, even though a bit operational sounding, has a clear meaning in my mind. -- Johan ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
RE: Which of the following PrimTyCons have a pointer-sized representations
| data T = MkT !S | data S = MkS Int | | then my impl will unbox the S field of MkT because the result is only one field | wide, namely an Int. | | Wouldn't Johan's have unboxed S too? (if not, I misunderstood what he did) No, that would change the semantics! We don't want to do that. | I'm happy to call this -funbox-strict-small-fields. However, I'd like | the documentation to talk about pointer-sized things as that, even | though a bit operational sounding, has a clear meaning in my mind. I'm somewhat inclined to *change* the current flag so that -funbox-strict-fields means unbox small fields -funbox-all-strict-fields means unbox ALL strict fields And as you say to make -funbox-strict-fields implied by -O. But I do not feel strongly at all. You represent users; you decide. (or anyone else can pipe up). Simon ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
Re: Which of the following PrimTyCons have a pointer-sized representations
On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | data T = MkT !S | data S = MkS Int | | then my impl will unbox the S field of MkT because the result is only one field | wide, namely an Int. | | Wouldn't Johan's have unboxed S too? (if not, I misunderstood what he did) No, that would change the semantics! We don't want to do that. I think Simon M meant that my change would have unpacked the field of *type* S in the MkT constructor. We must not unpack the field in the MkS constructor. | I'm happy to call this -funbox-strict-small-fields. However, I'd like | the documentation to talk about pointer-sized things as that, even | though a bit operational sounding, has a clear meaning in my mind. I'm somewhat inclined to *change* the current flag so that -funbox-strict-fields means unbox small fields -funbox-all-strict-fields means unbox ALL strict fields Lets go with -funbox-small-strict-fields to avoid unnecessary breakages. If we end up enabling this flag by default eventually it doesn't really matter what the name is as people will never type it out explicitly. And as you say to make -funbox-strict-fields implied by -O. I was going to not enable this by default in 7.8 and spend some time after the 7.8 release to run a bunch of benchmarks to try to decide whether it's a win on average. If you think that we should enable it by default already in 7.8 we can do that. -- Johan ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
