Date: Mon, 8 Dec 2014 15:39:25 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: grarpamp <grarpamp@gmail.com> Cc: freebsd-performance@freebsd.org, freebsd-smp@freebsd.org, freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: HyperThreading on Intel Xeon Haswell, a benefit? Message-ID: <20141208153925.5df90587@prometheus> In-Reply-To: <CAD2Ti28LZD6u%2BAovBHBFUjQGe0yQLEeArx1t-09sWHTPvOCcpw@mail.gmail.com> References: <CAD2Ti28LZD6u%2BAovBHBFUjQGe0yQLEeArx1t-09sWHTPvOCcpw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Dec 2014 04:43:05 -0500 grarpamp <grarpamp@gmail.com> wrote: > HyperThreading on Intel Xeon Haswell, a benefit? >=20 > What bits of FreeBSD are aware and can take proper advantage of > Intel HTT, such as its thread/process schedulers (sched-BSD/ULE/...), > etc? >=20 > What system/app loads are, or are not, likely to benefit with today's > HyperThreading CPU's? Kernel (ZFS/crypto/net/...) vs. Userland > (apps)? >=20 > 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? >=20 > 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 >=20 > There are some Core i3/i5/i7 Haswell parts with HT as well. > http://ark.intel.com/Search/Advanced?s=3Dt&ECCMemory=3Dtrue&VTD=3Dtrue&AE= STech=3Dtrue >=20 > 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. >=20 > 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/ >=20 > Being unsure of the best list, please direct replies to whichever > is good. Thanks. >=20 > [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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to > "freebsd-performance-unsubscribe@freebsd.org" Hello. Well, I have a very narrow and some sort of naive experience, so be warned. =46rom 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=3D`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.=20 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. oh =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141208153925.5df90587>