By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), November 13, 2012 6:09 pm
Room: Moderated Discussions
hobold (hobold.delete@this.vectorizer.org) on November 13, 2012 5:13 pm wrote:
>
> I would guess that in the context of a fully cache coherent manycore machine, when you
> try to optimize the scatter operation to store more than a single vector element at a
> time, you run into problems. Memory transactions probably don't make that any easier.
>
> For example, if a scatter operation has to be aborted and restarted for some reason, does it (semantically)
> execute all or nothing? Or can it be in a partly completed state? Larrabee made partly completed
> state information architecturally visible (in a mandatory boolean mask register), but did not support
> transactional memory. As far as I know, AVX* does not expose such internal state.
>
> Or when two "simultaneous" scatter operations from two different cores fight over overlapping
> memory addresses, and then one or both operations has to be undone and later rerun ... is it even
> possible to decide on a consistent specification of what the memory contents ought to be?
>
> Does the coherency protocol support groups of in-flight memory accesses that are semantically
> related to one another? With respect to one or more memory transactions?
>
>
> I could be blowing this issue out of proportions due to personal
> cluelessness. But it does seem rather complicated to me.
AVX2 does expose internal state.
«This instruction can be suspended by an exception if at least one element is already
gathered (i.e., if the exception is triggered by an element other than the rightmost
one with its mask bit set). When this happens, the destination register and the mask
operand are partially updated; those elements that have been gathered are placed
into the destination register and have their mask bits set to zero. If any traps or
interrupts are pending from already gathered elements, they will be delivered in lieu
of the exception; in this case, EFLAG.RF is set to one so an instruction breakpoint is
not re-triggered when the instruction is continued.»
This, of course, makes it simple to implement gather: it's actually a µOP sequence, with individual µOP for each load. All it's required is to keep the proper order.
Using a similar method for stores should not be complicated either.
I'd say Intel simply decided scatter wasn't worth the effort.
>
> I would guess that in the context of a fully cache coherent manycore machine, when you
> try to optimize the scatter operation to store more than a single vector element at a
> time, you run into problems. Memory transactions probably don't make that any easier.
>
> For example, if a scatter operation has to be aborted and restarted for some reason, does it (semantically)
> execute all or nothing? Or can it be in a partly completed state? Larrabee made partly completed
> state information architecturally visible (in a mandatory boolean mask register), but did not support
> transactional memory. As far as I know, AVX* does not expose such internal state.
>
> Or when two "simultaneous" scatter operations from two different cores fight over overlapping
> memory addresses, and then one or both operations has to be undone and later rerun ... is it even
> possible to decide on a consistent specification of what the memory contents ought to be?
>
> Does the coherency protocol support groups of in-flight memory accesses that are semantically
> related to one another? With respect to one or more memory transactions?
>
>
> I could be blowing this issue out of proportions due to personal
> cluelessness. But it does seem rather complicated to me.
AVX2 does expose internal state.
«This instruction can be suspended by an exception if at least one element is already
gathered (i.e., if the exception is triggered by an element other than the rightmost
one with its mask bit set). When this happens, the destination register and the mask
operand are partially updated; those elements that have been gathered are placed
into the destination register and have their mask bits set to zero. If any traps or
interrupts are pending from already gathered elements, they will be delivered in lieu
of the exception; in this case, EFLAG.RF is set to one so an instruction breakpoint is
not re-triggered when the instruction is continued.»
This, of course, makes it simple to implement gather: it's actually a µOP sequence, with individual µOP for each load. All it's required is to keep the proper order.
Using a similar method for stores should not be complicated either.
I'd say Intel simply decided scatter wasn't worth the effort.
