Why align all pinned array payloads on 16 bytes?

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

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

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

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

Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow : 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? mallocForeignPtrBytes is defined in terms of malloc (
https://www.haskell.org/onlinereport/haskell2010/haskellch29.html#x37-284000...),
which in turn has the following guarantee (
https://www.haskell.org/onlinereport/haskell2010/haskellch31.html#x39-287000...
):
"... 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...),
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.

Thanks for all the answers. Another surprising thing about the pinned object
allocation primops is that the aligned allocator allows alignment to bytes,
rather than to words (the documentation doesn't say whether it's words or bytes,
but it can be seen from the code that it's actually aligning to the given
byte). Is there a use case for this or people mostly use alignment on word
boundaries?
Ömer
Sven Panne
Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow
: 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?
mallocForeignPtrBytes is defined in terms of malloc (https://www.haskell.org/onlinereport/haskell2010/haskellch29.html#x37-284000...), which in turn has the following guarantee (https://www.haskell.org/onlinereport/haskell2010/haskellch31.html#x39-287000...):
"... 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...), 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.

I don't imagine anyone wants to align to anything that's not a power of 2,
or less than a word size. Still, unless the current generality results in
extra complication or overheads I wouldn't change it.
On Mon, 22 Oct 2018 at 11:44, Ömer Sinan Ağacan
Thanks for all the answers. Another surprising thing about the pinned object allocation primops is that the aligned allocator allows alignment to bytes, rather than to words (the documentation doesn't say whether it's words or bytes, but it can be seen from the code that it's actually aligning to the given byte). Is there a use case for this or people mostly use alignment on word boundaries?
Ömer
Sven Panne
, 17 Eki 2018 Çar, 10:29 tarihinde şunu yazdı: Am Di., 16. Okt. 2018 um 23:18 Uhr schrieb Simon Marlow <
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?
mallocForeignPtrBytes is defined in terms of malloc ( https://www.haskell.org/onlinereport/haskell2010/haskellch29.html#x37-284000...), which in turn has the following guarantee ( https://www.haskell.org/onlinereport/haskell2010/haskellch31.html#x39-287000... ):
"... All storage allocated by functions that allocate based on a size in bytes must be sufficiently aligned for any of the basic foreign types
marlowsd@gmail.com>: 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...), 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.
participants (5)
-
Alexander Kjeldaas
-
Carter Schonwald
-
Simon Marlow
-
Sven Panne
-
Ömer Sinan Ağacan