Tiny Hyperthreading Experiment

[goldleaf]

A while back I put together a little experiment to see how hyperthreading affected Houdini. Mainly I was curious to see what the effect was for myself; every place I've worked seemed to have a different opinion, and some sys admins were very adament about HT have no improvement on performance, but rather had a negative affect. I think that info is outdated, as from what I've read HT was like that when it first debuted.

http://blog.cerebero.com/post/157399715043/hyper-threading

Hope its helpful!

 

[Jason]

FWIW, we've found an overall benefit for Mantra/VRay renders which is the vast majority of processes on the farm. Fluid sims we're not so sure.  Cloth/FEM/Hair sims, depending on the solver it can hurt performance. Many solvers like this are not easily threaded so if a thread lands on a virtual core, it'll degrade overall performance.  Some solvers try to use Affinity to favor physical cores but this can result in issues if you're trying to run more than one sim (from different sessions) on the box at the same time.

So - hyperthread your farm and your comp, lighting and FX artists. Don't hyperthread CFX/TechAnm people. 

[goldleaf]

Great insights, it's good to hear some experiences from more in-depth testing.

Thanks Jason!

[Guest tar]

ya - as I understand it a so-called virtual core is just the idle processor when it has a cache miss.

[malexander]

"Hyperthreading slows workloads" is from the days of the old Front-Side Bus, which couldn't supply the CPU with data fast enough to cope with double the threads.  That changed a long time ago when Intel ditched the FSB with the Nehalem architecture, when the i7/5/3 product prefixes came into being.

Now you generally only get a slowdown if threaded code scales poorly, if lock contention begins to dominate over real work. Running houdini -j<n> to restrict Houdini to use fewer threads in those cases (such as the cases Jason mentioned) would be a better solution that disabling it unilaterally.