Why align all pinned array payloads on 16 bytes?

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

Why align all pinned array payloads on 16 bytes?

Ömer Sinan Ağacan
Hi,

I just found out we currently align all pinned array payloads to 16 bytes and
I'm wondering why. I don't see any comments/notes on this, and it's also not
part of the primop documentation. We also have another primop for aligned
allocation: newAlignedPinnedByteArray#. Given that alignment behavior of
newPinnedByteArray# is not documented and we have another one for aligned
allocation, perhaps we can remove alignment in newPinnedByteArray#.

Does anyone remember what was the motivation for always aligning pinned arrays?

Thanks

Ömer
_______________________________________________
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: Why align all pinned array payloads on 16 bytes?

Carter Schonwald
while I dont know the original context, some care may be needed ... depending on how this alignment assumption is accidentally used by users... it may result in really gross breakages

On Thu, Oct 11, 2018 at 1:44 PM Ömer Sinan Ağacan <[hidden email]> wrote:
Hi,

I just found out we currently align all pinned array payloads to 16 bytes and
I'm wondering why. I don't see any comments/notes on this, and it's also not
part of the primop documentation. We also have another primop for aligned
allocation: newAlignedPinnedByteArray#. Given that alignment behavior of
newPinnedByteArray# is not documented and we have another one for aligned
allocation, perhaps we can remove alignment in newPinnedByteArray#.

Does anyone remember what was the motivation for always aligning pinned arrays?

Thanks

Ömer
_______________________________________________
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: Why align all pinned array payloads on 16 bytes?

Simon Marlow-7
In reply to this post by Ömer Sinan Ağacan
I vaguely recall that this was because 16 byte alignment is the minimum you need for certain foreign types, and it's what malloc() does.  Perhaps check the FFI spec and the guarantees that mallocForeignPtrBytes and friends provide?

Cheers
Simon

On Thu, 11 Oct 2018 at 18:44, Ömer Sinan Ağacan <[hidden email]> wrote:
Hi,

I just found out we currently align all pinned array payloads to 16 bytes and
I'm wondering why. I don't see any comments/notes on this, and it's also not
part of the primop documentation. We also have another primop for aligned
allocation: newAlignedPinnedByteArray#. Given that alignment behavior of
newPinnedByteArray# is not documented and we have another one for aligned
allocation, perhaps we can remove alignment in newPinnedByteArray#.

Does anyone remember what was the motivation for always aligning pinned arrays?

Thanks

Ömer
_______________________________________________
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: Why align all pinned array payloads on 16 bytes?

Alexander Kjeldaas

The SSE types require 16-byte alignment.  Most of the original SSE instructions have versions that accept non-aligned data though.

Alexander

On Tue, Oct 16, 2018 at 11:18 PM Simon Marlow <[hidden email]> wrote:
I vaguely recall that this was because 16 byte alignment is the minimum you need for certain foreign types, and it's what malloc() does.  Perhaps check the FFI spec and the guarantees that mallocForeignPtrBytes and friends provide?

Cheers
Simon

On Thu, 11 Oct 2018 at 18:44, Ömer Sinan Ağacan <[hidden email]> wrote:
Hi,

I just found out we currently align all pinned array payloads to 16 bytes and
I'm wondering why. I don't see any comments/notes on this, and it's also not
part of the primop documentation. We also have another primop for aligned
allocation: newAlignedPinnedByteArray#. Given that alignment behavior of
newPinnedByteArray# is not documented and we have another one for aligned
allocation, perhaps we can remove alignment in newPinnedByteArray#.

Does anyone remember what was the motivation for always aligning pinned arrays?

Thanks

Ömer
_______________________________________________
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

_______________________________________________
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: Why align all pinned array payloads on 16 bytes?

Sven Panne-2
In reply to this post by Simon Marlow-7
Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow <[hidden email]>:
I vaguely recall that this was because 16 byte alignment is the minimum you need for certain foreign types, and it's what malloc() does.  Perhaps check the FFI spec and the guarantees that mallocForeignPtrBytes and friends provide?


   "... All storage allocated by functions that allocate based on a size in bytes must be sufficiently aligned for any of the basic foreign types that fits into the newly allocated storage. ..."

The largest basic foreign types are Word64/Double and probably Ptr/FunPtr/StablePtr (https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1700008.7), so per spec you need at least an 8-byte alignement. But in an SSE-world I would be *very* reluctant to use an alignment less strict than 16 bytes, otherwise people will probably hate you... :-]

Cheers,
   S.

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