In an article, I read that: “Clusters cannot be computed parallel”
I assume this means that if the solver encounters a cluster, it will stop, enter the cluster, evaluate the solver there, and then – with the results from the cluster – resume execution of the main definition. However, as far as I understand it, Grasshopper is single threaded anyhow. From David’s post Let’s talk about Grasshopper 2.0: “Because we knew from the start that Grasshopper 2.0 needed to be multi-threaded, and you cannot ‘just’ parallelise single-threaded code.”
Take the following definition. I assume, that the divisions will be computed one after another, independent of whether packaged into a cluster or not.
Multi threaded parallel computation can be difficult to quantify performance gains or loos of performance. Many times it take smore time and memory to setup a multi-treaded setup. But then over time that loss in performance for setup can sometimes be overcome with many parallel calculations.
Clusters are not that sophisticated. They are simple a grouping mechanism for sections of the definition.
There are ways to run multi-treaded parallel in Grasshopper 1.
The impact on clusters is negligible. Clusters can help you in structuring your definitions. So you or a potential coworker performs better in maintaining your definitions. Other than that, you should not care about computational performance unless its obvious or required.
Premature optimization is evil!
If you need to optimize a definition, you either find a better combination of GH components, or you bypass Grasshopper as much as possible by writing your own code. It is helpful to have profiling skills, because many people don’t even know where the bottleneck is and begin to optimize the wrong part.
Whenever you don’t know how to improve performance, try to create a minimal example and post it here. Optimization topics are interesting threads in this forum, and often you get something faster😜
Thanks, but can this be quantified? negligible = O(1)?
I much prefer Hops for that, for reasons of readability and maintainability, but that’s for another topic.
That’s interesting, thanks! I’d prefer an authoritative answer by someone who knows how it works under the hood. Perhaps clusters are just fancy groups that get exploded before the solver does it’s job.
You cannot apply algorithmic complexity to a whole software component and evaluate performance. Nobody knows for sure. O(1) essentially means that you execute some system calls without iterating (over the data) again and introducing data-specific overhead. But this doesn’t quantifies overhead. Data is passed as reference, in contrast to script components, where data is copied for security reasons. (You can also bypass this when you deal with large sets of data), but still even if you re-iterate over the data, this can be negligible unless you deal with millions of data points. CPU’s are really fast nowadays!
Even if clusters would introduce significant overheat. It is still wrong to not use them, because you might create pseudo-optimised code, trading readability for a couple of milliseconds.
Other than that, also consider that the window needs to draw less, the less components are on the canvas. If you deal with a couple of thousand components, this can also matter performance-wise.
Really, its wrong and very one-dimensional to think about performance like this. If you have a concrete problem then start investigating…
