ARCHITECTURE: Inkscape performance unaffected by multi-core / CPU setups

[Troy James Sobotka]

Summary: With the advent of multiple core setups, Inkscape's performance by relying on a single core is potentially crippling its future. It would seem logical and progressive to begin the transition into multiple core rendering / performance augmentation at this point. Current Inkscape technology limits the ability to create complexity as a result of this hindrance.

Symptoms: Slow rendering times, slow export times, etc.

[MenTaLguY (mental-deactivatedaccount)]

It's a nice thought, but it's going to be a while before we'll be able to do much about it; the codebase is pervasively non-threadsafe.

Rendering is the most obvious candidate for multiple core support, but if we start using hardware acceleration, then multiple rendering threads are actually a liability (they end up wasting IO bandwidth to the GPU). So we need to be prepared to use different strategies depending on the availability of hardware acceleration, etc.

[Troy James Sobotka (troy-sobotka)]

Wouldn't rendering be more well suited to multi-cpu task?

As I understand it, every graphics card vendor will implement different techniques to achieve a common goal. This would seem to break consistency across platforms.

Using the CPU cores would allow the algorithms (blur for example) to be 100% consistent regardless of platform. Is this a correct assumption?

[jazzynico (jazzynico)]

Multi-threading for blur operations is available in 0.48 in the preferences dialog.
It is also implemented in 0.47, but you need to add the following line in preferences.xml manually:
<group
   numthreads="2"
   id="threading" />

[DanHeywood (heywood-photography)]

After adding those lines to preferences.xml (on an Intel Core 2 Duo, iMac, OS 10.6), I timed how long an illustration with blur took to zoom up one step in 0.47. It was exactly the same speed/time as without the multi-threading enabled. Using the same illustration, I also compared the time it took to "select all in all layers," and this too was the same time with or without multi-threading enabled. Are these tests appropriate, or would speed improvements be found in some other ways when using blur and multi-threading? Or perhaps there is some error in how I attempted to enable the multi-threading.

Note: preferences.xml on Mac is found by the steps shared by zipe here: http://www.inkscapeforum.com/viewtopic.php?f=29&t=884&start=25

[DanHeywood (heywood-photography)]

...Put that thought on hold. I just saw that I was changing the preferences.xml of 0.46. I'll come back when I do it right :)

[su_v (suv-lp)]

0.47 and later uses ~/.config/inkscape/preferences.xml
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#Preferences>

[DanHeywood (heywood-photography)]

Thanks ~suv, I was able to do it correctly this time. I also downloaded the current Mac OS 10.6 build of 0.48, and tried out the thread feature there too. With threads set to two on my Core 2 Duo, neither 0.47 or 0.48 had any increased speed with my one step zoom test on an illustration with blur. In fact, the 0.48 was 1-2 seconds slower in completing the zoom of a blurred illustration when I set threads to 2. Maybe I should start a new thread, as this is related too, but different than the original post in this thread.

[Airwave (airwaveindehouse)]

More Speed, please devs, i think the performance shoult be better in future.

my dual core should be able to make it possible.

thanks

[Teto (teto45)]

Same problem here. Has a 2 core quad, 8 Mega of memory, Seven 64, and everything is okay except if I use filters. They're just exhausting my computer, and using 'medium quality' for filters is just impossible (too ugly - no offense).
Of course I can switch rendering (complete, without filter, just edges) but when you make new filter and there are many of them on the drawing...
So please, devs, do something :))

[Kris (kris-degussem)]

This issue has been worked on. See the main page of the inkscape website: one of the Google summer of code projects targeted rendering to Caïro which resulted in a performance increase. Simultaneously multicore support was introduced during this project and the plan was to work further on OpenCL implementation. Hopefully all this makes it into inkscape 0.49

[Troy James Sobotka (troy-sobotka)]

I bug beg anyone concerned about performance on Inkscape to at least consider proxying. (See https://bugs.launchpad.net/inkscape/+bug/330271 for a more in depth explanation)

Basically, all of the above improvements, while hugely valuable and welcome, cannot fully eradicate heavy and complex imaging performance loss. This would be doubly so if Inkscape ever lands deep linear colour and is compounded as images grow in complexity.

So, as we can clearly see, the more powerful Inkscape passes and such will inevitably require some backend rendering time. The future will only increase the loads.

To alleviate this, there can be only one solution: To bake | render | proxy the information.

Proxying would be a final and workable solution for those that seek to create complex works under Inkscape. It would be part of this equation as well, as proxying could use tiles to render the proxy across multiple cores.

[theAdib (theadib)]

any reason why this option can not be edited by the inkscape settings dialogue?
Why should inkscape not use ALL cores available?

[Kris (kris-degussem)]

Inkscape uses multithreading for all cores since trunk revision 10326.
However, due to license restrictions in MacOs X, there are problems with compile Inkscape with OpenMP support. So currently mulithreading support can not be generally released for inkscape. On Windows and linux you can enjoy a massive speedup using a recent development version of Inkscape.

[su_v (suv-lp)]

> Inkscape uses multithreading for all cores since trunk revision 10326.

Note: this is limited to the rendering of SVG filter effects, and does not apply to the rest of the application.

> due to license restrictions in MacOs X, there are problems with compile
> Inkscape with OpenMP support.

The underlying issue is the rather old version of GCC Apple provides with Xcode [1] . Due to license changes in GCC, Apple will never upgrade to a later GCC version than 4.2.1, and eventually drop GCC completely in favor of CLANG. Building Inkscape with a custom-installed newer GCC version doesn't work out-of-the-box due to ABI conflicts in linked C++interface libraries [2].

Update: Since the time I had discussed the details impeding OpenMP support on Mac OS X with Kris on irc, I did manage to produce stable builds of 0.48.2, 0.48.x and current trunk with full OpenMP support (64bit builds with GCC 4.6.2 (MacPorts) on OS X 10.7.2 Lion). I'm currently working on a shell script as 'proof-of-concept' and to allow easier testing of the build setup on other systems. The script does not create a bundled osx application yet (this might be added later on).

[1] <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/36355>
[2] <http://wiki.inkscape.org/wiki/index.php/FAQ#On_Linux.2C_Inkscape_crashes_with_.22invalid_pointer.22_message>