mirror of
https://github.com/opnsense/src.git
synced 2026-05-20 17:09:30 -04:00
ddab052725
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. |
||
|---|---|---|
| .. | ||
| colldef | ||
| dict | ||
| doc | ||
| dtrace | ||
| examples | ||
| i18n | ||
| keys | ||
| man | ||
| me | ||
| misc | ||
| mk | ||
| mklocale | ||
| monetdef | ||
| msgdef | ||
| numericdef | ||
| security | ||
| sendmail | ||
| skel | ||
| snmp | ||
| syscons | ||
| tabset | ||
| termcap | ||
| tests | ||
| timedef | ||
| vt | ||
| zoneinfo | ||
| Makefile | ||
| Makefile.inc | ||