I realize that these libraries are used on many architectures.
However, on modern x86 machines, that are less than ~7 years old, it
doesn't seem to matter all that much.
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
In the comments, looks like somewhat older processors take a 40%
performance hit, which isn't good, but it isn't awful.
IIRC, of the processors that are actually used, there are two where
access alignment really matters - ARM and PowerPC. If you're running
linux I believe it will handle the exception and do the unaligned
access. However, of course it's really slow to do this.
I'm not sure if it makes sense to change the law. Someone might be
relying on the behavior of instances that do not fulfill this law.
Perhaps in those cases it makes sense to just remove the instance.
-Michael
On Fri, Dec 15, 2017 at 9:33 PM, David Feuer
The documentation for pokeByteOff indicates that the following equality holds:
pokeElemOff addr idx x = poke (addr `plusPtr` (idx * sizeOf x)) x
Notably, this ignores alignment. It thus seems to imply that sizeOf must always be a multiple of alignment; otherwise, non-zero indices could access non-aligned addresses.
Was this intentional? If so, I believe sizeOf and alignment should document the law. If not, then I believe the {poke,peek}ElemOff laws need to change to something like
pokeElemOff addr idx x = poke (addr `plusPtr` (idx * lcm (sizeOf x) (alignment x))) x
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries