HyperThreading on Intel Xeon Haswell, a benefit?

O. Hartmann ohartman at zedat.fu-berlin.de
Mon Dec 8 14:40:33 UTC 2014

On Mon, 8 Dec 2014 04:43:05 -0500
grarpamp <grarpamp at gmail.com> wrote:

> HyperThreading on Intel Xeon Haswell, a benefit?
> What bits of FreeBSD are aware and can take proper advantage of
> Intel HTT, such as its thread/process schedulers (sched-BSD/ULE/...),
> etc?
> What system/app loads are, or are not, likely to benefit with today's
> HyperThreading CPU's? Kernel (ZFS/crypto/net/...) vs.  Userland
> (apps)?
> Does anyone have performance stats for this current class of CPU
> to post comparing HT (enabled and disabled) while using more than
> four processes/threads in parallel?
> For instance, these two Intel Xeon Haswell four core CPU's are
> identical except for HT [1] (e3-1226v3 and e3-1246v3), and you
> can always turn HT off for testing.
> http://ark.intel.com/compare/80917,80916
> There are some Core i3/i5/i7 Haswell parts with HT as well.
> http://ark.intel.com/Search/Advanced?s=t&ECCMemory=true&VTD=true&AESTech=true
> There don't seem to be many reviews of Xeon processors, let alone
> HT. And most Unix talk of HT seems dated by at least a few years
> and a couple processor generations.
> Also, was the HT cache leak security issue from a decade ago ever
> fixed in hardware?
> "Cache missing for fun and profit"
> http://www.daemonology.net/papers/
> Being unsure of the best list, please direct replies to whichever
> is good. Thanks.
> [1] Plus 200MHz/6% clock per core and $59/27% market price bumps,
> but this thread is about whether or not there is any benefit to HT
> in current Intel CPU's such as Haswell, how much of one, and where.
> Once that is determined, then you can factor in other parameters
> like these to see if it's an overall value.
> _______________________________________________
> freebsd-performance at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to
> "freebsd-performance-unsubscribe at freebsd.org"


Well, I have a very narrow and some sort of naive experience, so be

From my experience, mostly compiling FreeBSD sources from scratch
(deleted /usr/obj, no sophisticated caching subsystems used), compiling
world and kernel with as many threads allowed as possible (using
value of possible threads via PARA=`sysctl -n hw.ncpu` and use then
$PARA as variable for "make -j${PARA} ..."), a dual core, 4-thread CPU
at 3.3 GHz takes ~ 60 minutes to build world, the same as a 4-core
castrated i3 with disabled SMT. Switching off SMT on the dual core
results in roughly 90 - 100 minutes compile time in my case, depending
on the average load of the box while compiling. So, for the INTEGER
performance, I see some real benefits of SMT.

The picture is somehow different for the floating point performance.
Using SMT in some FPU heavy caclulations on Sandy- and Ivy-Bridge CPUs
(Haswell is not available as XEON to me at this very moment), I see
only 10% - a max. of 25% (roughly estimated on some crude manually
timed calculations!). There is some sligt benefit, even better with
most recent Ivy-Bridge than Sandy-Bridge and bot latter seem to be
superior in that matter to some Westmere 6-Core XEONS we used to use a
couple of years ago (this may be related to some other architectural
design improvements other than SMT, like the ring bus introduced in
Sandy Bridge and improved in Ivy Bridge and maybe Haswell).

In earlier times (pre Sandy-Bridge era) there were issues were it
would be beneficial switching off SMT for heavy FPU load in some
BLAS/LAPACK based benchmark scenarios, but this knowledge is years
ago with older P4 designs and early Core i7. I lost track of that. 

To make it short: I would highly recommend using/purchasing SMT
capable CPUs since there is a benefit in performance. But at the end
the performance gain has to meet the costs of a SMT capable XEON. As
far as I know, most of the "value" XEONs do have SMT by default.

There are some disadvantages regarding the amount of memory the
kernel has to consume for each core (logical and/or physical) found,
so systems with small amounts of physical RAM (< 8 GiB) could run
into disadvantageous situations - if I'm not wrong. But for all
FreeBSD users considering using ZFS fro
professional/semiprofessional usage, 8 GiB at least is a must,
otherwise the ZFS system is crippling performance, not SMT.


More information about the freebsd-questions mailing list