Hi Marc, it's irrelevant. DataTrees or no DataTrees, the problem lies elsewhere.
-- David Rutten [email protected] Robert McNeel & Associates On May 14, 5:34 pm, Marc Syp <[email protected]> wrote: > 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 <[email protected]> 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 > > [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 -- Hide quoted text - > > > - Show quoted text -
