Up front, I work for Intel and, even write software for the Intel(r) Xeon Phi(tm) coprocessor.
On 12 Feb 2013, at 16:38, Richard Walsh wrote: > Curious about the observed benefits of hyper-threading, which generally offers > little to floating-point intensive HPC computations where functional unit > collision is an issue. There's a big difference between the processors in the Phi, and those in current Xeons. The Phi CPUs are in-order processors, whereas the Xeons are out of order. On the Xeons hyper-threading is intended to allow the out of order CPU to schedule operations from either hardware thread when there are spare functional units that aren't being used. If a single thread can max-out a functional unit (for instance the floating point ALU) then enabling another hardware thread is unlikely significantly to improve performance (as you observe!). However the intent in the in-order processor is different; here the aim is to provide extra latency tolerance when one thread is stalled waiting for a cache or memory access; in the out of order core, this is hidden by the out of order mechanism. So the benefits of running more hardware threads in the Phi can be much larger than in the big, out of order core, and I would certainly recommend running at least two threads/core unless you are seriously memory bandwidth bound. When investigating scaleability on the Phi, my preference is to plot cores along the x-axis and treat 1thread/core, 2threads/core, ... 4threads/core as separate series. I find this easier to understand than a plot with threads on the x-axis, because it's then hard to distinguish 60threads (== 15 coresx4 threads) from 60 threads (==20coresx3T), 60threads == (30Cx2T) and 60threads (==60Cx1T). If you're using OpenMP, then the KMP_PLACE_THREADS envirable makes it easy to play with allocations of that sort. -- -- Jim -- James Cownie <jcow...@cantab.net>
_______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf