From: "H.J. Lu" <hjl.tools@gmail.com>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
Hongtao Liu <hongtao.liu@intel.com>,
Hongyu Wang <hongyu.wang@intel.com>
Subject: Re: [PATCH 2/3] x86: Update memcpy/memset inline strategies for Skylake family CPUs
Date: Mon, 5 Apr 2021 14:53:57 -0700 [thread overview]
Message-ID: <CAMe9rOria7bHjN-gt-s=8965aNbbztCfYDw03bCagky-qgCmjQ@mail.gmail.com> (raw)
In-Reply-To: <20210405211407.GC91941@kam.mff.cuni.cz>
On Mon, Apr 5, 2021 at 2:14 PM Jan Hubicka <hubicka@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.
next prev parent reply other threads:[~2021-04-05 21:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 13:16 [PATCH 0/3] x86: Update memcpy/memset inline strategies H.J. Lu
2021-03-22 13:16 ` [PATCH 1/3] x86: Update memcpy/memset inline strategies for Ice Lake H.J. Lu
2021-03-22 14:10 ` Jan Hubicka
2021-03-22 23:57 ` [PATCH v2 " H.J. Lu
2021-03-29 13:43 ` H.J. Lu
2021-03-31 6:59 ` Richard Biener
2021-03-31 8:05 ` Jan Hubicka
2021-03-31 13:09 ` H.J. Lu
2021-03-31 13:40 ` Jan Hubicka
2021-03-31 13:47 ` Jan Hubicka
2021-03-31 15:41 ` H.J. Lu
2021-03-31 17:43 ` Jan Hubicka
2021-03-31 17:54 ` H.J. Lu
2021-04-01 5:57 ` Hongyu Wang
2021-03-22 13:16 ` [PATCH 2/3] x86: Update memcpy/memset inline strategies for Skylake family CPUs H.J. Lu
2021-04-05 13:45 ` H.J. Lu
2021-04-05 21:14 ` Jan Hubicka
2021-04-05 21:53 ` H.J. Lu [this message]
2021-04-06 9:09 ` Hongyu Wang
2021-04-06 9:51 ` Jan Hubicka
2021-04-06 12:34 ` H.J. Lu
2021-03-22 13:16 ` [PATCH 3/3] x86: Update memcpy/memset inline strategies for -mtune=generic H.J. Lu
2021-03-22 13:29 ` Richard Biener
2021-03-22 13:38 ` H.J. Lu
2021-03-23 2:41 ` Hongyu Wang
2021-03-23 8:19 ` Richard Biener
2021-08-22 15:28 ` PING [PATCH] " H.J. Lu
2021-09-08 3:01 ` PING^2 " H.J. Lu
2021-09-13 13:38 ` H.J. Lu
2021-09-20 17:06 ` PING^3 " H.J. Lu
2021-10-01 15:24 ` PING^4 " H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMe9rOria7bHjN-gt-s=8965aNbbztCfYDw03bCagky-qgCmjQ@mail.gmail.com' \
--to=hjl.tools@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hongtao.liu@intel.com \
--cc=hongyu.wang@intel.com \
--cc=hubicka@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).