dimven
commented
6 years ago Currently the only node that uses multi-threading in the entire package is "Mesh.ToPolySurface" and that is hard-coded to 4 threads. If you're wondering why four, that's because even the most generic i3 desktop or i5 laptop nowadays comes with 2 physical cores and 4 logical ones. While at the same time if we try to assign more threads on a more powerful multi-core system, we quickly hit diminishing returns with that particular workflow. We can only serialize part of the code (particularly the part that generates surface instances from the list of points and indexes) and are limited to sequential execution in the data extraction and aggregation portions of the script. Luke's post describes why and how this is in much greater detail.
Your second link talks about C-python (the original python implementation that gets interpreted down to C code). You have to remember that Dynamo is primarily developed in c# and uses the dot.Net ecosystem That means that when we run a python script, it actually gets interpreted down to dot.Net's IL (Intermediate Language) and runs in the same VM environment as the rest of Dynamo. This is why the built-in python scripter works great with c# assemblies (such as Math.Net) but can not use native C python modules such as numpy and scipy. Dot.Net doesn't have the equivalent of a GIL and that means we can effectively use real multi-threading from a single process, as long as we're aware of the caveats of MT and avoid situations where we're writing to the same memory locations or creating race conditions.
While interacting with a Revit document through the API is always limited to a single thread, multi-threading is not disabled in the scope of Dynamo & Revit. The particular node is not circumventing anything. Just like in c#'s standard library, there are certain classes and methods which are thread safe and can be read from multiple threads and there are others which are not. What we do lack, is any documentation clearly stating the above and it's usually down to trial and error to see if a particular approach will work or not. After thoroughly testing it, I found out that this mixed serial - parallel - serial methodology works well for me and decided to share it mostly as a proof of concept.
Hi Dimitar, I've been reading up on multi-threading. My IT manager got a bit nervous about the idea of me distributing home made multi-threaded processes on our server. How exactly was I planning to prevent a script from hogging computing cores, so that other users would have to make do with less, or even end up staring at a frozen screen?
From what I've been reading, your use of the 'threading' method (it is called a method, right? Still learning) it is perfectly safe because the GIL will prevent the script from doing anything more than locking itself up due to a memory conflict. Also, Dynamo seems to prevent multi-threading, or does a Python node circumvent that somehow? But what I've been reading is years old, just on the top of the Google results. I'd be gratefull if you could share yor insights into multi-threading. For one thing, if the GIL actually does block parallel processing, how is it that your approach results in faster execution?
Links
http://dynamobim.org/forums/topic/is-dynamo-multi-thread-or-multi-core-or-both/ http://jessenoller.com/2009/02/01/python-threads-and-the-global-interpreter-lock/