Sorry for the question: is it out of the little time wip Rhino 6; the development of the new version, it should be faster than switching from Rhino 4 to Rhino 5, since we do not need to rewrite all the code from scratch, or not?
The engine of intersection of the next version will be the same then?
Basically anything that might be scripted. While there are high frequency CPUs around, the trend is clearly towards multi-core, low frequency.
It really sucks to wait minutes for a medium sized script to finish while the CPU literally sits idle.
With Grasshopper and scripting being an integral part of Rhino now, I think the design factor for commands execution speed should be automation, not user interaction… And user experience would profit for heavier operations where users currently see a delay in execution.
I am aware not every operation lends itself to parallelization, but that’s the point. Find out what can be done and do so. And if it can’t be done, at least make it thread safe.
Scripting is a linear operation and not easily threaded (since the next thing to be scripted is dependent on the current one finishing).
I’m not sure how you measure the “size” of a script. But the size has no correlation with the speed of execution.
We are always in the process of doing this…
Try to keep in mind that multithreading is not the holy grail of performance. Certainly some features can and will benefit from multithreading. But many operations, that appear to be good candidates, won’t see any benefit from multithreading. And, there is overhead for setting multiple threads, which can negate any performance gain.
I need to clarify: when i am talking about scripts I am generally thinking grasshopper. While grasshopper still executes left to right, it could make massive use of multithreading. So when I talk about medium sized scripts, I think about grasshopper generating a few hundred copies.
Then again, the script interface is just one way to make use of Rhinos functions. I couldn’t make a RhinoCommon plugin multithreaded, because there just is no guarantee, the functions are thread safe.
So the second thing I want to clarify is, when I am talking about focus on multithreading, I am talking about the possibility of using the SDK in a multithreaded environment. I do not mean to make every command use multiple Threads.