I've recently created a software benchmarking database for the 3d community found here: http://www.3dspeedmachine.com/?page=3. [3dspeedmachine.com] I wanted to see there would be any interest in benchmarking Houdini. If so, I would need some help in finding an appropriate scene file. I have a sample scene in OBJ format which can be used as a base model if need be: http://www.3dspeedmachine.com/scenes/benchmarkscene.zip [3dspeedmachine.com]
Please let me know if there is any interest in this.
-joe
admin@3dspeedmachine.com

Hi

This come close to what I wanted to discuss

I was listening last night at an interview Bill Roberts from Softimage about version 7 of XSI at fxguide http://www.fxguide.com/fxpodcast.html [fxguide.com]

and they did talked about ICE, houdini and multi threads.

he mentioned that houdini is not all mutli thread and THEY are, so is this true?, how much of houdini is multithreaded and what's not?

Does this means that when I'm doing a liquid in houdini of modeling animation etc, am I only using ONE core?

well, hope someone can share some info on this.

Thank you

Some of Houdini is, some isn't. I can't speak for Soft and their claim of ‘everything’. I do know that calls for threading more stuff in Houdini isn't being ignored.

Cheers,

J.C.

All of ICE is multi-threaded, so it is insanely fast.
Like most other current apps the rest of XSI, is partially multi-threaded.

In houdini you have VEX multi-threading, options if your using VEX,
but even then with a scene like Miguels Bamf2.hip, which uses some VEX
my system only uses 53% of each processor, and thats with multi-threading on in the Vex Params. This seems about the same wither or not I use the multi-threading option there is a slight difference but not much, so I am still basically only getting just over half of what I should.

I used Miguels file because it was sitting on my desktop when I read this.
Its also indicative if the kind of thing you would use for this test.

I am sure if I tested a wak of files then I would probably see a better pattern, of what really makes use of the processors capacity.

however in ICE this kind of thing would nail both processors to 100% so
you are getting an insane amount of performance comparatively.

Another example would be we setup a blendshape on a fairly heavy
poly object, and check the frame rate, which clocks in at 73fps, not bad
we then build the same operator in ICE and the same deformation
runs at 137 fps.

I believe SESI should really push for multi-threading in a really aggressive way if they want to compete in straight speed for speed.
This is going to be a big deal to a lot of people that don't know Houdini. Those that use it know the power and flexibility and don't necessarily need to be “sold” on it. But others may look at the current speed discrepancy and think well I'm going with the fast one.

My 2 cents or mabey that was more like 50 cents.

All of ICE is multi-threaded, so it is insanely fast.

That is not the complete truth, unfortunately.

Some nodes are not threaded by nature, and if You use them in Your network the speed suffers. Nodes that have to look through the complete data set for example. I think it is a nature of multithreading.
But with clever building You can minimize this.

VEX was constructed to be embarrassingly parallel [en.wikipedia.org], as a pure SIMD architecture - so there's hardly any case for changing VEX's behaviour. Some DOPs such as the particle fluids can be highly parallel in some special cases (depending on particle count and spread for example) - even in highly specialized software such as Realflow there are some major constrains for multithreading this kind of task. Some SOPs are multithreaded, too, such as the particle fluid surface.

However, the overwhelming amount of SOPs is single threaded, and a lot of them in theory could be multithreaded (off the top of my head - point, attribute*, ray for example). Also, as soon as expressions are involved in the cook tree, my understanding is that multithreading is non-trivial - understandably, as you have to ensure data consistency across the threads but expressions can mess around with your data. So in these cases, even if your VEX code is completely multithreading, it will still mostly depend on single threaded or thread-blocking nodes such as SOPs and expressions, which explains why it is slowed down (i.e. doesn't use 100% of all CPUs).

My understanding is that SESI is already hard at work rewriting different parts of Houdini to make them multithreaded, and we should expect some cool stuff soon

cheers,
Abdelkareem

Yes I hope that SESI can compete in speed with ICE an softimage in general.
Is not only about the multithreading stuff in ICE, the viewport is much much faster in softimage.
So the overall feedback with the user is really fast and good.
But hoping that this speed issues cab ne improved in the near future.

any interest in helping with a houdini scene file for for benchmarking? i noticed this file is available to the public. http://www.sidefx.com/index.php?option=com_content&task=view&id=1294&Itemid=279 [sidefx.com]
does anyone see an issue with using that file for benchmarking? i'd really like to add houdini to the database.
best,
-joe