[Maya-Python] Parallel Evaluation Examples

[Marcus Ottosson]

Hi all,

Sparked by an interesting thread recently, I’m trying to get a better handle on the new evaluation mode in Maya 2016+, and am looking for examples of where it has a positive impact.

Conceptually, I think it makes sense; if something can run in parallel across multiple CPU cores then it should.

Based on only this idea, these are some of the examples I’d expect to be a good fit.

1. 1 sphere or 1,000,000 vertices, deformed by an animated lattice
2. 1,000 spheres, animated independently of each other
3. 4 independent hierarchies of objects with 100 children each

For (3), I’d expect a 4x performance increase on a 4-core system.

But that’s not what I’m seeing.

evaluation=off: 107.23 ms
evaluation=parallel: 406.81 ms
evaluation=parallel, nodeType=untrusted: 421.11 ms
evaluation=parallel, nodeType=parallel: 407.96 ms

• https://gist.github.com/mottosso/ee34d1f1819efb7251abf08ae3532346

Here, 4 independent hierarchies, each of depth 100 driving a cube via a parentConstraint. Interestingly, a 4x decrease of performance on my 4-core system.

Here you can see the infinitesimal effect parallel mode has.

Compared with DG mode…

Notice the small orange strokes on the other threads in parallel, this is what they are:

My question to you is..

1. What is a good example of parallelism amongst many nodes? (As opposed to parallelism in a single node, like a deformer)
2. Is stepping through frames via cmds.currentTime a reliable metric for determining the effect of parallelism? What is better?
3. If so, why is it faster without parallelism?
4. Why doesn’t setting all node types to “untrusted” the same as evaluation=off?
5. Can I instruct Maya to assign a series of nodes to a given core myself? E.g. if I know up-front that there are 4 independent hierarchies.

If found that with currentTime(update=False), their timings are all equal, which is what I’d expect. Additionally, without refresh(suspend=True) the timings are much higher and more similar, which I’d expect is due to the small difference in parallelism getting lost in the much higher cost of drawing.

I’m particularly interested in parallelism amongst multiple nodes, like hierarchies of objects with lots of connections, like control rigs, and less interested in parallelism within a single node.

In addition to examples, if anyone knows of any more references than the ones below, please share.

Reference

• Using Parallel Maya
• Cult of Rig
• ?

Best,
Marcus

​

[Joe Weidenbach]

The first thing to realise about Parallel Evaluation is that it's different than DG evaluation -- A lot of the assumptions we made for DG mode are incorrect when considering parallel mode. The second piece is that it's buggy in 2016 (for example, nodes will still be evaluated even if they're hidden -- this is fixed by 2018).

Parallel is optimised for viewport playback, and makes assumptions based on this (indeed, when interacting with a single node, you're still in DG mode, not parallel -- it only affects playback).  One of these assumptions is that all nodes in the graph will be evaluated, rather than just those that changed.  So, the first thing you must do is ensure that the nodes in DG evaluation don't benefit from caching (an easy way to do this is to assign keyframes to each DG graph at the base level, which will invalidate the caches on each frame).  If this is not the case, it's very possible that your DG mode will be faster than parallel due to automatic caching.

The other piece to recognise is that there are lots of little things which will break Parallel evaluation and cause a fallback to DG -- a big example of this is use of expressions, or python-based nodes.

The canonical use of evaluation for many nodes would be a character rig (or many character rigs). There are many segments of a rig that can be evaluated in parallel, even though the top-level nodes need to wait for the lower-level nodes to be evaluated.  The key is that you have LOTS of independent nodes in the node graph that are not dependent on each other and that the evaluation manager can break them up and assign dependencies on a node-by-node basis. If you just have four independent hierarchies, then it can process those DG graphs on four threads, but there's still a cost for the thread setup.

I'd suspect (without looking at your scenes) that the reason you're seeing faster DG times is the first piece.  Caching is just not enabled for parallel mode (the assumption is that it's faster to just run through things than to check if it needs to evaluate a node).  If you have animation tied into each system from the get-go, you'd likely see different results.  Otherwise, I'd need to actually look at your scenes and the profiler to figure out what's going on.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC8_z1c4fyBrpff42-D3GzdY1eGyG3r5b42ZAVXuT%3DNVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Marcus Ottosson]

Thanks Joe.

The other piece to recognise is that there are lots of little things which will break Parallel evaluation and cause a fallback to DG — a big example of this is use of expressions, or python-based nodes… The key is that you have LOTS of independent nodes in the node graph that are not dependent on each other and that the evaluation manager can break them up and assign dependencies on a node-by-node basis. .. If you just have four independent hierarchies, then it can process those DG graphs on four threads, but there’s still a cost for the thread setup.

This all makes sense, but what I’m really looking for is an example of is. What is “lots”? How can I construct a scene that actually does improve? What are the ideal circumstances and how can I know?

I’d suspect (without looking at your scenes) that the reason you’re seeing faster DG times is the first piece.

I set branches = 100 and re-ran the example, and presto!

evaluation=off: 132.83 ms
evaluation=parallel: 131.48 ms

Equal timings. So equal in fact that it was suspicious.. so I set it back to branches = 4 and..

evaluation=off: 132.74 ms
evaluation=parallel: 133.52 ms

Now I’m unable to reproduce the initial results at all, even in a new instance of Maya or a different machine, even though those results were consistent every time I ran them in that one session. Curious.

Let’s ignore that example for now and move back to the start, what is any example of parallelism amongst multiple nodes? Even if it’s just a 10% increase in FPS.

​

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC8_z1c4fyBrpff42-D3GzdY1eGyG3r5b42ZAVXuT%3DNVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAM33%3Da5e9KiUFGBtQfsTA5wp1gWjK-j%2Bv32sy_RPAx4Y4H6n4Q%40mail.gmail.com.

[Marcus Ottosson]

I’ve added another method of measuring performance.

1. profile1 - Measure by repeatedly calling cmds.currentTime(time, update=True) and keeping track of time. Lower is better.
2. profile2 - Measure by playing back for a fixed set of time, e.g. 3 seconds, and query what frame you end up on. Higher is better.

profile2 takes into account viewport refresh, whereas profile1 does not.

• Gist

Now I’m looking for more scenes, anything that can produce a measurable effect of parallelism.

​

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOC8_z1c4fyBrpff42-D3GzdY1eGyG3r5b42ZAVXuT%3DNVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscribe@googlegroups.com.

[Alok Gandhi]

Tons of valuable information here. This is all gold to someone who wants to dig.

Thanks all for the insights and kudos for Marcus for clear, to-the-point examples and investigation.

Cheers!

- Alok

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA9Hf%3DNDp%2By2wHR73MFBso%3Dz6VzopbKT2eitr00JgzKtg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Marcus Ottosson]

My pleasure, Alok. Thanks for the encouragement.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOA9Hf%3DNDp%2By2wHR73MFBso%3Dz6VzopbKT2eitr00JgzKtg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMQgW05XNc3L8HthqWjRdnVTausW%3DwDMc3H2ZJOW21q5Qw%40mail.gmail.com.