Ice Performance in 2014 SP2 approx 20% better than 2015 SP2

[jonmoore]

I recently decided to install Soft 2014 SP2 as my 2015 install had become bloated with ICE compounds which I was 1.) using as a 'crutch' and 2.) cluttered dynamic node search results and ended up slowing my workflow. It started as a somewhat intellectual 'back to basics' exercise, where my only non standard ICE components were Eric Mootz tools and Redshift. I simply wanted to see how I'd cope going back to the atomic elements of ICE to build compounds on the fly. But an unintended byproduct of the exercise is that I've found that my existing ICE setups were more perfomant - by at least 20%.

I'd often read reports of performance issues in Soft as each new years release came around but I must admit I'd taken it to be the usual user community gripes where artists often forget that they're attempting more ambitious projects each year.

I also went into the exercise thinking that losing Tab search in the ICE and Render Tree's would be too painful for me to want to use 2014 permanently but I'm not finding that to be the case at all, as the pre-2015 interaction model has many of it's own advantages that keep interaction fluidity at an equivalent pace.

What started as an intellectual exercise will probably end up being a permanent move. I'll gradually repopulate my ICE toolkit, scripts and plugins but hopefully with a more critical eye in terms of what I really need!

I'm wondering if anybody else has found similar performance gains in particular Soft releases?

[opoppopopp]

really? going to test it now...

[jonmoore]

really? going to test it now...

The simplest test you can do is set up a point cloud to emit 10k particles per second and ensure you're only displaying 5 % of those particles as 1 pixel points (this helps eliminate graphics driver issues between 2014 and 2015). Set up an Attribute Display to show the point count, and cook until you have a million or so particles emitted. Set up an FPS display and you should see a dramatic difference in the pure vector math performance between 2014 and 2015.

This is obviously a very unreal-world test but any setups based on particle or deformation type effects will show similar performance gains. When it comes to collisions and procedural creation/destruction of geometry, the performance gains aren't so great but Soft has always suffered with these types of setup. However I did find that emTopolizer based setups had reasonable performance gains as well. And most of Mr Mootz's C++ nodes in emTools showed better than 20% gains. emFluid5 performance is more balanced between 2014 and 2015 but that's pretty much a custom C++ solver that only uses ICE as a UI toolset.

[sirdavid32]

I still trust 2014 sp2 any day over 2015 sp2.
This just shows I was right.
Benchmark rigging as well. You'll find nice surprises in the scene inspector.

[NNois]

Humm, look at the new attribute editor in 2015.
Possibly you're exporting too much of them, there was a big change on that side.
Personally I never see that performance drop and the 2015 update was a very cool one on the ICE side of things

[luceric]

There are a lot of bug fixes between 2014 and 2015, perhaps some for correct evaluation that might cause lower performance, so I wouldn't necessarily trust an older version as being "right". That said, if it works for you, it works. Use whatever gets the job done.

[jonmoore]

I'm aware of the bug fixes between 2014 and 2015 but after running a collection of simple rigorous benchmarks I found that pure particle/point based effects in the ICE Tree ran faster in 2014 than in 2015 (the benchmarks were based on ICE's vector manipulation strengths which are far removed many from real world challenges). I still use 2015 as my workhorse install but I tend to run it in tandem with 2014 so that I can break down more complex tasks and solve them in 2014, where I have a minimal set of addon's and plugins. Over the years I've added over 200 addons, close to 700 ICE compounds, 300+ RT compounds and 50+ plugins to my 2015 install (and that's not counting the 40+ Workgroups, with their plugins and compounds). It may be the case that there's something in that collection of addons that's effecting evaluation (that seems doubtful, but in a benchmark scenario you ideally want to be comparing like with like, so it's important to highlight the differences).

I can't say that I've noticed performance differences outside of ICE between 2014 and 2015 but most of my work with Softimage is ICE-centric so I'm less likely to spot those performance differences (if they exist).

EDIT:
My hardware setup is also very well tuned for ICE. It's an old liquid cooled 20 core (40 thread) duel XEON E5 -2690 v2 system from 2014 (128 GB RAM); which is conservatively over-clocked to run at 4Ghz single core and 3.5 Ghz multi core. It may be old but it still holds it's own against modern systems. Having spoken to many others (particularly in the Houdini community) I've come to the opinion that Intel XEON multi-core systems are particularly well suited to many typical multi-physics challenges of ICE, Houdini, X-Particles etc. But I doubt I'll ever invest in a massively cored Intel system again seeing as rendering duties are handled by GPU these days, plus many multi-physics challenges (particularly those involving collisions) don't scale well to multiple cores. So when I finally get round to replacing this system, single core turbo performance will be a prime consideration. The point in mentioning my current hardware setup, is that it will amplify performance gains of idealised vector manipulation ICE setups.

[sirdavid32]

Thank you for sharing @jonmoore. ICE continues to impress everyone in the CG community throughout the years. Maybe you have any ICE videos about the benchmarking?
Thank you for the details in the tests.
Cheers!

