The following extract is from this discussion: http://www.grasshopper3d.com/forum/topics/performance-of-grasshopper?

When it comes to performance in Grasshopper at present 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.

In the near future, 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.

--

David Rutten

david@mcneel.com

Poprad, Slovakia