The Glasgow Haskell Users Mailing List

Johan Tibell | 7 Dec 2012 00:47

Picon

Which of the following PrimTyCons have a pointer-sized representations

Hi,

As part of some work I'm doing I need to classify all PrimTyCons by
the size of their representation as fields*. I need to classify them
into two classes: pointer-sized (or smaller) and
larger-than-pointer-sized. I've managed to figure out a bunch of them
myself:

Pointer-sized:

addrPrimTyCon
arrayPrimTyCon
byteArrayPrimTyCon  -- Represented as a pointer to heap object
arrayArrayPrimTyCon  -- Represented as a pointer to heap object
charPrimTyCon
doublePrimTyCon  -- Only on 64-bit
floatPrimTyCon
intPrimTyCon
int32PrimTyCon
int64PrimTyCon  -- Only on 64-bit
mutableArrayPrimTyCon  -- Represented as a pointer to heap object
mutableByteArrayPrimTyCon  -- Represented as a pointer to heap object
mutableArrayArrayPrimTyCon  -- Represented as a pointer to heap object
wordPrimTyCon
word32PrimTyCon
word64PrimTyCon  -- Only on 64-bit

These ones I need help with:

bcoPrimTyCon

(Continue reading)

Simon Peyton-Jones | 7 Dec 2012 12:36

Picon

RE: Which of the following PrimTyCons have a pointer-sized representations

You can use TyCon.tyConPrimRep, followed by primRepSizeW

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-
| users-bounces <at> haskell.org] On Behalf Of Johan Tibell
| Sent: 06 December 2012 23:47
| To: glasgow-haskell-users
| Subject: Which of the following PrimTyCons have a pointer-sized
| representations
| 
| Hi,
| 
| As part of some work I'm doing I need to classify all PrimTyCons by the
| size of their representation as fields*. I need to classify them into
| two classes: pointer-sized (or smaller) and larger-than-pointer-sized.
| I've managed to figure out a bunch of them
| 
| myself:
| 
| Pointer-sized:
| 
| addrPrimTyCon
| arrayPrimTyCon
| byteArrayPrimTyCon  -- Represented as a pointer to heap object
| arrayArrayPrimTyCon  -- Represented as a pointer to heap object
| charPrimTyCon doublePrimTyCon  -- Only on 64-bit floatPrimTyCon
| intPrimTyCon int32PrimTyCon int64PrimTyCon  -- Only on 64-bit
| mutableArrayPrimTyCon  -- Represented as a pointer to heap object

(Continue reading)

Johan Tibell | 7 Dec 2012 19:48

Picon

Re: Which of the following PrimTyCons have a pointer-sized representations

On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
<simonpj <at> 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

(Continue reading)

Johan Tibell | 7 Dec 2012 23:10

Picon

Re: Which of the following PrimTyCons have a pointer-sized representations

On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
> On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
> <simonpj <at> 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

(Continue reading)

Simon Peyton-Jones | 11 Dec 2012 13:29

Picon

RE: Which of the following PrimTyCons have a pointer-sized representations

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

	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. 

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.

I'll commit shortly and you can look

Simon

| -----Original Message-----

(Continue reading)

Simon Marlow | 11 Dec 2012 15:50

Picon

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.
>

(Continue reading)

Johan Tibell | 11 Dec 2012 17:01

Picon

Re: Which of the following PrimTyCons have a pointer-sized representations

Simon,

On Tue, Dec 11, 2012 at 4:29 AM, Simon Peyton-Jones
<simonpj <at> 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

(Continue reading)

Simon Peyton-Jones | 11 Dec 2012 22:02

Picon

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

Johan Tibell | 11 Dec 2012 22:31

Picon

Re: Which of the following PrimTyCons have a pointer-sized representations

On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones
<simonpj <at> 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.

(Continue reading)

Simon Marlow | 12 Dec 2012 14:27

Picon

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
> <simonpj <at> 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

(Continue reading)

Johan Tibell | 12 Dec 2012 18:33

Picon

Re: Which of the following PrimTyCons have a pointer-sized representations

On Wed, Dec 12, 2012 at 5:27 AM, Simon Marlow <marlowsd <at> gmail.com> wrote:
> On 11/12/12 21:31, Johan Tibell wrote:
>> On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones
>> <simonpj <at> 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

(Continue reading)

Return

Return to gmane.comp.lang.haskell.glasgow.user.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane