performance of grasshopper

Replies to This Discussion

Permalink Reply by Danny Boyes on April 13, 2011 at 3:14am

"We're gonna need a bigger boat"

This might not be a very helpful answer but, as far as I understand it, if you wish to increase the processing power for 3D modelling you need to get the fastest clock speed plus fastest memory and lots of it, that you can afford, included with a 64-bit system. The processes involved in Rhino and Grasshopper don't tend to lend themselves to multi-threading. Analytical work such as FEA or CFD are very much multi core orientated as is rendering. This is because they are doing lots of the same calculations but in different areas of the model at the same time. Grasshopper needs to be fairly linear in its approach as things at the end of your definition are waiting for things at the beginning to finish their calculations. You cannot jump the gun and split it up.

Now someone else can jump in here and correct all that I've said :)

Permalink Reply by David Rutten on April 13, 2011 at 3:47am

Ok. I shall.

 

You're right about the solution for now. Getting more cores won't help you much, getting a single fast core is a much better choice. Fast and lots of memory also helps a great deal.

 

That said, the processes that would benefit most from it in Rhino and Grasshopper actually lend themselves remarkably well to multi-threading. Things like Intersections, Meshing, operations on individual items in arrays would all benefit since they involve a lot of repetition where one iteration does not depend on the previous one.

 

Rhino4 was not designed to be threadsafe, and there were places where it was not possible to thread certain tasks. For example, imagine the Contour command. You'd think that it would be a piece of cake to thread that, you assign the first 25 contour intersections to core 1, the next 25 to core 2, the next 25 to core 3 and so on and so forth. But as it turns out intersecting a Brep and a Plane requires Rhino to build a spatial tree of the Brep first (assuming it doesn't exist yet). These trees vastly speed up a lot of operations and they are created lazily, meaning they get created the first time they are needed. Now we suddenly have four threads all trying to run a Brep Plane intersection and all trying to build the same spatial tree at the same time. This cannot end well. So in Rhino5 we made sure that when the spatial tree is getting build, every other thread that tries to access the Brep gets put on hold until the tree is done.

 

Then there's problems that the Intersection function might store temporary data on the Brep during the intersection, which makes threading intersections on the same Brep an absolute impossibility.

 

Then there's the even worse problem that the Intersection function might store temporary data in a static cache, which means you cannot run the function more than once at a time, even if it's on different Breps.

 

In Rhino5 we tried to rectify all of these problems. I think we got most of them by now.

 

When Grasshopper switches to Rhino5 for good, we'll start looking into threading a lot more seriously, not in the least because we'll also switch to .NET 4, which has some pretty cool mechanisms for writing decent MT code.

 

Until then, we'll have to stick to good old fashioned optimization. Christoph's problem was that it takes 12 minutes to open a file. Even if you thread that and you get 100% efficiency (which you won't, there's always additional overhead when threading) it would still take 3 minutes if you have 4 cores. It's an improvement sure, but not much of one. I'd like to know exactly where all that time is spend, then maybe we can remove specific bottlenecks.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Christoph Degendorfer on April 13, 2011 at 4:49am

Thanks David and Danny for the long explanation!

 

The most intense component I use is the Occlusion component with a lot of vectors. This one takes 7.3 minutes to calculate.

The definition is big so the rest of the computation time is because of the amount of components. There longest calculation time is about one second.

I was thinking to split the definition but I really want to keep it interactive from the start.

Im working mostly in the end of the definition so that the majority does not need to be recalculated accept in the beginning.

 

Maybe it would help if the result of a definition is stored in the ghx file so that it is "referenceable" from other files and must´n be opened/calculated every start.

Like advanced clusters...

Just an idea

 

in the meantim i´ll optimize the definition as you mentioned.

 

christoph

 

My System:

Quad CPU Q9300 @2,50 GHz

8 GB RAM

NVIDIA Quadro FX1700

64 bit

Attachments:

• definition_complete.jpg, 206 KB
• definition_part.jpg, 373 KB