3 ms·

Yes? I agree with that. I don't really see the issue there. The computer will allocate data in aligned addresses, so you would have to be doing something weird

by tovej 5mo ago

Yes? I agree with that. I don't really see the issue there. The computer will allocate data in aligned addresses, so you would have to be doing something weird to begin with to access unaligned pointers. And aligned access is always better anyway. I guess packed structs are a thing if you're really byte golfing. Maybe compressed network data would also make sense. But then I would assume you are aware of unaligned pointers, and have a sane way to parse that data, rather than read individual parts of it from a raw pointer. I am curious, what would be a legitimate reason for an unaligned pointer to int?

simonask 5mo ago
String search algorithms would be one example, where a 64-bit register can be used as a “vector” containing 8x1 bytes.
- jstimpfle 5mo ago
  Where is the part about unaligned pointers?
  - simonask 5mo ago
    Strings typically consist of UTF-8 bytes, and any old `char*` pair has no alignment guarantees.
    - jstimpfle 5mo ago
      That's true, and that's why your typical string vector code has a prelude and a postlude to do the incomplete chunks at the ends. Between the ends, it's processing larger self-aligned chunks.
      - simonask 5mo ago
        If you're aware of that technique, why were you asking about use cases for unaligned loads?
        jstimpfle 5mo ago
        I'm saying that string search algorithms are _not_ a legitimate use case for unaligned loads.
        simonask 5mo ago
        You didn’t really say that, but feel free to share any reasons you might have to think so. I don’t see any reason why it wouldn’t be perfectly fine on recent hardware, where unaligned loads are just as fast, and the cache pressure is identical for a linear search algorithm.
        jstimpfle 5mo ago
        I asked where is the part about unaligned pointers in your string processing example. Saying that you want to load multiple bytes at a time does not imply at all that you have to do unaligned loads. Doing unaligned loads using SSE or AVX might have been possible on Intel architectures for a long time, but it is still a little bit slower afaik. But anyway when you get into sub-architecture specific details like that, you've essentially left C-land, and you're essentially doing assembler level programming.
        simonask 5mo ago
        Every vectorized string search algorithm (including those treating an unsigned long as a "vector" of 8 bytes) currently needs a prelude that performs the search up to the first alignment boundary, and then performs the bulk of the search on well-aligned blocks, and then finally a postlude search in the tail of the string, where the tail is shorter than the block size/alignment. Using unaligned loads, you can get rid of the prelude, including the associated branches and intptr arithmetic, and just have to deal with the tail. If you're comparing short-ish strings, almost all of the time is spent in the prelude and postlude, even if the entire substring fits in a register. This is a silly language limitation when the hardware can actually easily just support the unaligned load. In particular, it doesn't seem justified that what at most amounts to a tiny inefficiency in hardware turns into a very expensive class of bugs (UB).

by tovej 5mo ago

simonask 5mo ago

String search algorithms would be one example, where a 64-bit register can be used as a “vector” containing 8x1 bytes.

jstimpfle 5mo ago
Where is the part about unaligned pointers?
- simonask 5mo ago
  Strings typically consist of UTF-8 bytes, and any old `char*` pair has no alignment guarantees.
  - jstimpfle 5mo ago
    That's true, and that's why your typical string vector code has a prelude and a postlude to do the incomplete chunks at the ends. Between the ends, it's processing larger self-aligned chunks.
    - simonask 5mo ago
      If you're aware of that technique, why were you asking about use cases for unaligned loads?
      - jstimpfle 5mo ago
        I'm saying that string search algorithms are _not_ a legitimate use case for unaligned loads.
        simonask 5mo ago
        You didn’t really say that, but feel free to share any reasons you might have to think so. I don’t see any reason why it wouldn’t be perfectly fine on recent hardware, where unaligned loads are just as fast, and the cache pressure is identical for a linear search algorithm.
        jstimpfle 5mo ago
        I asked where is the part about unaligned pointers in your string processing example. Saying that you want to load multiple bytes at a time does not imply at all that you have to do unaligned loads. Doing unaligned loads using SSE or AVX might have been possible on Intel architectures for a long time, but it is still a little bit slower afaik. But anyway when you get into sub-architecture specific details like that, you've essentially left C-land, and you're essentially doing assembler level programming.
        simonask 5mo ago
        Every vectorized string search algorithm (including those treating an unsigned long as a "vector" of 8 bytes) currently needs a prelude that performs the search up to the first alignment boundary, and then performs the bulk of the search on well-aligned blocks, and then finally a postlude search in the tail of the string, where the tail is shorter than the block size/alignment. Using unaligned loads, you can get rid of the prelude, including the associated branches and intptr arithmetic, and just have to deal with the tail. If you're comparing short-ish strings, almost all of the time is spent in the prelude and postlude, even if the entire substring fits in a register. This is a silly language limitation when the hardware can actually easily just support the unaligned load. In particular, it doesn't seem justified that what at most amounts to a tiny inefficiency in hardware turns into a very expensive class of bugs (UB).