Re: Stealing a Great Idea from the 6600

Thomas Koenig wrote:

MitchAlsup1 <mitchalsup@aol.com> schrieb:

Now, if &b[1] happens to = &a[0], then your construction fails while
VVM
succeeds--it just runs slower because there IS a dependency checked by
HW and enforced. In those situations where the dependency is
nonexistent,
then the loop vectorizes--and the programmer remains blissfuly unaware.

The performance loss can be significant, unfortunately, depending
on the ratio of the width of the data in quesiton to the width of
the SIMD which actually performs the operation.  In the case of
8-bit data and 256-bit wide SIMD, this would be a factor of 32,
which could lead to a slowdown of a factor of... 25,  maybe?
This would be enough to trigger bug reports, I can tell you from
experience :-)

Between 2000 and 2006 I was enamored with SIMD as a proxy for
vectorization. Then, as illustrated above, I started to recognize
the dark alley SIMD was leading others down. In effect it was no
better than vectorization and made the compilers so much more difficult (alias analysis),... and then there is the explosion
of OpCode space consumption,... All of which I wanted to avoid.
The R in RISC should stand for Reduced, not Ridiculous.
Those are simply some of the reasons VVM is "not like that".
VVM requires that the compiler solve exactly none of the
alias problems, the minimum length problems, and works when
typical CRAY-like vectors fail, and where SIMD fails. The
reason it works is the HW recognizes aliasing and slows down
instead of jumping off the cliff.

One technique that could get around that would be loop reversal,
with a branch to the correct loop at runtime (or a predicate
choosing the right values for the loop constants).

Costing code density, compiler complexity, assembly language
programming complexity, and is unnecessary.

An option to raise an exception when there is a slowdown due
to loops running the wrong direction could be helpful in this
context.

Making the slow down even slower/greater.