| commit | 0c0d39fe4aeb0f69b26e76337c5dfd5530d5d44e | |
| author | Adhemerval Zanella <adhemerval.zanella@linaro.org> | |
| Thu, 8 Feb 2024 13:08:38 +0000 (8 10:08 -0300) | ||
| committer | H.J. Lu <hjl.tools@gmail.com> | |
| Tue, 13 Feb 2024 16:49:12 +0000 (13 08:49 -0800) | ||
| tree | 90a312fbf1c501177bfd1e33b67ace7d62bbbd56 | treesnapshot (tar.gz zip) |
| parent | 155bb9d036646138348fee0ac045de601811e0c5 | commitdiff |
x86: Fix Zen3/Zen4 ERMS selection (BZ 30994)
The REP MOVSB usage on memcpy/memmove does not show much performance
improvement on Zen3/Zen4 cores compared to the vectorized loops. Also,
as from BZ 30994, if the source is aligned and the destination is not
the performance can be 20x slower.
The performance difference is noticeable with small buffer sizes, closer
to the lower bounds limits when memcpy/memmove starts to use ERMS. The
performance of REP MOVSB is similar to vectorized instruction on the
size limit (the L2 cache). Also, there is no drawback to multiple cores
sharing the cache.
Checked on x86_64-linux-gnu on Zen3.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The REP MOVSB usage on memcpy/memmove does not show much performance
improvement on Zen3/Zen4 cores compared to the vectorized loops. Also,
as from BZ 30994, if the source is aligned and the destination is not
the performance can be 20x slower.
The performance difference is noticeable with small buffer sizes, closer
to the lower bounds limits when memcpy/memmove starts to use ERMS. The
performance of REP MOVSB is similar to vectorized instruction on the
size limit (the L2 cache). Also, there is no drawback to multiple cores
sharing the cache.
Checked on x86_64-linux-gnu on Zen3.
Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
| sysdeps/x86/dl-cacheinfo.h | diffblobblamehistory |