I've done some basic experimenting with SMT on network loads. For the most part, as long as you don't fill up one of the ports on the execution engine that's doing SMT, you're okay.
I've found that a memcpy heavy load (read: normal, non-zero copy network traffic) brings SMT threads to their knees. A pair of threads gets as much work done in normal UDP transmit/receive as a single non-SMT thread. It looks like it's because the ports doing memory input/output are full and there's not really any other work that's being done. I think haswell still only has one store data port per core. :( -adrian On 8 December 2014 at 06:39, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote: > On Mon, 8 Dec 2014 04:43:05 -0500 > grarpamp <grarp...@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to >> "freebsd-performance-unsubscr...@freebsd.org" > > Hello. > > Well, I have a very narrow and some sort of naive experience, so be > warned. > > 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. > > oh > _______________________________________________ > freebsd-questi...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
