This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Commit 27d3ce1467990f89126e228559dec8f84b96c60e?
- From: Carlos O'Donell <carlos at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Cc: Florian Weimer <fweimer at redhat dot com>
- Date: Tue, 26 Nov 2019 10:01:19 -0500
- Subject: Commit 27d3ce1467990f89126e228559dec8f84b96c60e?
HJ,
In commit 27d3ce1467990f89126e228559dec8f84b96c60e we stop
setting bit_arch_Fast_Copy_Backward for Intel Core processors
as an optimization to improve performance.
It turns out that this change also improves performance for
Haswell servers. Was it the intent of this change to *also*
improve performance for Haswell? The comments don't indicate
this and I was worried that it might be an unintentional change
in this case. The particular CPU was a E5-2650 v3.
If we step back and look at the overall sequence of changes and
performance it looks like this:
The performance regression is between this change:
c3d8dc45c9df199b8334599a6cbd98c9950dba62 - Triggers default: handling + TSX handling.
- Causes a 21% lmbench regression for an E5-2650 v3.
and this change (the one we are discussing):
27d3ce1467990f89126e228559dec8f84b96c60e - Removes bit_arch_Fast_Copy_Backward.
- Restores the performance loss.
My worry is that the two are unrelated, and that we've only
just made back performance at the expense of the other change
and we could be doing better.
As our Intel expert what do you think is going on here?
--
Cheers,
Carlos.
[1] https://ark.intel.com/content/www/us/en/ark/products/81705/intel-xeon-processor-e5-2650-v3-25m-cache-2-30-ghz.html