Parallelize all the things
This is just a wild, flailing thought, but I get the impression there are a few areas of Blender that would benefit a lot from some kind of parallelization. Eg. from what I've heard (I haven't checked), the VSE, the compositor and some or all of the physics sims are all single threaded and CPU-bound, and consequently quite slow.
Obviously the focus is on getting 2.8 out at the moment, but maybe when things are calmer it'd make sense to do some sort of general triaging / strategizing / speeding up of the various afflicted areas. Maybe even contract someone with appropriate skillz to do it. I'd be up for putting a few bucks into such an enterprise, and maybe other people would too.
6 Comments
This doesn't seem like a specific enough suggestion, maybe suggest parallelization for a specific part?
@h.goudey: Well, this may be easy actually, to be done in two steps:
Most of this should be a simple find-and-replace in the code
@pietrobelgioco: I think Blender is mostly C not C++.
@pietrobelgioco: I seriously doubt it would be that simple in the majority of cases. While maybe there are some sequential loops that can be parallelized, most of the loops are loops for a reason, i.e. an iteration depends on the previous iteration. You can't just flatten out that for loop and expect it to work.
If you say it's simple, why not dive into the code and see what you can do? Your help would be appreciated I would think.
@h.goudey: I agree with you that it mostly wouldn't be as simple as that, but I also agree with pietrobelgioco that it might be worth undertaking as a systematic project rather than thinking of it as lots of unrelated tasks.
@h.goudey: Well, for what I saw so far, as rule of thumb, if you can convert a for loop using the stl::algorithm (filters, map, reduce, foreach), or using them directly instead (for instance a sort, for the more complex examples), and you are used a bit with functional programming, you can have most of the time a parallel piece of code out of the box and being able to ignore completely the complexity behind it.
True that, if you have a dependency graph of a certain complexity you may be forced to use a sequential process, or a slower algorithm to do the same task (i.e. to solve linear systems you can use the sequential Gauss-Siedel method, or the 10 times slower Jacobi method, although you may have to your disposal 30 times the computer power with a parallel approach) or some more sophisticated systems (Like graph coloring, which is not impossible, but there aren't libraries ready to use, so hard to implement)
Aaaaand...I had a look inside the source code, in particular inside Cycles and Bmesh, the first two that came into my mind for some speed up...Cycles is in C++ and it's already paralleled, Bmesh is in play old C... so nothing really ready to multicore cpus with STL -_-