> Do you know what of the three changes (preferring reps/stosb, > CLEAR_RATIO and algorithm choice changes) cause the two speedups > on eebmc?
A extracted testcase from nnet_test in https://godbolt.org/z/c8KdsohTP This loop is transformed to builtin_memcpy and builtin_memset with size 280. Current strategy for skylake is {512, unrolled_loop, false} for such size, so it will generate unrolled loops with mov, while the patch generates memcpy/memset libcall and uses vector move. For idctrn01 it is memset with size 512. So the speedups come from algorithm change. H.J. Lu via Gcc-patches <gcc-patches@gcc.gnu.org> 于2021年4月6日周二 上午5:55写道： > > On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > > /* skylake_cost should produce code tuned for Skylake familly of CPUs. > > > > */ > > > > static stringop_algs skylake_memcpy[2] = { > > > > - {libcall, {{1024, rep_prefix_4_byte, true}, {-1, libcall, false}}}, > > > > - {libcall, {{16, loop, false}, {512, unrolled_loop, false}, > > > > - {-1, libcall, false}}}}; > > > > + {libcall, > > > > + {{256, rep_prefix_1_byte, true}, > > > > + {256, loop, false}, > > > > + {-1, libcall, false}}}, > > > > + {libcall, > > > > + {{256, rep_prefix_1_byte, true}, > > > > + {256, loop, false}, > > > > + {-1, libcall, false}}}}; > > > > > > > > static stringop_algs skylake_memset[2] = { > > > > - {libcall, {{6, loop_1_byte, true}, > > > > - {24, loop, true}, > > > > - {8192, rep_prefix_4_byte, true}, > > > > - {-1, libcall, false}}}, > > > > - {libcall, {{24, loop, true}, {512, unrolled_loop, false}, > > > > - {-1, libcall, false}}}}; > > > > + {libcall, > > > > + {{256, rep_prefix_1_byte, true}, > > > > + {256, loop, false}, > > > > + {-1, libcall, false}}}, > > > > + {libcall, > > > > + {{256, rep_prefix_1_byte, true}, > > > > + {256, loop, false}, > > > > + {-1, libcall, false}}}}; > > > > > > > > > > If there are no objections, I will check it in on Wednesday. > > > > On my skylake notebook if I run the benchmarking script I get: > > > > jan@skylake:~/trunk/contrib> ./bench-stringop 64 640000000 gcc -march=native > > memcpy > > block size libcall rep1 noalg rep4 noalg rep8 noalg loop > > noalg unrl noalg sse noalg byte PGO dynamic BEST > > 8192000 0:00.23 0:00.21 0:00.21 0:00.21 0:00.21 0:00.22 0:00.24 > > 0:00.28 0:00.22 0:00.20 0:00.21 0:00.19 0:00.19 0:00.77 0:00.18 0:00.18 > > 0:00.19 sse > > 819200 0:00.09 0:00.18 0:00.18 0:00.18 0:00.18 0:00.18 0:00.20 > > 0:00.19 0:00.16 0:00.15 0:00.16 0:00.13 0:00.14 0:00.63 0:00.09 0:00.09 > > 0:00.09 libcall > > 81920 0:00.06 0:00.07 0:00.07 0:00.06 0:00.06 0:00.06 0:00.06 > > 0:00.12 0:00.11 0:00.11 0:00.10 0:00.07 0:00.08 0:00.66 0:00.11 0:00.06 > > 0:00.06 libcall > > 20480 0:00.06 0:00.07 0:00.05 0:00.06 0:00.07 0:00.07 0:00.08 > > 0:00.14 0:00.14 0:00.10 0:00.11 0:00.06 0:00.07 0:01.11 0:00.07 0:00.09 > > 0:00.05 rep1noalign > > 8192 0:00.06 0:00.05 0:00.04 0:00.05 0:00.06 0:00.07 0:00.07 > > 0:00.12 0:00.15 0:00.11 0:00.10 0:00.06 0:00.06 0:00.64 0:00.06 0:00.05 > > 0:00.04 rep1noalign > > 4096 0:00.05 0:00.05 0:00.05 0:00.06 0:00.07 0:00.05 0:00.05 > > 0:00.09 0:00.14 0:00.11 0:00.10 0:00.07 0:00.06 0:00.61 0:00.05 0:00.07 > > 0:00.05 libcall > > 2048 0:00.04 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 > > 0:00.10 0:00.14 0:00.09 0:00.09 0:00.09 0:00.07 0:00.64 0:00.06 0:00.07 > > 0:00.04 libcall > > 1024 0:00.06 0:00.08 0:00.08 0:00.10 0:00.11 0:00.06 0:00.06 > > 0:00.12 0:00.15 0:00.09 0:00.09 0:00.16 0:00.09 0:00.63 0:00.05 0:00.06 > > 0:00.06 libcall > > 512 0:00.06 0:00.07 0:00.08 0:00.12 0:00.08 0:00.10 0:00.09 > > 0:00.13 0:00.16 0:00.10 0:00.10 0:00.28 0:00.18 0:00.66 0:00.13 0:00.08 > > 0:00.06 libcall > > 256 0:00.10 0:00.12 0:00.11 0:00.14 0:00.11 0:00.12 0:00.13 > > 0:00.14 0:00.16 0:00.13 0:00.12 0:00.49 0:00.30 0:00.68 0:00.14 0:00.12 > > 0:00.10 libcall > > 128 0:00.15 0:00.19 0:00.18 0:00.20 0:00.19 0:00.20 0:00.18 > > 0:00.19 0:00.21 0:00.17 0:00.15 0:00.49 0:00.43 0:00.72 0:00.17 0:00.17 > > 0:00.15 libcall > > 64 0:00.29 0:00.28 0:00.29 0:00.33 0:00.33 0:00.34 0:00.29 > > 0:00.25 0:00.29 0:00.26 0:00.26 0:01.01 0:00.97 0:01.13 0:00.32 0:00.28 > > 0:00.25 loop > > 48 0:00.37 0:00.39 0:00.38 0:00.45 0:00.41 0:00.45 0:00.44 > > 0:00.45 0:00.33 0:00.32 0:00.33 0:02.21 0:02.22 0:00.87 0:00.32 0:00.31 > > 0:00.32 unrl > > 32 0:00.54 0:00.52 0:00.50 0:00.60 0:00.62 0:00.61 0:00.52 > > 0:00.42 0:00.43 0:00.40 0:00.42 0:01.18 0:01.16 0:01.14 0:00.39 0:00.40 > > 0:00.40 unrl > > 24 0:00.71 0:00.74 0:00.77 0:00.83 0:00.78 0:00.81 0:00.75 > > 0:00.52 0:00.52 0:00.52 0:00.50 0:02.28 0:02.27 0:00.94 0:00.49 0:00.50 > > 0:00.50 unrlnoalign > > 16 0:00.97 0:01.03 0:01.20 0:01.52 0:01.37 0:01.84 0:01.10 > > 0:00.90 0:00.86 0:00.79 0:00.77 0:01.27 0:01.32 0:01.25 0:00.91 0:00.91 > > 0:00.77 unrlnoalign > > 14 0:01.35 0:01.37 0:01.39 0:01.76 0:01.44 0:01.53 0:01.58 > > 0:01.01 0:00.99 0:00.94 0:00.94 0:01.34 0:01.29 0:01.28 0:01.01 0:00.99 > > 0:00.94 unrl > > 12 0:01.48 0:01.55 0:01.55 0:01.70 0:01.55 0:02.01 0:01.52 > > 0:01.11 0:01.07 0:01.02 0:01.04 0:02.21 0:02.25 0:01.19 0:01.11 0:01.10 > > 0:01.02 unrl > > 10 0:01.73 0:01.90 0:01.88 0:02.05 0:01.86 0:02.09 0:01.78 > > 0:01.32 0:01.41 0:01.25 0:01.23 0:02.46 0:02.25 0:01.36 0:01.50 0:01.38 > > 0:01.23 unrlnoalign > > 8 0:02.22 0:02.17 0:02.18 0:02.43 0:02.09 0:02.55 0:01.92 > > 0:01.54 0:01.46 0:01.38 0:01.38 0:01.51 0:01.62 0:01.54 0:01.55 0:01.55 > > 0:01.38 unrl > > So indeed rep byte seems consistently outperforming rep4/rep8 however > > urolled variant seems to be better than rep byte for small block sizes. > > My patch generates "rep movsb" only in a very limited cases: > > 1. With MOVE_RATIO and CLEAR_RATIO == 17, GCC will use integer/vector > load and store for up to 16 * 16 (256) bytes when the data size is > fixed and known. > 2. Inline only if data size is known to be <= 256. > a. Use "rep movsb/stosb" with a simple code sequence if the data size > is a constant. > b. Use loop if data size is not a constant. > > As a result, "rep stosb" is generated only when 128 < data size < 256 > with -mno-sse. > > > Do you have some data for blocks in size 8...256 to be faster with rep1 > > compared to unrolled loop for perhaps more real world benchmarks? > > "rep movsb" isn't generated with my patch in this case since > MOVE_RATIO == 17 can copy up to 16 * 16 (256) bytes with > XMM registers. > > > The difference seems to get quite big for small locks in range 8...16 > > bytes. I noticed that before and sort of conlcuded that it is probably > > the branch prediction playing relatively well for those small block > > sizes. On the other hand winding up the relatively long unrolled loop is > > not very cool just to catch this case. > > > > Do you know what of the three changes (preferring reps/stosb, > > CLEAR_RATIO and algorithm choice changes) cause the two speedups > > on eebmc? > > Hongyu, can you find out where the speedup came from? > > Thanks. > > -- > H.J.
