New primitive types?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

New primitive types?

Michal Terepeta
Hi all,

I'm working on making it possible to pack constructor fields [1],
example:

```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
```

should only require 4 bytes for unpacked `Float` and 4 bytes for
unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
of 2 it currently does).

The diff to support packing of fields is in review [2], but to really
take advantage of it I think we need to introduce new primitive types:
- Int{8,16,32}#
- Word{8,16,32}#
along with some corresponding primops and with some other follow-up
changes like extending `PrimRep`.

Then we could use them in definitions of `Int{8,16,32}` and
`Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).

Does that sound ok with everyone? (just making sure that this makes
sense before I invest more time into this :)

Thanks,
Michal



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Carter Schonwald
One issue with packed fields is that on many architectures you can't quite do subword reads or  writes.  So it might not always be a win.  

There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized types.  

That said, I do support making word/int64/32 # types more first class / built in.  (I hit some issues which tie into this topic in the process of working on my still in progress safeword package. )

Point being: I support improving what we have, but it's got a bit of surface area.  Please let me know how I can help you dig into this though 

On Tue, Aug 1, 2017 at 9:37 AM Michal Terepeta <[hidden email]> wrote:
Hi all,

I'm working on making it possible to pack constructor fields [1],
example:

```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
```

should only require 4 bytes for unpacked `Float` and 4 bytes for
unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
of 2 it currently does).

The diff to support packing of fields is in review [2], but to really
take advantage of it I think we need to introduce new primitive types:
- Int{8,16,32}#
- Word{8,16,32}#
along with some corresponding primops and with some other follow-up
changes like extending `PrimRep`.

Then we could use them in definitions of `Int{8,16,32}` and
`Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).

Does that sound ok with everyone? (just making sure that this makes
sense before I invest more time into this :)

Thanks,
Michal


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Michal Terepeta
On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <[hidden email]> wrote:
> One issue with packed fields is that on many architectures you can't quite do subword reads or
> writes.  So it might not always be a win.  

Could you give any examples?

Note that we're still going to do aligned read/writes, i.e., `Int32#`
would still be 4 bytes aligned, `Int16#` 2 bytes, etc. So we might
have "holes", e.g., `data Foo = Foo Int8# Int64#` would still waste 7
bytes (since `Int64#` should be 8 bytes aligned).

In the future, I'd also like to do some field reordering to avoid some
holes like that in cases like `Foo Int32# Int64# Int32#` (here it'd be
better if the in-memory layout was `Int64#` first and then the two
`Int32#`s)

> There's also the issue that c-- as it exists in ghc doesn't have any notion of subword sized
> types.  
>
> That said, I do support making word/int64/32 # types more first class / built in.  (I hit some
> issues which tie into this topic in the process of working on my still in progress safeword
> package. )
>
> Point being: I support improving what we have, but it's got a bit of surface area.  Please let me
> know how I can help you dig into this though 

tracks the progress. The most recent diff is

So far, most of this work is based on some unfinished code by Simon
Marlow to support storing constructor fields smaller than words.  I'm
currently mostly finishing/fixing it and splitting to smaller pieces.
Introducing more primitive stuff is the next step. (assuming everyone
is ok with this :)

Cheers,
Michal


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Sylvain Henry-2
In reply to this post by Michal Terepeta

Hi,

I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc.

Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal.

Sylvain


On 01/08/2017 15:37, Michal Terepeta wrote:
Hi all,

I'm working on making it possible to pack constructor fields [1],
example:

```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32
```

should only require 4 bytes for unpacked `Float` and 4 bytes for
unpacked `Int32`, which on 64-bit arch would take just 1 word (instead
of 2 it currently does).

The diff to support packing of fields is in review [2], but to really
take advantage of it I think we need to introduce new primitive types:
- Int{8,16,32}#
- Word{8,16,32}#
along with some corresponding primops and with some other follow-up
changes like extending `PrimRep`.

Then we could use them in definitions of `Int{8,16,32}` and
`Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`).

Does that sound ok with everyone? (just making sure that this makes
sense before I invest more time into this :)

Thanks,
Michal




_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Florian Weimer
In reply to this post by Michal Terepeta
* Michal Terepeta:

> On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <[hidden email]>
> wrote:
>> One issue with packed fields is that on many architectures you can't
> quite do subword reads or
>> writes.  So it might not always be a win.
>
> Could you give any examples?

