By: anon (spam.delete.delete@this.this.spam.com), September 20, 2018 1:49 am
Room: Moderated Discussions
Travis Downs (travis.downs.delete@this.gmail.com) on September 19, 2018 6:09 pm wrote:
> anon (spam.delete.delete@this.this.spam.com) on September 19, 2018 2:42 am wrote:
>
> > Or the displacement vs page crossing statistics are vastly different depending on the source.
>
> Maybe? Kind of hard to see how though.
>
> Displacements are definitely used differently for pointer chasing versus say unrolled linear access
> of an array (where the address is certain to come from an ALU op) or memcpy. I would expect node
> based structures to have many small offsets, usually the same offset, while unrolled linear code
> has a range of offsets which may be big for big unrolls. Hard to imagine it affecting page crossing
> much There is a small effect to object alignment: e.g., heap objects which are likely targets of
> pointer chasing might be 16B or 32B aligned always, which reduces the chance of heap crossing a
> bit - sometimes to zero for small offsets like 8 - but this effect is very weak.
>
> Even if displacement distribution is wildly different, however, it's hard to see
> how you get different page crossing stats at a given displacement. You'd have
> to have the memory allocators or stack layout or something in on the game.
>
I don't know. Maybe the unrolled loop is set up in a way that all displacements between -2048 and +2047 point to the same page. Compilers might try to optimize for that. Maybe the chances are lower to be within the same page after an ALU op.
I forgot to mention but it seems more likely that it could also be a different distribution of displacements or both. So maybe displacements applied to loaded adresses are generally lower while those that are large but within +-2047 tend to be well behaved.
To get back to the unrolling case: If the loop isn't completely unrolled there should be an ALU op on the base adress every iteration which would prevent the fast path, wouldn't it?
> > Have you tested disp8 vs disp32 for ALU sources?
>
> The test I used has no displacement, so is about the best case for no page
> crossing (impossible unless you are accessing something misaligned).
>
>
So the replay block happens with no displacement?
That would mean page crossing have to be highly correlated for it to be a win.
My idea was that since page crossing are vastly more likely with large displacements they'd only assume that the next will fail as well for disp32 and just take the chance for no displacement/disp8.
> anon (spam.delete.delete@this.this.spam.com) on September 19, 2018 2:42 am wrote:
>
> > Or the displacement vs page crossing statistics are vastly different depending on the source.
>
> Maybe? Kind of hard to see how though.
>
> Displacements are definitely used differently for pointer chasing versus say unrolled linear access
> of an array (where the address is certain to come from an ALU op) or memcpy. I would expect node
> based structures to have many small offsets, usually the same offset, while unrolled linear code
> has a range of offsets which may be big for big unrolls. Hard to imagine it affecting page crossing
> much There is a small effect to object alignment: e.g., heap objects which are likely targets of
> pointer chasing might be 16B or 32B aligned always, which reduces the chance of heap crossing a
> bit - sometimes to zero for small offsets like 8 - but this effect is very weak.
>
> Even if displacement distribution is wildly different, however, it's hard to see
> how you get different page crossing stats at a given displacement. You'd have
> to have the memory allocators or stack layout or something in on the game.
>
I don't know. Maybe the unrolled loop is set up in a way that all displacements between -2048 and +2047 point to the same page. Compilers might try to optimize for that. Maybe the chances are lower to be within the same page after an ALU op.
I forgot to mention but it seems more likely that it could also be a different distribution of displacements or both. So maybe displacements applied to loaded adresses are generally lower while those that are large but within +-2047 tend to be well behaved.
To get back to the unrolling case: If the loop isn't completely unrolled there should be an ALU op on the base adress every iteration which would prevent the fast path, wouldn't it?
> > Have you tested disp8 vs disp32 for ALU sources?
>
> The test I used has no displacement, so is about the best case for no page
> crossing (impossible unless you are accessing something misaligned).
>
>
So the replay block happens with no displacement?
That would mean page crossing have to be highly correlated for it to be a win.
My idea was that since page crossing are vastly more likely with large displacements they'd only assume that the next will fail as well for disp32 and just take the chance for no displacement/disp8.