I would like to know if Grasshopper is still mainly a single-thread software? I have seen some posts that there has been some experimentation with some nodes, trying to create Multi-thread
Since I usually work with very big routines. (Thousands of nodes)
I want to know if someone could orient me regarding which will be the best processor to have in my PC? A multi-thread, single-thread, dual-core.
What part does Rhino plays when you bake geometry, mostly 2d lines.
Has anyone done some kind of experimentation about this?
Does writing my own nodes in python makes any difference?
Between Xeon and Intel or AMD does it really makes any difference?
I will be doing some experimentation about this and I will share it with you. However, any previous experience pointing me in the right direction can save me valuable resources.
Yes. There are some components which use multithreading, but it’s just a few.
That’s something you may want to look in to. There are really only downsides to giant networks. Lots of memory usage, long processing times, difficult to read, edit and debug, difficult to work on as a team…
I know it’s not easy splitting up a file in GH1 (data output/input components, scripts, and clusters are your only options, none of them great), but you must be in significant pain already with files this big.
The advice hasn’t changed much for Grasshopper 1. Fewer faster cores are better than many slower cores. However if you’re looking to buy a machine for the next 5—10 years, you may well want to go for more cores as that will make a difference in the future.
As David mentioned, GH is still mostly single threaded. My experience across a variety of computers over the years has been pretty much the same though. While different computers may have measurable differences most high end computers “feel” the same. By that I mean for what ever the computer, definitions go from being live updating to input changes needing a second to update and finally to the dreaded value changes lock GH for several seconds and you finally get the update with very similar workloads.
I find refactoring becomes part of the computational design process. You start by quickly exploring, things eventually get out of hands and you tidy things up and use more robust and quicker methods as you funnel down to a solution. Breaking up large definitions into several smaller one and using Elefront to pass data can be a good solution if this is an architectural type project. Otherwise, breaking things off with Data Dams is good too. Sometimes, it’s possible to make a fast visualization portion to a definition to allow you to quickly iterate and have a secondary slower final geometry version.
Python in Grasshopper is a bit hit in miss. There might be better info floating around the forums on this but some operations are surprisingly just as quick as C# and some stuff is crazy slow.
I personally think that spending so much energy on hardware requirements is really not helpful. The reason is simple. Chances are quite low that a definition potentially executes in realtime on one PC but not on the weaker equivalent. If you have a fast algorithm its likely to perform well one any modern machine, whereas a bad algorithm does perform weak on any as well.
And to be honest, whats the difference in waiting 2 or 4 minutes to finish a computation? If its up to the money then rather choose the weaker hardware and buy some good books from the money you save. But if you plan to earn good money from your work then really take the best and never look back. It will return the investment at some point.
Nah, after using computers for…35+ years now, hardware questions are getting more and more tedious. Benchmarks are kind of bunk, what’s going to be “ideal” for you varies widely, unless your budget is really low anything you get is likely to work–it’s not like the PC isn’t spending most of its time sitting waiting for your input!–and there are literally hundreds of experts on YouTube to teach you about the minutiae if you really care. Wait as long as you can, spend as much as you can, don’t look back.