On Sun, 2008-03-16 at 19:31 +0100, Mihaela wrote:
I think its fair to say no software can, you always have parts that can be split to work on more than one core, and parts that can't (this part can even be tangled spaghetti code).
There's still the infrastructural issues; for example, we have to be careful about libgc until we can rely on the new versions with better thread support being widely available.
It would be worthwhile to analyze the code and see what parts are appropriate for multithreading. Maybe you would only find 2 or 3 such places, but the speed increase on multicore machines could still be very significant.
I've done this to an extent, actually. The biggest potential win would be rendering, although we have to be careful since once we start taking advantage of hardware acceleration, rendering becomes more of an IO issue rather than a computation one. (more threads tends to make IO worse rather than better, since you saturate your IO bandwidth quickly and start to take hits from multiplexing)
The biggest problem right now is that the rendering/arena code reaches up vertically through nearly every Inkscape subsystem, in large part via its dependency on SPStyle. Until we break that dependency, I don't have much hope about parallelizing rendering generally. The exception may be the rendering of SVG filter effects, the inner loops of which are relatively isolated from the rest of the code. Filter effects are also the least likely to get hardware acceleration anytime soon, so we don't have to worry about that complication either.
Most of the rest of the codebase isn't really going to parallelize well, ever; a lot of things like document operations and transactions are rather inherently serial. The performance problems there are also often more a matter of doing too much unnecessary work than anything else.
A few threads could be applied to improve UI responsiveness, and I'd eventually like to do that, but we'd need to be very cautious about non-determinism. We've already had some very nasty problems from non-determinism introduced by people naively using Glib idle tasks or calling back into the event loop from an event handler; threads would be several orders of magnitude worse in that respect.
The expert in multithreading I mentioned might help isnt familiar with Inkscape code and he'd need your input when it came to a specific case,
Could you bring him into the thread, maybe?
In the new version of gcc OpenMP will be implemented (i think its in experimental phase now). With it the parallelization will be much easier, so it would also be very good to implement OpenMP into Inkscape.
I believe gcc has had some OpenMP support in released versions since 4.2. OpenMP is rather limited in what it can do for us, but it should be helpful for optimizing some computation-heavy loops (filter effects again?). Generally I would like to try to avoid the use of explicit threading when possible, and OpenMP certainly fits that bill.
-mental