I'm a complete laymen when it comes to programming, so this is probably a really stupid "suggestion"... but doesn't the data tree structure lend itself to multithreading? That is, within a single component, when the calculation initiates, isn't there a way to separate independent calculations/operations done within each path? Take a mass addition component with 4 paths, N=9. Couldn't the component send each path to a separate core? The performance increases for each component would seem to be drastic when you add it all up... but I suppose I'm missing something fairly major because if it were that easy, I'm sure you would have already done it. :P
Marc On May 14, 4:37 pm, David Rutten <da...@mcneel.com> wrote: > Hi Damien, > > you are right of course, and properly written code ought not give too > much problems when called from within a multi-threaded environment. > Meshing is indeed an excellent example of potential for multi- > threading. It might work on a number of levels: > > 1) Break the list of objects to mesh into N sublists and assign each > sublist to an individual core. This should be reasonably easy to do. > > 2) Break the polysurface into N sublists of faces, and assign each > face array to an individual core. Once they are all finished, the > meshing-post-process can start to stitch up all the edges. This is > obviously much harder to synchronize, but it would provide performance > increase for individual objects. > > 3) Break the entire meshing algorithm into loose parts, and have each > core only focus on a subset of vertices that belong to a single face. > This will be very tricky, and its not obvious that there will be a > performance increase because of all the logic overhead. > > The mesher is already written with threading in mind, so we should be > able to add this feature without having to rewrite too much code. > > I made a multi-threading test a while back in an attempt to speed up > the Contour command. Essentially assigning each contour section to a > new thread. This didn't work because the deep-down nurbs intersection > code in Rhino either stores intermediate data in global variables or > on the Brep object being intersected. Thus, once you call this > BrepBrep Intersection code from within two threads simultaneously, > they get confused because they keep overwriting each others > intermediate results. We have a lot of those functions in the core > which means there's no way we can just start implementing multi- > threading command by command. > > So it's actually much worse than you think. It's not just that we > (McNeel) won't go into MT anytime soon, but our 3rd party developers > also cannot do so because they have to rely on our non-thread-safe > core functions. > > The good news is that for Rhino5 we've started looking into this and > we've actually made some isolated bits and pieces multi-threaded. As > we become more comfortable and more experienced with MT, we'll be able > to slowly fix all the non-thread-safe functions in the core. No idea > how long this will take or if we'll even manage to fix ALL the > problems. > > What does this mean for Grasshopper: > > Since the order of operations inside in Grasshopper is totally > unpredictable (it depends on the network made by the user), I dare not > make GH components thread-aware. There are of course parts where > threading is possible (preview meshes or grasshopper-only-operations > for example), but I've disabled preview-meshing-threads for the time > being since there were some odd crashes and I didn't have the courage > to debug them. > > -- > David Rutten > da...@mcneel.com > Robert McNeel & Associates > > On May 14, 2:37 pm, damien_alomar <dominos...@gmail.com> wrote: > > > > > Thanks for the info Bob. I didn't realize that you guys had started > > using OpenMP. Although in most cases, rewriting some of those chunks > > of code to allow for multithreading might not really offer too much > > added benefit, I think there are still other places where smaller > > changes to allow for multithreading could be added. A simple example > > is something like meshing. If we're meshing more than one object why > > can't we have each object potentially meshed in its own thread? I > > think solving fairly basic multithreaded situations like that might be > > a good place to start and one where there is certainly a good deal of > > added benefit. Just my two cents from a guy who's not looking at the > > code and couldn't write it myself ;) > > > Best, > > Damien > > > On May 14, 12:52 am, Bob McNeel <bob.mcn...@gmail.com> wrote: > > > > The details are not simple... to get your head into the problem, start > > > by reading this article... all of it, along with the discussion. > > > >http://www.technologyreview.com/multicore > > > > Multicore programming is generally require a major rewrite of big > > > chunks of code. Often for very little improvement. Of course there are > > > exceptions, like raytracing which is already parallelized in most > > > applications include Rhino and Flamingo. > > > > There are tools to help. One example is OpenMP. We are using OpenMP in > > > Rhino 5, but my guess is that in most cases where OpenMP helps Rhino > > > is already so fast you won't be able to tell the difference very > > > often. > > > > To get your head deep into the topic, pick up a copy of "Using OpenMP" > > > from MIT Press. > > > > On May 13, 8:48 pm, damien_alomar <dominos...@gmail.com> wrote: > > > > > I'm not sure what you're hopes were based on, but AFAIK there are no > > > > multithreading additions for v5 or Grasshopper. Doesn't really matter > > > > what kind of system you have as its something that requires the > > > > attention of the Rhino developers and David. Last I asked (many > > > > months ago), David said that he attempted to try out some > > > > multithreading with GH, but had a lot of problems managing threads and > > > > a number of issues with some SDK functions not being thread safe. > > > > Unfortunately the response from McNeel on multithreading has been > > > > practically non-existent with the only "official" word being that > > > > "none of the functions in Rhino lend themselves to > > > > multithreading" (loose quote there). I personally don't buy that, but > > > > I'm just a lay person and that's really a discussion for another > > > > thread. > > > > > Best, > > > > Damien > > > > > On May 13, 5:17 pm, Marc Syp <marc....@gmail.com> wrote: > > > > > > So I installed Rhino 5 today in the hopes that it would allow my GH to > > > > > multithread, but alas my dual-core still maxes out at 50%... I'm > > > > > running 32-bit. Is that the problem?? We have 64-bit machines at > > > > > work but I don't want to go through the lengthy and politically > > > > > dangerous process of commandeering one of them if I will have the same > > > > > problem. > > > > > > Will I find a multi-threading solution soon? I find that I am limited > > > > > in GH only by access to more processing power, and it makes me very > > > > > sad... :( > > > > > > Marc- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -
