Hi Igor,
(Apologies for not threading this, I haven't received my digest for this
list yet)
You wrote:
>I recently checked this old discussion about when/why to use lxvd2x instead of
>lvsl/lvx/vperm/lvx to load elements from memory to vector:
>https://gcc.gnu.org/ml/gcc/2015-03/msg00135.html
>I had the same doubt and I was also concerned how performance influences on
>these
>approaches. So that, I created the following project to check which one is
>faster
>and how memory alignment can influence on results:
>https://github.com/PPC64/load_vec_cmp
>This is a simple code, that many loads (using both approaches) are executed in
>a
>simple loop in order to measure which implementation is slower. The project
>also
>considers alignment.
>As it can be seen on this plot
>(https://raw.githubusercontent.com/igorsnunes/load_vec_cmp/master/doc/LoadVecCompare.png)
>an unaligned load using lxvd2x takes more time.
>The previous discussion (as far as I could see) addresses that lxvd2x performs
>better than lvsl/lvx/vperm/lvx in all cases. Is that correct? Is my analysis
>wrong?
>This issue concerned me, once lxvd2x is heavily used on compiled code.
One problem with your analysis is that you are forcing the use of the xxswapd
following the lxvd2x. Although this is technically required for a load in
isolation to place elements in the correct lanes, in practice the compiler is
able to remove almost all of the xxswapd instructions during optimization. Most
SIMD code does not care about which lanes are used for calculation, so long as
results in memory are placed properly. For computations that do care, we can
often adjust the computations to still allow the swaps to be removed. So your
analysis does not show anything about how code is produced in practice.
Another issue is that you're throwing away the results of the loads, which isn't
a particularly useful way to measure the costs of the latencies of the
instructions. Typically with the pipelined lvx implementation, you will have
an lvx feeding the vperm feeding at least one use of the loaded value in each
iteration of the loop, while with lxvd2x and optimization you will only have an
lxvd2x feeding the use(s). The latter is easier for the scheduler to cover
latencies in most cases.
Finally, as a rule of thumb, these kind of "loop kernels" are really bad for
predicting performance, particularly on POWER.
In the upcoming POWER9 processors, the swap issue goes away entirely, as we will
have true little-endian unaligned loads (the indexed-form lxvx to replace
lxvd2x/
xxswapd, and the offset-form lxv to reduce register pressure).
Now, you will of course see slightly worse unaligned performance for lxvd2x
versus aligned performance for lxvd2x. This happens at specific crossing
points where the hardware has to work a bit harder.
I hate to just say "trust me" but I want you to understand that we have been
looking at these kinds of performance issues for several years. This does
not mean that there are no cases where the pipelined lvx solution works better
for a particular loop, but if you let the compiler optimize it (or do similar
optimization in your own assembly code), lxvd2x is almost always better.
Thanks,
Bill
