ni...@lysator.liu.se (Niels Möller) writes:
I've implemented a neon addmul_2, see below.
Cool!
Unfortunately, it's not very fast. My first working version took almost
10 cycles per limb product. One iteration through the loop is 9
instructions, and it takes 19 cycles, so there's definitely something
slowing execution down. Then I moved the multiplications earlier, which
got us down to 7 cycles per limb product (14 cycles per iteration through
the loop).
You mean 10 cycles per for one U limb multiplied by the 2 V limbs?
Then 7/2 = 3.5 c/l is a good start.
The plain (non-SIMD) code runs at 2.38 c/l on A9. That might be
reachable or beatable with unrolling and better pipelining.
And I don't really know how far it can be sped up, but there is
definitely some potential for software pipelining (the multiplies can be
moved even further in advance), and with some unrolling we could do
loads and stores of two (or more) limbs at a time.
What about SIMD multiply-accumulate? IIRC, these insns have the same
latency ate throughput as non-accumulating SIMD multiplies.
The recurrency seems
to be a chain
vaddl, vadd, vshr, vld1
which with some tricks could be turned into
vaddl, vadd, vext
What latency can one expect? If we have only a single cycle latency for
each those operations, performance will be limited by instruction
decoding. One could hope to get down to two cycles / limb product, but
it looks quite difficult.
I don't have any well-informed opinion since I cannot read Neon code
yet.
Maybe it would be interesting to try the code also on cortex-a15?
Be my guest. Your account at parma is waiting for you.
Ah, and one interface question: What's the smallest n which mpn_addmul_2
must support?
2.
--
Torbjörn
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
