3 ms·

Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https:

Well, I guess alignment doesn't say anything about how large of a block is allocated.... And this is the clearest source I can find, which says 32 bytes. https://prog21.dadgum.com/179.html https://prog21.dadgum.com/179.html

blattimwind 8y ago
> Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).
- saagarjha 8y ago
  > Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
  - blattimwind 8y ago
    > This is extremely processor-dependent No, it's not. > you should not be writing C if you’re relying on this. Luckily you are in no position to tell anyone what they should or shouldn't do.
    - saagarjha 8y ago
      Sorry, I misunderstood the context of that statement and was thought you were talking about vectorized algorithms exploiting out-of-bounds reads in general, which is pretty dependent on the processor as to when it will work (depending on how page boundaries and cache lines are set up). And I didn't really mean my statement about using C in the prescriptive way you seem to have taken it: I was merely trying to say that you should probably be using assembly in this case, because you are relying on details of your processor that your compiler is likely to be unaware about and may penalize you for. For example, the vectorized string routines in libSystem do overshoot the end of the string because they use pcmpeqb, and it is written in assembly because it relies on alignment guarantees that are difficult to express in C. Plus it guarantees vectorization ;)
      - blattimwind 8y ago
        Ah, true, it is my turn to apologize then for interpreting your post in a rather uncharitable way.

blattimwind 8y ago

> Well, I guess alignment doesn't say anything about how large of a block is allocated It tells you where something can't be, and because virtual memory is allocated in whole pages the "padding" so to speak will always be accessible. There's also the obvious truism that if you can access something in a cache line, all addresses in the cache line are safe to access. (Vectorized algorithms frequently implicitly rely on this for short reads, IOW there is no way reading a 128 or 256 bit vector can fault if just reading the first lane would not fault).

saagarjha 8y ago
> Vectorized algorithms frequently implicitly rely on this for short reads This is extremely processor-dependent and you should not be writing C if you’re relying on this.
- blattimwind 8y ago
  > This is extremely processor-dependent No, it's not. > you should not be writing C if you’re relying on this. Luckily you are in no position to tell anyone what they should or shouldn't do.
  - saagarjha 8y ago
    Sorry, I misunderstood the context of that statement and was thought you were talking about vectorized algorithms exploiting out-of-bounds reads in general, which is pretty dependent on the processor as to when it will work (depending on how page boundaries and cache lines are set up). And I didn't really mean my statement about using C in the prescriptive way you seem to have taken it: I was merely trying to say that you should probably be using assembly in this case, because you are relying on details of your processor that your compiler is likely to be unaware about and may penalize you for. For example, the vectorized string routines in libSystem do overshoot the end of the string because they use pcmpeqb, and it is written in assembly because it relies on alignment guarantees that are difficult to express in C. Plus it guarantees vectorization ;)
    - blattimwind 8y ago
      Ah, true, it is my turn to apologize then for interpreting your post in a rather uncharitable way.