arm "neon"

Torbjorn Granlund tg at
Wed Feb 20 22:44:33 CET 2013

nisse at (Niels Möller) writes:

  I've implemented a neon addmul_2, see below.

  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

  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?


More information about the gmp-devel mailing list