在 2020/11/16 23:56, Dave Martin 写道: >> --8<-- >> ... >> adler_A .req x10 >> adler_B .req x11 >> >> .macro adler32_core >> ld1b zX.h, p0/z, [x1] // load bytes >> inch x1 >> >> uaddv d0, p0, zX.h >> mul zX.h, p0/m, zX.h, zJ.h // Sum [j=0 .. v-1] j*X[j+n] >> mov x9, v0.d[0] >> uaddv d1, p0, zX.h >> add adler_A, adler_A, x9 // A[n+v] = An + Sum [j=0 ... v-1] X[j] >> mov x9, v1.d[0] >> madd adler_B, x7, adler_A, adler_B // Bn + v*A[n+v] >> sub adler_B, adler_B, x9 // B[n+v] = Bn + v*A[n+v] - Sum [j=0 .. v-1] j*X[j+n] >> .endm > If this has best performance, I find that quite surprising. Those uaddv > instructions will stop the vector lanes flowing independently inside the > loop, so if an individual element load is slow arriuaddving then everything > will have to wait. I don't know much about this problem, do you mean that the uaddv instruction used in the loop has a great impact on performance? > > A decent hardware prefetcher may tend to hide that issue for sequential > memory access, though: i.e., if the hardware does a decent job of > fetching data before the actual loads are issued, the data may appear to > arrive with minimal delay. > > The effect might be a lot worse for algorithms that have less > predictable memory access patterns. > > Possibly you do win some additional performance due to processing twice > as many elements at once, here. I think so. Compared to loading bytes into zX.h, if you load them directly into zX.b, and then use uunpklo/uunpkhi for register expansion, the performance will be more better(20% faster). This may be the reason. -- Best regards, Li Qiang
