M4x wrote: ↑Wed Sep 29, 2021 5:03 am
The one CPU core thing depends on what's supported so far if I recall correctly. Not sure if the Sketcher WB normally uses more than one core at the moment.
The Sketcher does use two cores when doing QR decomposition, because it does two different QR decompositions in parallel. The first QR decomposition is formulated to obtain additional information about constraints (redundancy/conflicting). The second QR decomposition is formulated to obtain additional information on geometry (which elements are constrained an which are not). Both QR decompositions are equivalent from a computational point of view, and independent from each other (they are QR decompositions of a matrix and its transpose). The program continues as single threaded just after both results are obtained. This is the sole instance in which the sketcher uses multiple cores.
There is potential to add multi-threading to a second operation. After QR decomposition, the very big large system is "decoupled" in subsystems. These are solved (DogLeg) one after the other. It might be possible (to tell it for sure I would need to look deeper into it) to solve these in parallel. However, even when this is demonstrated possible, I am unsure how much improvement it may bring. These systems are for sure not equivalent in terms of computational requirements. In some cases they are extremely asymmetrical. Even if run in parallel, it is likely that any possible gain is negligible, as the cost of several processes is negligible and the overall time would be driven by the larger subsystem. In the extreme, it could even happen that the cost of firing and joining different threads is higher than the additional cost of having the light subsystems processed, leading to an increased of solving time by using multiple cores. Of course, in such a case, it should still be possible to decide whether to run parallel processes or do it iteratively depending on the size of the individual subsystems.
However, this actual solving of decoupled systems, in my experience, only takes long when there are convergence problems. This means that one of the subsystems, the one that would drive the overall time if run in parallel, would still determine the overall cost. In the other cases, it is fast, so probably no meaningful advantage could be obtained from making them parallel (even if time would be cut by 50%, which is quite an improvement, what is the difference between 0.3 secs and 0.15 secs?). So, all-in-all, it has remained a very low priority for me over the years, because I have the feeling that it would bring no meaningful advantage. So it is probably only worth as a theoretical exercise to test multi-threading skills.
In the present case, the solving time is clearly driven by the QR decomposition, so the gain, if any, would not be perceived, or even when it can be perceived, it would not still make the program "responsible".