[jonmoore]

The downside of filming a benchmark is that the screen capture process itself degrades the performance so that's a no go. But it's easy enough to put a test together. Just think in terms of typical Krakatoa particle effects - ink drops, particle clouds, magical effects and such like. These are effects where ICE can make optimal use of multiple cores. Try and make ICE become an SPH fluid solver (as Thiago Costa did in the early days of ICE) and you'll find ICE ends up being throttled to a single core. At the time FLIP solvers were in their infancy and nowhere near as performant as they are today so an ICE built SPH solver was a welcome thing, but judged by modern options it's nothing more than a badly performing academic exercise.

My take with ICE is that it excels in two core areas. 1.) effects built around the manipulation of vectors (deformation or particle), where it can make use of all the cores you throw it it. And 2.) custom built functionality that doesn't typically ship with DCC's. The second category's value isn't generally judged by performance criteria and make up a sizeable chunk of the great things ICE has been used for over the years. ICE's core value is that it enables the artist to do things their DCC couldn't otherwise achieve; and on that basis performance isn't so critical as a value judgement criteria.

This is another of the reasons that I'll continue to rely on my 2015 install for the majority of things I do in XSI. But it's good to know that 2014 will provide a little more grunt for those times when I'm looking to manipulate particle counts in the tens of millions.

[opoppopopp]

I just remember I create this post back in last year...

https://www.si-community.com/forum/v ... 236#p62236

[jonmoore]

I just remember I create this post back in last year...

https://www.si-community.com/forum/v ... 236#p62236

There's a number of factors slowing that scenes performance but the most critical one is the viewport display. If you change your particle display to points of 1 pixel and only show 5% of those points, the performance is far better. Plus, most of those old demo scenes were created with XSI 7 and the compounds aren't as well optimised as later iterations of ICE (it's my understanding that Soft loads the original node Dll's for scenes built with previous versions so that render results remain predictable when loaded into later versions). Also the State Machine nodes are well known to be a sketchy and the scene also relies of a second Clone Points tree, which adds a another performance hit.

On my set up, once the Particle Display changes have been set the vast majority of frames fly by starting at 60+ fps and never fall below 15 fps all the way to frame 400 (in 2015, 2014 falls to 17/18 FPS) . The spawning behaviour is the major slow down on later frames as that's a further parallel evaluation challenge (the CPU scheduler finds it harder to distribute the task across the available cores). In terms of processor utilisation, my setup varies between 25 and 30% when using 2015 SP2. 2014 SP2 delivers 30-35% utilisation all the way to frame 400.

An important thing to recognise when it comes to particle parallel evaluation, is that you'll get closer to 100% utilisation with larger particle counts (100K plus per second). When you have smaller particle counts it's actually more expensive to attempt to parallelise the task than it is to run on a lesser number of cores. The CPU scheduler should be smart enough to make these decisions for you behind the scenes. Intuitively, this feels wrong but it's simply the nature of the beast. I've never read anything explicit about how the scheduling occurs with ICE but in Houdini when working with VEX, the rule of thumb is that anything less than 1024 calculations per cycle will run faster on a single core.

[opoppopopp]

I just remember I create this post back in last year...

https://www.si-community.com/forum/v ... 236#p62236

There's a number of factors slowing that scenes performance but the most critical one is the viewport display. If you change your particle display to points of 1 pixel and only show 5% of those points, the performance is far better. Plus, most of those old demo scenes were created with XSI 7 and the compounds aren't as well optimised as later iterations of ICE (it's my understanding that Soft loads the original node Dll's for scenes built with previous versions so that render results remain predictable when loaded into later versions). Also the State Machine nodes are well known to be a sketchy and the scene also relies of a second Clone Points tree, which adds a another performance hit.

On my set up, once the Particle Display changes have been set the vast majority of frames fly by starting at 60+ fps and never fall below 15 fps all the way to frame 400 (in 2015, 2014 falls to 17/18 FPS) . The spawning behaviour is the major slow down on later frames as that's a further parallel evaluation challenge (the CPU scheduler finds it harder to distribute the task across the available cores). In terms of processor utilisation, my setup varies between 25 and 30% when using 2015 SP2. 2014 SP2 delivers 30-35% utilisation all the way to frame 400.

An important thing to recognise when it comes to particle parallel evaluation, is that you'll get closer to 100% utilisation with larger particle counts (100K plus per second). When you have smaller particle counts it's actually more expensive to attempt to parallelise the task than it is to run on a lesser number of cores. The CPU scheduler should be smart enough to make these decisions for you behind the scenes. Intuitively, this feels wrong but it's simply the nature of the beast. I've never read anything explicit about how the scheduling occurs with ICE but in Houdini when working with VEX, the rule of thumb is that anything less than 1024 calculations per cycle will run faster on a single core.

Thank you for this informative post!
BTW. including those discussion in that ICE kinematics thread, by the fact that we only get more core count other than frequency in our CPU, My whole purpose is hope things can SCALE better, at least those tasks which are inherently scale-able.