Hi,
is it possible to tell inkscape to make use of more than one cpu? (while rendering, svg to png)
Florian
Florian Ludwig wrote:
Hi,
is it possible to tell inkscape to make use of more than one cpu? (while rendering, svg to png)
No, Inkscape is very much single threaded. Thinking about this, it would probably not be very hard to make Inkscape uses multiple threads on a low level, as long as it's so low-level it doesn't use any libraries (in particular, I seem to remember the garbage collector isn't thread-safe, but I'm not 100% sure about that) or anything else that might not be thread-safe, but nobody has done so so far.
It might make an interesting project if you know C++ and want to try your hands on this (for something like Gaussian blur it would simply involve letting two or more threads process separate parts of the image, which should be relatively easy to program). My guess is that it would be worth it (performance wise), at least for certain expensive operations, but I have no idea how much performance gain you'd really get.
I noticed that the next release of GCC is going to have OpenMP support. That could be a quick way to get some speedup in things that are essentially SIMD, like gaussian blur and other image filters.
--bb
On 4/7/07, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
Florian Ludwig wrote:
Hi,
is it possible to tell inkscape to make use of more than one cpu? (while rendering, svg to png)
No, Inkscape is very much single threaded. Thinking about this, it would probably not be very hard to make Inkscape uses multiple threads on a low level, as long as it's so low-level it doesn't use any libraries (in particular, I seem to remember the garbage collector isn't thread-safe, but I'm not 100% sure about that) or anything else that might not be thread-safe, but nobody has done so so far.
It might make an interesting project if you know C++ and want to try your hands on this (for something like Gaussian blur it would simply involve letting two or more threads process separate parts of the image, which should be relatively easy to program). My guess is that it would be worth it (performance wise), at least for certain expensive operations, but I have no idea how much performance gain you'd really get.
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
but I have no idea how much performance gain you'd really get.
On a dual core processor (and those are now all around) I guess its would benefit a lot of this since both cores are used and not just one. (Or if you have access to a 4-cpu @3.2 ghz server you would render an image with lots of blur in very little time :)
Florian Ludwig
Florian Ludwig wrote:
but I have no idea how much performance gain you'd really get.
On a dual core processor (and those are now all around) I guess its would benefit a lot of this since both cores are used and not just one. (Or if you have access to a 4-cpu @3.2 ghz server you would render an image with lots of blur in very little time :)
Obviously :) But that is only true for the parallelizable parts, and you're also adding a bit of overhead (although I expect it won't be too much). And then there is always the problem of limited memory bandwidth of course.
So the speedup will definitely be less than 2, the only question that remains is how much less. If it's 1.5, well, that may be worth it. If it's just 1.0001 or something like that (or even less than one) it would be dubious.
BTW, have a look at http://en.wikipedia.org/wiki/Amdahl%27s_law if you're interested in this sort of thing.
On Mon, 09 Apr 2007 15:26:43 +0200, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
So the speedup will definitely be less than 2, the only question that remains is how much less. If it's 1.5, well, that may be worth it. If it's just 1.0001 or something like that (or even less than one) it would be dubious.
Threads for rendering are a non-starter right now, at minimum unless we can entirely remove the use of SPStyle from NRArenaItem -- the locking issues are just too complex otherwise, and it is likely that we'd simply end up having to serialize the rendering threads, leading to something like that 1.0001 scenario.
(we'd also need to be careful about using the garbage collector in conjunction with multiple threads, but that's not an insurmountable problem in itself)
-mental
On Mon, 9 Apr 2007 8:48:59 -0700, MenTaLguY <mental@...32...> wrote:
Threads for rendering are a non-starter right now, at minimum unless we can entirely remove the use of SPStyle from NRArenaItem
Actually ... there are a lot of other things which would need to be done as well, like the cairo migration. Livarot's path representation keeps rasterization state in the path object itself, so it simply can't be shared between threads.
-mental
On Mon, Apr 09, 2007 at 08:51:10AM -0700, MenTaLguY wrote:
On Mon, 9 Apr 2007 8:48:59 -0700, MenTaLguY <mental@...32...> wrote:
Threads for rendering are a non-starter right now, at minimum unless we can entirely remove the use of SPStyle from NRArenaItem
Actually ... there are a lot of other things which would need to be done as well, like the cairo migration. Livarot's path representation keeps rasterization state in the path object itself, so it simply can't be shared between threads.
As well, one could argue that given the difference in rendering performance between livarot and cdraw, there is still performance optimization gains to be achieved, that may be more beneficial to shoot for, if people are interested in working on extending Inkscape's cpu performance.
IIRC, a year ago memory limitations were a larger concern than cpu?
One last question with threading - with extensions IIRC they currently block until the child is complete; if extensions could be done as independen sub-processes, could that address any of the use cases where cpu performance is an issue?
Bryce
On Mon, 9 Apr 2007 09:47:02 -0700, Bryce Harrington <bryce@...983...> wrote:
As well, one could argue that given the difference in rendering performance between livarot and cdraw, there is still performance optimization gains to be achieved, that may be more beneficial to shoot for, if people are interested in working on extending Inkscape's cpu performance.
cairo should help there too -- it isn't up to cdraw levels yet, but I understand recent versions have gotten faster than livarot for many things.
IIRC, a year ago memory limitations were a larger concern than cpu?
Yes, and in fact memory issues with livarot are still the main driver behind cairo migration.
One last question with threading - with extensions IIRC they currently block until the child is complete; if extensions could be done as independen sub-processes
Strictly speaking, I don't think that's something we would need to use threads to address. If we did not block, we would still need to disable interaction for those windows with the document that the extension is currently operating upon.
could that address any of the use cases where cpu performance is an issue?
Probably not. Although we can make the experience a little nicer, the user has to wait for the extension to complete one way or the other.
-mental
Bryce Harrington wrote:
On Mon, Apr 09, 2007 at 08:51:10AM -0700, MenTaLguY wrote:
On Mon, 9 Apr 2007 8:48:59 -0700, MenTaLguY <mental@...32...> wrote:
Threads for rendering are a non-starter right now, at minimum unless we can entirely remove the use of SPStyle from NRArenaItem
Actually ... there are a lot of other things which would need to be done as well, like the cairo migration. Livarot's path representation keeps rasterization state in the path object itself, so it simply can't be shared between threads.
As well, one could argue that given the difference in rendering performance between livarot and cdraw, there is still performance optimization gains to be achieved, that may be more beneficial to shoot for, if people are interested in working on extending Inkscape's cpu performance.
Sure, but it never hurts to have some extra possibilities of course :) And with the increasing popularity of multi-core systems I think it is becoming an interesting area to start looking into.
MenTaLguY wrote:
On Mon, 09 Apr 2007 15:26:43 +0200, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
So the speedup will definitely be less than 2, the only question that remains is how much less. If it's 1.5, well, that may be worth it. If it's just 1.0001 or something like that (or even less than one) it would be dubious.
Threads for rendering are a non-starter right now, at minimum unless we can entirely remove the use of SPStyle from NRArenaItem -- the locking issues are just too complex otherwise, and it is likely that we'd simply end up having to serialize the rendering threads, leading to something like that 1.0001 scenario.
(we'd also need to be careful about using the garbage collector in conjunction with multiple threads, but that's not an insurmountable problem in itself)
Well, I was thinking about using threads at a slightly lower level, for example just for blurring. That way the code that is actually impacted by the use of threads is limited to a handful of functions that mostly just use arithmetic anyway (so no state). Most of the Inkscape code base essentially wouldn't even have to know about it. However, it would mean you're creating threads quite often (or having some kind of communication between threads to wake them), and I have no idea how expensive that would be.
On Mon, 09 Apr 2007 20:14:39 +0200, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
However, it would mean you're creating threads quite often (or having some kind of communication between threads to wake them), and I have no idea how expensive that would be.
It should be fairly straightforward -- maintain a pool of n threads (where n corresponds roughly to the number of processors), and submit work to them via work queues.
I suppose setting up a single bit of infrastructure for this purpose would probably serve us better than having people implement it ad-hoc everywhere. I may go ahead and do that since it's becoming apparent to me that we're not going to be able to ignore the thread issue for much longer.
-mental
participants (5)
-
Bill Baxter -
Bryce Harrington -
Florian Ludwig -
Jasper van de Gronde -
MenTaLguY