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 [email protected] Robert McNeel & Associates On May 14, 2:37 pm, damien_alomar <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 -
