You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On various architectures, particularly RISC, alignment faults get thrown on unaligned access. This either causes software emulation of unaligned access (with a lot of overhead due to the interrupt) or crashes.
It's easy to find the places where we need to add alignment support - it's all the use of Storable instances, which come with alignment info. To support this, we can probably just have the encoder / decoder for these skip forward enough padding bytes to reach an aligned address. A pretty easy fix!
It relies on all of the alignment values being a divisor of the buffer's alignment. In other words, bufferOffsetmodalignment x == 0 must be true for all of the alignments used. Otherwise, we're going to have trouble with reliable encoding / decoding. While we can add some asserts for this, I don't think this assumption will be violated in practice.
This alignment stuff gets more complicated with support for machine independent serialization. See #36 . We'd want the machine independent instances to know how to use aligned accesses to simulate an unaligned access.
PowerPC Specific
Not sure how much demand there is for PowerPC support, but we probably already support it. store is currently buildable: false on PowerPC, because there are a few things with the potential to have pathologically poor performance.
In this comment, hvr points out an interesting article about devastating performance with unaligned access:
Here's a good couple paragraphs from the article:
The PowerPC takes a hybrid approach. Every PowerPC processor to date has hardware support for unaligned 32-bit integer access. While you still pay a performance penalty for unaligned access, it tends to be small.
On the other hand, modern PowerPC processors lack hardware support for unaligned 64-bit floating-point access. When asked to load an unaligned floating-point number from memory, modern PowerPC processors will throw an exception and have the operating system perform the alignment chores in software. Performing alignment in software is much slower than performing it in hardware.
So it looks like for the specific case of PPC, we could continue doing unaligned access of most things, but ensure aligned access of Double. What about Int64? It's surprising to me that this would affect Double but not Int64
The text was updated successfully, but these errors were encountered:
On various architectures, particularly RISC, alignment faults get thrown on unaligned access. This either causes software emulation of unaligned access (with a lot of overhead due to the interrupt) or crashes.
It's easy to find the places where we need to add alignment support - it's all the use of
Storable
instances, which come withalignment
info. To support this, we can probably just have the encoder / decoder for these skip forward enough padding bytes to reach an aligned address. A pretty easy fix!It relies on all of the
alignment
values being a divisor of the buffer's alignment. In other words,bufferOffset
modalignment x == 0
must be true for all of the alignments used. Otherwise, we're going to have trouble with reliable encoding / decoding. While we can add some asserts for this, I don't think this assumption will be violated in practice.This alignment stuff gets more complicated with support for machine independent serialization. See #36 . We'd want the machine independent instances to know how to use aligned accesses to simulate an unaligned access.
PowerPC Specific
Not sure how much demand there is for PowerPC support, but we probably already support it.
store
is currentlybuildable: false
on PowerPC, because there are a few things with the potential to have pathologically poor performance.In this comment, hvr points out an interesting article about devastating performance with unaligned access:
Here's a good couple paragraphs from the article:
So it looks like for the specific case of PPC, we could continue doing unaligned access of most things, but ensure aligned access of
Double
. What aboutInt64
? It's surprising to me that this would affectDouble
but notInt64
The text was updated successfully, but these errors were encountered: