Conversation

Charlotte lotteheartplural/Cinny cinny_heart_plural thetadelta ursaminor treblesand

today’s episode in “x86 was a mistake”: “alignment doesn’t matter”

add that to the list of things with “the x86 isn’t big endian sometimes” and “x86 has a stricter memory ordering than swiss train timetables”

1
1
6

alignment matters because outside of x86:

  • misaligned memory access are slower (sometimes only 2-3x, sometimes requiring taking a trap into the kernel which emulates the read)
  • may not be atomic where aligned access would be
  • may not be available as atomic accesses at all

nvm there are x86 instructions that require strict alignment (simd instructions)

big endian has issues now because everything is written exclusively for little endian systems

x86’s memory ordering is total store order, meaning that writes have identical order between cores and hardware threads. that does mean that a lot of instructions are already atomic, but at the same time the relative order of stores between threads is unspecified? just that they are consistent. Other ISAs have way weaker requirements (requiring explicit barriers to make sure that reads and writes can’t cross the instruction). in a way x86 has a read fence before stores and a read-write fence after stores

1
1
3

@charlotte EVERY time I discovered I had accidentally caused a misaligned read it was because I had switched to using a SIMD instruction, because no other instructions care about alignment!!!!

1
0
0
@cloudhop there's always the question *how* they become misaligned because even in c that at the very least requires arithmetic on a type-punned pointer or vendor extensions
1
0
0

@charlotte or just a custom allocator (which is almost always what happens with me)

0
0
0