arm "neon"

[Torbjorn Granlund]

nisse at 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