Re: New primitive types?

[Michal Terepeta]

On Sun, Aug 27, 2017 at 7:49 PM Michal Terepeta 
wrote:

> > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry  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.
>

Just FYI: I've opened:
https://github.com/ghc-proposals/ghc-proposals/pull/74

Cheers,
Michal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 
wrote:

> > On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry  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
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Michal Terepeta]

> On Thu, Aug 3, 2017 at 2:28 AM Sylvain Henry  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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Florian Weimer]

* 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[David Feuer]

Atomic operations, or the lack thereof, don't seem terribly relevant to 
immutable Haskell constructor fields.


David FeuerWell-Typed, LLP
 Original message From: Carter Schonwald 
<carter.schonw...@gmail.com> Date: 8/26/17  10:56 PM  (GMT-05:00) To: Florian 
Weimer <f...@deneb.enyo.de>, Michal Terepeta <michal.terep...@gmail.com> Cc: 
ghc-devs <ghc-devs@haskell.org> 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 <f...@deneb.enyo.de> wrote:

> * Michal Terepeta:
>
> > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <
> carter.schonw...@gmail.com>
> > 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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  wrote:

> * Michal Terepeta:
>
> > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald <
> carter.schonw...@gmail.com>
> > 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Florian Weimer]

* Michal Terepeta:

> On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald 
> 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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Sylvain Henry]

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

[1] https://ghc.haskell.org/trac/ghc/ticket/13825
[2] https://phabricator.haskell.org/D3809



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New primitive types?

[Michal Terepeta]

On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald 
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

Have a look at https://ghc.haskell.org/trac/ghc/ticket/13825 which
tracks the progress. The most recent diff is
https://phabricator.haskell.org/D3809

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
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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 <michal.terep...@gmail.com>
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
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/13825
> [2] https://phabricator.haskell.org/D3809
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[1] https://ghc.haskell.org/trac/ghc/ticket/13825
[2] https://phabricator.haskell.org/D3809
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs