| Message ID | 004c01d0cba1$e15ac5a0$a41050e0$@com |
|---|---|
| State | New |
| Headers | show |
On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote: > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up to 16 > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes align > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero of more > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes 64 or > 128. STP of Q registers is used to reduce codesize without loss of performance. > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with varying sizes > and alignment the new version is 50% faster. > > OK for commit? > A strategy for smaller sizes is quite similar to one on x64. Could you comment why did you choose this control flow. It isn't clear where you should stop with full unrolling, I recall that with some gcc majority of calls had size 192 so unrolling to 256 bytes obviously gave speedup. I also got some ideas to handle small case with conditional moves/ masked moves, as aarch64 doesn't have conditional move only select would it be possible to handle small case by address4 = (size & 4) ? address : stack; *((int32_t *) address4) = vc; address2 = (size & 2) ? address + size - 2: stack; *((int16_t *) address2) = vc; address1 = (size & 1) ? address + (size & 4): stack; *((char *) address2) = vc; I didn't tested if it makes improvement but it looks likely. A real performance impact of this is tricky as it heavily depends on what caller does so only definitive way is take programs that use it (like gcc) and run overnight test to see if you get 1% improvement in total running time or not. Here I would also be interested how this will be improved on dryrun data.
> Ondřej Bílka wrote: > On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote: > > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up > to 16 > > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes > align > > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero > of more > > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes > 64 or > > 128. STP of Q registers is used to reduce codesize without loss of performance. > > > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with > varying sizes > > and alignment the new version is 50% faster. > > > > OK for commit? > > > A strategy for smaller sizes is quite similar to one on x64. Could you > comment why did you choose this control flow. It isn't clear where you > should stop with full unrolling, I recall that with some gcc majority of > calls had size 192 so unrolling to 256 bytes obviously gave speedup. Further unrolling may well be beneficial in some cases, but for that I need to compare actual data. GCC appears to almost exclusively hit the dc zva case according to profiles, so the memsets must be larger than 256. > I also got some ideas to handle small case with conditional moves/ > masked moves, as aarch64 doesn't have conditional move only select > would it be possible to handle small case by > > address4 = (size & 4) ? address : stack; > *((int32_t *) address4) = vc; > address2 = (size & 2) ? address + size - 2: stack; > *((int16_t *) address2) = vc; > address1 = (size & 1) ? address + (size & 4): stack; > *((char *) address2) = vc; > > I didn't tested if it makes improvement but it looks likely. That might be faster on some cores, but it's not clear that size 0-3 or 0-7 are common enough for it to matter. > A real performance impact of this is tricky as it heavily depends on > what caller does so only definitive way is take programs that use it > (like gcc) and run overnight test to see if you get 1% improvement in > total running time or not. > > Here I would also be interested how this will be improved on dryrun > data. I think 1% improvement would be hard to measure in a actual running system. Collecting statistics would be more interesting as that can be played back as part of a benchmark in a controlled environment. Wilco
On Tue, Aug 11, 2015 at 02:02:25PM +0100, Wilco Dijkstra wrote: > > Ondřej Bílka wrote: > > On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote: > > > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up > > to 16 > > > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes > > align > > > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero > > of more > > > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes > > 64 or > > > 128. STP of Q registers is used to reduce codesize without loss of performance. > > > > > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with > > varying sizes > > > and alignment the new version is 50% faster. > > > > > > OK for commit? > > > > > A strategy for smaller sizes is quite similar to one on x64. Could you > > comment why did you choose this control flow. It isn't clear where you > > should stop with full unrolling, I recall that with some gcc majority of > > calls had size 192 so unrolling to 256 bytes obviously gave speedup. > > Further unrolling may well be beneficial in some cases, but for that > I need to compare actual data. GCC appears to almost exclusively hit > the dc zva case according to profiles, so the memsets must be larger > than 256. > Sorry, I recalled that piece of data wrong. Its memcpy that does that. Memset frequently does larger calls. > > I also got some ideas to handle small case with conditional moves/ > > masked moves, as aarch64 doesn't have conditional move only select > > would it be possible to handle small case by > > > > address4 = (size & 4) ? address : stack; > > *((int32_t *) address4) = vc; > > address2 = (size & 2) ? address + size - 2: stack; > > *((int16_t *) address2) = vc; > > address1 = (size & 1) ? address + (size & 4): stack; > > *((char *) address2) = vc; > > > > I didn't tested if it makes improvement but it looks likely. > > That might be faster on some cores, but it's not clear that size 0-3 > or 0-7 are common enough for it to matter. > True. I mentioned that mainly as these are worst case on my benchmark where setting one byte is slower than setting 256. I realized that this could be used also for larger sizes you could use tricks like this to reduce branch misprediction penalty x[n >= 8 ? 1 : 0] = vc; x[n >= 16 ? 2 : 0] = vc; x[n >= 24 ? 3 : 0] = vc; x[n >= 32 ? 4 : 0] = vc; x[n >= 40 ? 5 : 0] = vc; > > A real performance impact of this is tricky as it heavily depends on > > what caller does so only definitive way is take programs that use it > > (like gcc) and run overnight test to see if you get 1% improvement in > > total running time or not. > > > > Here I would also be interested how this will be improved on dryrun > > data. > > I think 1% improvement would be hard to measure in a actual running system. > Collecting statistics would be more interesting as that can be played back > as part of a benchmark in a controlled environment. > No, what I mean is repeatedly running say gcc test.c -O3 and measuring running time of that. Dryrun is that controled environment but it doesn't measure all effects so measuring live programs is better.
On 31 July 2015 at 16:02, Wilco Dijkstra <wdijkstr@arm.com> wrote: > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up to 16 > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes align > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero of more > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes 64 or > 128. STP of Q registers is used to reduce codesize without loss of performance. > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with varying sizes > and alignment the new version is 50% faster. > > OK for commit? > > ChangeLog: > 2015-07-31 Wilco Dijkstra <wdijkstr@arm.com> > > * sysdeps/aarch64/memset.S (__memset): > Rewrite of optimized memset. > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Please drop this unrelated white space change when you commit. OK /Marcus
On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote: > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up to 16 > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes align > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero of more > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes 64 or > 128. STP of Q registers is used to reduce codesize without loss of performance. > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with varying sizes > and alignment the new version is 50% faster. > > OK for commit? > I have two comments, first is that you should try same optimizations I did on x64. First what surprised me is why you stop full unrolling at only 96 bytes as you could go upto 256 bytes and code would be still relatively small. Then you could use trick that you could handle size 32-96 bytes and x-3*x range in general by using following which cuts number of branches. *s = c; *s + (size - x) / 2 = c; *s + size -x = c; Second is to turn sizes smaller than 16 bytes branchless by using conditional moves to write to stack when size is smaller than constant for example in following way. uint64 *p8 = size >= 8 ? s : stack; uint64 *p4 = size >= 4 ? s + (size & 8) : stack; uint64 *p2 = size >= 2 ? s + (size & 12) : stack; char *p1 = size ? s + size - 1 : stack; *p8 = c; *p4 = c; *p2 = c; *p1 = c; > ChangeLog: > 2015-07-31 Wilco Dijkstra <wdijkstr@arm.com> > > * sysdeps/aarch64/memset.S (__memset): > Rewrite of optimized memset. > > --- > sysdeps/aarch64/memset.S | 361 +++++++++++++++++++++-------------------------- > 1 file changed, 162 insertions(+), 199 deletions(-) > > diff --git a/sysdeps/aarch64/memset.S b/sysdeps/aarch64/memset.S > index 816640a..bdd670d 100644 > --- a/sysdeps/aarch64/memset.S > +++ b/sysdeps/aarch64/memset.S > @@ -9,220 +9,183 @@ > > The GNU C Library is distributed in the hope that it will be useful, > but WITHOUT ANY WARRANTY; without even the implied warranty of > - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > Lesser General Public License for more details. > again substitution gone awry.
> Ondřej Bílka wrote: > On Fri, Jul 31, 2015 at 04:02:12PM +0100, Wilco Dijkstra wrote: > > This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up > to 16 > > bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes > align > > the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero > of more > > than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes > 64 or > > 128. STP of Q registers is used to reduce codesize without loss of performance. > > > > Speedup on test-memset is 1% on Cortex-A57 and 8% on Cortex-A53. On a random test with > varying sizes > > and alignment the new version is 50% faster. > > > > OK for commit? > > > I have two comments, first is that you should try same optimizations I > did on x64. > > First what surprised me is why you stop full unrolling at only 96 bytes > as you could go upto 256 bytes and code would be still relatively small. There is no need to unroll further as it will use the dc zva instruction to clear whole cachelines for larger sizes. > Then you could use trick that you could handle size 32-96 bytes and > x-3*x range in general by using following which cuts number of branches. > *s = c; > *s + (size - x) / 2 = c; > *s + size -x = c; Yes that might be feasible as a further improvement for the next version. > Second is to turn sizes smaller than 16 bytes branchless by using > conditional moves to write to stack when size is smaller than constant > for example in following way. > > uint64 *p8 = size >= 8 ? s : stack; > uint64 *p4 = size >= 4 ? s + (size & 8) : stack; > uint64 *p2 = size >= 2 ? s + (size & 12) : stack; > char *p1 = size ? s + size - 1 : stack; > *p8 = c; > *p4 = c; > *p2 = c; > *p1 = c; Yes that is possible too. I'll have a look into that for the next version after this one. That'll need real data as it would now always do 4 stores and usually writes to the stack. Wilco
diff --git a/sysdeps/aarch64/memset.S b/sysdeps/aarch64/memset.S index 816640a..bdd670d 100644 --- a/sysdeps/aarch64/memset.S +++ b/sysdeps/aarch64/memset.S @@ -9,220 +9,183 @@ The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library. If not, see <http://www.gnu.org/licenses/>. */ +#include <sysdep.h> + /* Assumptions: * - * ARMv8-a, AArch64 - * Unaligned accesses + * ARMv8-a, AArch64, unaligned accesses * */ -#include <sysdep.h> - -/* By default we assume that the DC instruction can be used to zero - data blocks more efficiently. In some circumstances this might be - unsafe, for example in an asymmetric multiprocessor environment with - different DC clear lengths (neither the upper nor lower lengths are - safe to use). The feature can be disabled by defining DONT_USE_DC. - - If code may be run in a virtualized environment, then define - MAYBE_VIRT. This will cause the code to cache the system register - values rather than re-reading them each call. */ - -#define dstin x0 -#define val w1 -#define count x2 -#define tmp1 x3 -#define tmp1w w3 -#define tmp2 x4 -#define tmp2w w4 -#define zva_len_x x5 -#define zva_len w5 -#define zva_bits_x x6 - -#define A_l x7 -#define A_lw w7 -#define dst x8 -#define tmp3w w9 +#define dstin x0 +#define val x1 +#define valw w1 +#define count x2 +#define dst x3 +#define dstend x4 +#define tmp1 x5 +#define tmp1w w5 +#define tmp2 x6 +#define tmp2w w6 +#define zva_len x7 +#define zva_lenw w7 ENTRY_ALIGN (__memset, 6) - mov dst, dstin /* Preserve return value. */ - ands A_lw, val, #255 -#ifndef DONT_USE_DC - b.eq L(zero_mem) -#endif - orr A_lw, A_lw, A_lw, lsl #8 - orr A_lw, A_lw, A_lw, lsl #16 - orr A_l, A_l, A_l, lsl #32 -L(tail_maybe_long): - cmp count, #64 - b.ge L(not_short) -L(tail_maybe_tiny): - cmp count, #15 - b.le L(tail15tiny) -L(tail63): - ands tmp1, count, #0x30 - b.eq L(tail15) - add dst, dst, tmp1 - cmp tmp1w, #0x20 - b.eq 1f - b.lt 2f - stp A_l, A_l, [dst, #-48] -1: - stp A_l, A_l, [dst, #-32] -2: - stp A_l, A_l, [dst, #-16] - -L(tail15): - and count, count, #15 - add dst, dst, count - stp A_l, A_l, [dst, #-16] /* Repeat some/all of last store. */ - RET - -L(tail15tiny): - /* Set up to 15 bytes. Does not assume earlier memory - being set. */ - tbz count, #3, 1f - str A_l, [dst], #8 -1: - tbz count, #2, 1f - str A_lw, [dst], #4 -1: - tbz count, #1, 1f - strh A_lw, [dst], #2 -1: - tbz count, #0, 1f - strb A_lw, [dst] -1: - RET - - /* Critical loop. Start at a new cache line boundary. Assuming - * 64 bytes per line, this ensures the entire loop is in one line. */ - .p2align 6 -L(not_short): - neg tmp2, dst - ands tmp2, tmp2, #15 - b.eq 2f - /* Bring DST to 128-bit (16-byte) alignment. We know that there's - * more than that to set, so we simply store 16 bytes and advance by - * the amount required to reach alignment. */ - sub count, count, tmp2 - stp A_l, A_l, [dst] - add dst, dst, tmp2 - /* There may be less than 63 bytes to go now. */ - cmp count, #63 - b.le L(tail63) -2: - sub dst, dst, #16 /* Pre-bias. */ - sub count, count, #64 -1: - stp A_l, A_l, [dst, #16] - stp A_l, A_l, [dst, #32] - stp A_l, A_l, [dst, #48] - stp A_l, A_l, [dst, #64]! - subs count, count, #64 - b.ge 1b - tst count, #0x3f - add dst, dst, #16 - b.ne L(tail63) - RET - -#ifndef DONT_USE_DC - /* For zeroing memory, check to see if we can use the ZVA feature to - * zero entire 'cache' lines. */ -L(zero_mem): - mov A_l, #0 - cmp count, #63 - b.le L(tail_maybe_tiny) - neg tmp2, dst - ands tmp2, tmp2, #15 - b.eq 1f - sub count, count, tmp2 - stp A_l, A_l, [dst] - add dst, dst, tmp2 - cmp count, #63 - b.le L(tail63) -1: - /* For zeroing small amounts of memory, it's not worth setting up - * the line-clear code. */ - cmp count, #128 - b.lt L(not_short) -#ifdef MAYBE_VIRT - /* For efficiency when virtualized, we cache the ZVA capability. */ - adrp tmp2, L(cache_clear) - ldr zva_len, [tmp2, #:lo12:L(cache_clear)] - tbnz zva_len, #31, L(not_short) - cbnz zva_len, L(zero_by_line) - mrs tmp1, dczid_el0 - tbz tmp1, #4, 1f - /* ZVA not available. Remember this for next time. */ - mov zva_len, #~0 - str zva_len, [tmp2, #:lo12:L(cache_clear)] - b L(not_short) -1: - mov tmp3w, #4 - and zva_len, tmp1w, #15 /* Safety: other bits reserved. */ - lsl zva_len, tmp3w, zva_len - str zva_len, [tmp2, #:lo12:L(cache_clear)] -#else + dup v0.16B, valw + add dstend, dstin, count + + cmp count, 96 + b.hi L(set_long) + cmp count, 16 + b.hs L(set_medium) + mov val, v0.D[0] + + /* Set 0..15 bytes. */ + tbz count, 3, 1f + str val, [dstin] + str val, [dstend, -8] + ret + nop +1: tbz count, 2, 2f + str valw, [dstin] + str valw, [dstend, -4] + ret +2: cbz count, 3f + strb valw, [dstin] + tbz count, 1, 3f + strh valw, [dstend, -2] +3: ret + + /* Set 17..96 bytes. */ +L(set_medium): + str q0, [dstin] + tbnz count, 6, L(set96) + str q0, [dstend, -16] + tbz count, 5, 1f + str q0, [dstin, 16] + str q0, [dstend, -32] +1: ret + + .p2align 4 + /* Set 64..96 bytes. Write 64 bytes from the start and + 32 bytes from the end. */ +L(set96): + str q0, [dstin, 16] + stp q0, q0, [dstin, 32] + stp q0, q0, [dstend, -32] + ret + + .p2align 3 + nop +L(set_long): + and valw, valw, 255 + bic dst, dstin, 15 + str q0, [dstin] + cmp count, 256 + ccmp valw, 0, 0, cs + b.eq L(try_zva) +L(no_zva): + sub count, dstend, dst /* Count is 16 too large. */ + add dst, dst, 16 + sub count, count, 64 + 16 /* Adjust count and bias for loop. */ +1: stp q0, q0, [dst], 64 + stp q0, q0, [dst, -32] +L(tail64): + subs count, count, 64 + b.hi 1b +2: stp q0, q0, [dstend, -64] + stp q0, q0, [dstend, -32] + ret + + .p2align 3 +L(try_zva): mrs tmp1, dczid_el0 - tbnz tmp1, #4, L(not_short) - mov tmp3w, #4 - and zva_len, tmp1w, #15 /* Safety: other bits reserved. */ - lsl zva_len, tmp3w, zva_len -#endif - -L(zero_by_line): - /* Compute how far we need to go to become suitably aligned. We're - * already at quad-word alignment. */ - cmp count, zva_len_x - b.lt L(not_short) /* Not enough to reach alignment. */ - sub zva_bits_x, zva_len_x, #1 - neg tmp2, dst - ands tmp2, tmp2, zva_bits_x - b.eq 1f /* Already aligned. */ - /* Not aligned, check that there's enough to copy after alignment. */ - sub tmp1, count, tmp2 - cmp tmp1, #64 - ccmp tmp1, zva_len_x, #8, ge /* NZCV=0b1000 */ - b.lt L(not_short) - /* We know that there's at least 64 bytes to zero and that it's safe - * to overrun by 64 bytes. */ - mov count, tmp1 -2: - stp A_l, A_l, [dst] - stp A_l, A_l, [dst, #16] - stp A_l, A_l, [dst, #32] - subs tmp2, tmp2, #64 - stp A_l, A_l, [dst, #48] - add dst, dst, #64 - b.ge 2b - /* We've overrun a bit, so adjust dst downwards. */ - add dst, dst, tmp2 -1: - sub count, count, zva_len_x -3: - dc zva, dst - add dst, dst, zva_len_x - subs count, count, zva_len_x - b.ge 3b - ands count, count, zva_bits_x - b.ne L(tail_maybe_long) - RET -#ifdef MAYBE_VIRT - .bss - .p2align 2 -L(cache_clear): - .space 4 -#endif -#endif /* DONT_USE_DC */ + tbnz tmp1w, 4, L(no_zva) + and tmp1w, tmp1w, 15 + cmp tmp1w, 4 /* ZVA size is 64 bytes. */ + b.ne L(zva_128) + + /* Write the first and last 64 byte aligned block using stp rather + than using DC ZVA. This is faster on some cores. + */ +L(zva_64): + str q0, [dst, 16] + stp q0, q0, [dst, 32] + bic dst, dst, 63 + stp q0, q0, [dst, 64] + stp q0, q0, [dst, 96] + sub count, dstend, dst /* Count is now 128 too large. */ + sub count, count, 128+64+64 /* Adjust count and bias for loop. */ + add dst, dst, 128 + nop +1: dc zva, dst + add dst, dst, 64 + subs count, count, 64 + b.hi 1b + stp q0, q0, [dst, 0] + stp q0, q0, [dst, 32] + stp q0, q0, [dstend, -64] + stp q0, q0, [dstend, -32] + ret + + .p2align 3 +L(zva_128): + cmp tmp1w, 5 /* ZVA size is 128 bytes. */ + b.ne L(zva_other) + + str q0, [dst, 16] + stp q0, q0, [dst, 32] + stp q0, q0, [dst, 64] + stp q0, q0, [dst, 96] + bic dst, dst, 127 + sub count, dstend, dst /* Count is now 128 too large. */ + sub count, count, 128+128 /* Adjust count and bias for loop. */ + add dst, dst, 128 +1: dc zva, dst + add dst, dst, 128 + subs count, count, 128 + b.hi 1b + stp q0, q0, [dstend, -128] + stp q0, q0, [dstend, -96] + stp q0, q0, [dstend, -64] + stp q0, q0, [dstend, -32] + ret + +L(zva_other): + mov tmp2w, 4 + lsl zva_lenw, tmp2w, tmp1w + add tmp1, zva_len, 64 /* Max alignment bytes written. */ + cmp count, tmp1 + blo L(no_zva) + + sub tmp2, zva_len, 1 + add tmp1, dst, zva_len + add dst, dst, 16 + subs count, tmp1, dst /* Actual alignment bytes to write. */ + bic tmp1, tmp1, tmp2 /* Aligned dc zva start address. */ + beq 2f +1: stp q0, q0, [dst], 64 + stp q0, q0, [dst, -32] + subs count, count, 64 + b.hi 1b +2: mov dst, tmp1 + sub count, dstend, tmp1 /* Remaining bytes to write. */ + subs count, count, zva_len + b.lo 4f +3: dc zva, dst + add dst, dst, zva_len + subs count, count, zva_len + b.hs 3b +4: add count, count, zva_len + b L(tail64) END (__memset) weak_alias (__memset, memset)