Disable SSE in libthr
authorvangyzen <vangyzen@FreeBSD.org>
Wed, 5 Aug 2015 12:53:55 +0000 (12:53 +0000)
committervangyzen <vangyzen@FreeBSD.org>
Wed, 5 Aug 2015 12:53:55 +0000 (12:53 +0000)
commitc03b18934d413aec21ae9586ad012f7efd44e6c5
tree225fa08db613158199aeeedef5d9013498ba572e
parent579f504041988e888f7552e59339a77a1948b11e
Disable SSE in libthr

Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock.  If the thread does not otherwise use SSE,
this usage incurs a context-switch of the FPU/SSE state, which
reduces the performance of multiple real-world applications by a
non-trivial amount (3-5% in one application).

Instead of this change, I experimented with eagerly switching the
FPU state at context-switch time.  This did not help.  Most of the
cost seems to be in the read/write of memory--as kib@ stated--and
not in the #NM handling.  I tested on machines with and without
XSAVEOPT.

One counter-argument to this change is that most applications already
use SIMD, and the number of applications and amount of SIMD usage
are only increasing.  This is absolutely true.  I agree that--in
general and in principle--this change is in the wrong direction.
However, there are applications that do not use enough SSE to offset
the extra context-switch cost.  SSE does not provide a clear benefit
in the current libthr code with the current compiler, but it does
provide a clear loss in some cases.  Therefore, disabling SSE in
libthr is a non-loss for most, and a gain for some.

I refrained from disabling SSE in libc--as was suggested--because
I can't make the above argument for libc.  It provides a wide variety
of code; each case should be analyzed separately.

https://lists.freebsd.org/pipermail/freebsd-current/2015-March/055193.html

Suggestions from: dim, jmg, rpaulo
Approved by: kib (mentor)
MFC after: 2 weeks
Sponsored by: Dell Inc.
lib/libthr/arch/amd64/Makefile.inc
lib/libthr/arch/i386/Makefile.inc
libexec/rtld-elf/amd64/Makefile.inc
libexec/rtld-elf/i386/Makefile.inc
share/mk/bsd.cpu.mk