Hey,
Was wondering if anyone had any thoughts on hyperthreading in linux when using houdini. I just recompiled a new kernel with HT turned off, due to the very bad performance in houdini. Almost all operations were only running on one cpu, and since they are virtual, performance was abysmal.
Is houdini optimized for threading? Most operations seem to only run on one cpu. I've only got mantra to use more than one, and that's by forcing it with the -h or -n flag. I'm surprised particle operations weren't taking advantage of the extra cpu's. Not even when HT turned off. To be honest, Houdini runs fastest on our amd 64 machines (2 gig, 32 bit OS, geforce vid cards), it feels quicker and more responsive than on a dual xeon 3.2 with 2gigs and a quadroFX1300. Weird no?
Anyway, just wanted to hear if anyone else had the same findings… could be me doing something wrong, I'm pretty new on houdini.

Peter

Hey Peter,
The main Houdini processes do not use multithreading, sadly. However, there are exceptions Halo (COPs) can use multithreading though beware of image corruption. Most people turn multithreading off in COPs (Main Prefs->Compositing) as a result. When it works, though, the multithreading in COPs is really sweet.
Also, VEX operators can use multithreading as well, but again, sadly, more often than not having it on will cause crashing.
Mantra is the prime candidate for multithreading, where it generally works well.

Cheers,

Peter B

Hey Peter

Thanks for the info. I'm surprised houdini lacks advanced threading, when it's so advanced a piece of software over all. It's painfull to sit and wait for something to cook when 3 cpus are just sitting idle. Oh well, one day maybe…

Peter

The “Threading in Houdini” topic comes up from time to time and I think Mark #32 summed up the issue really nicely in this thread….

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=4667&highlight=thread [sidefx.com]

twod
Unfortunately, multithreading an application is not at all an easy task (or sometimes, even possible). It makes coding and maintaining that app orders of magnitude more difficult. And it's even worse for established applications written as single-threaded apps (like Houdini). It's sort of akin to converting your gas-powered car a hybrid car, based solely on the fact that hybrid engines now exist.

On the surface, it looks certain things in Houdini would thread well (like nodes or network branches). However, our expression language severely complicates things (as you can essentially cook other nodes through an expression). In other cases, the work is not divisible, but inter-dependent. In the case of DOPs, determining how to split the workload could probably be a separate thread itself - it's that complicated for anything beyond the simplest of cases. And finally, existing code is simply not threadsafe - even in the standard C libs sometimes - and doing a sweep to convert code to be threadsafe is a huge undertaking by itself.

It's almost a little unfortunate that dual-core CPUs came out so suddenly, as now everyone wants to take advantage of it (and rightly so). Since quad processors are now within reach, this will only become a bigger issue. However, I suspect it will be years before established software catches up (even compilers and debuggers are still lagging in thread support). It's great to have all these extra processing units, but keeping them all busy can be a difficult task.

Hey priel, don't forget if you organise your time well you can always use the other cpus for rendering tests (memory permitting) or just browsing the forums for clever tricks to speed things up!

true true… slashdot is starting to feel like second home

Thank you all for the information regarding threading.