Historic DEC Alpha, now long obsolete.

It is very hard to create compliant and performant implementations of
Java 5, C 11 or C++ 11 on such architectures.  All these languages
(and their subsequent revisions) require that naturally aligned
objects can be accessed independently.  For example, you can't use a
simple read-modify-write cycle to implement a single-byte store using
word operations.

That's why such architectures really do not have a future (or even a
present), except maybe in niche markets such as GPGPU (but even there,
things are heading towards the de-facto standard memory model).
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Carter Schonwald
Which architectures are which? 

I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear 

On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer <[hidden email]> wrote:
* Michal Terepeta:

> On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <[hidden email]>
> wrote:
>> One issue with packed fields is that on many architectures you can't
> quite do subword reads or
>> writes.  So it might not always be a win.
>
> Could you give any examples?

Historic DEC Alpha, now long obsolete.

It is very hard to create compliant and performant implementations of
Java 5, C 11 or C++ 11 on such architectures.  All these languages
(and their subsequent revisions) require that naturally aligned
objects can be accessed independently.  For example, you can't use a
simple read-modify-write cycle to implement a single-byte store using
word operations.

That's why such architectures really do not have a future (or even a
present), except maybe in niche markets such as GPGPU (but even there,
things are heading towards the de-facto standard memory model).

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

David Feuer-2
In reply to this post by Michal Terepeta
Atomic operations, or the lack thereof, don't seem terribly relevant to immutable Haskell constructor fields.



David Feuer
Well-Typed, LLP

-------- Original message --------
From: Carter Schonwald <[hidden email]>
Date: 8/26/17 10:56 PM (GMT-05:00)
To: Florian Weimer <[hidden email]>, Michal Terepeta <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: New primitive types?

Which architectures are which?

I assume you mean the dec alpha allowed atomic operations on bytes... but
your phrasing is a teeny bit unclear

On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer <[hidden email]> wrote:

> * Michal Terepeta:
>
> > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <
> [hidden email]>
> > wrote:
> >> One issue with packed fields is that on many architectures you can't
> > quite do subword reads or
> >> writes.  So it might not always be a win.
> >
> > Could you give any examples?
>
> Historic DEC Alpha, now long obsolete.
>
> It is very hard to create compliant and performant implementations of
> Java 5, C 11 or C++ 11 on such architectures.  All these languages
> (and their subsequent revisions) require that naturally aligned
> objects can be accessed independently.  For example, you can't use a
> simple read-modify-write cycle to implement a single-byte store using
> word operations.
>
> That's why such architectures really do not have a future (or even a
> present), except maybe in niche markets such as GPGPU (but even there,
> things are heading towards the de-facto standard memory model).
>

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Florian Weimer
In reply to this post by Carter Schonwald
* Carter Schonwald:

> Which architectures are which?
>
> I assume you mean the dec alpha allowed atomic operations on bytes... but
> your phrasing is a teeny bit unclear

Early DEC Alpha had only word access.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Michal Terepeta
In reply to this post by Sylvain Henry-2
> On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry <[hidden email]> wrote:
> Hi,
>
> I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc.
>
> Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal.

Ok, a short proposal sounds reasonable.

I don't think this would break a lot of code - based on a few searches
it seems that people don't really extract `Int#` from
`Int8/Int16/Int32` (similarly with words).
Or am I missing something?

Thanks,
Michal

PS. Sorry for slow reply - I was traveling.


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Carter Schonwald
I think it should be mostly fine... memory alignment is my main bugbear of a worry, but I guess that requires experimentation 😊😊

On Sun, Aug 27, 2017 at 6:50 PM Michal Terepeta <[hidden email]> wrote:
> On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry <[hidden email]> wrote:
> Hi,
>
> I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc.
>
> Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal.

Ok, a short proposal sounds reasonable.

I don't think this would break a lot of code - based on a few searches
it seems that people don't really extract `Int#` from
`Int8/Int16/Int32` (similarly with words).
Or am I missing something?

Thanks,
Michal

PS. Sorry for slow reply - I was traveling.

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: New primitive types?

Michal Terepeta
In reply to this post by Michal Terepeta
On Sun, Aug 27, 2017 at 7:49 PM Michal Terepeta <[hidden email]> wrote:
> On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry <[hidden email]> wrote:
> Hi,
>
> I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc.
>
> Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal.

Ok, a short proposal sounds reasonable.


Cheers,
Michal

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs