Re: [Gimp-user] multi-threaded Gimp
Hi, On 10/19/2012 10:29 PM, Liam R E Quin wrote: so if one would allocate a target memory area in RAM first and then fill the mem map with the to-be-saved data one could open a file handle right from the start and copy the mem portions to disk as they get filled by the compression algo. The problem with this is that you don't know in advance how much memoro to allocate or where to write, because the compression varies depending on patterns of light and dark (for example) in the image. I've never actually coded png compression so correct me if I'm wrong. If you have n cores. You allocate n blocks of memory assuming worst compression outcome and start to parallely compress blocks you only use a reasonably small amount of memory. (n times the worst case size of a png tile). For each block that is ready and can be appended to the disk file, you write out the block ans start to compress the next unhandled block. Of course this is asynchronous as some blocks will finish to compress before the next-to-be-written-out is still working, but you still speed up compression by a big factor and still have a small and static compression buffer. If you add a write-out-queue you can achieve a more effective parallelism while still limiting memory usage. Just my 2c. Bye Bgs Or another approach would be make a copy of the image in RAM and do the save in the background. That way when using the same file name one would even narrow the state transition of the file to a minumum. It's done in a separate process right now, but copying the image in memory, if it's, say, a one gigabyte image, might be problematic. And the images that need to be sped up are the fast ones. It might be faster in some cases for gimp to do a "merge visible layers" before a save, I don't know. Liam ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On Fri, 2012-10-19 at 16:50 +0200, Dexter Filmore wrote: > Am Thursday 18 October 2012 21:05:35 schrieb Jernej Simončič: > > On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote: > > > I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. > > > > If you're talking about saving a file, there's not much that can be done - > > saving isn't something that can be parallelized. > Well... writing to disk sure can't, but I guess there are image compression > algos that can utilize multicores? After all, formats as png and jpg as far > as I know, correct me if I'm wrong, tile the image and work on the tiles > first. Yes, both jpeg and png are amenable to some thread support. For that matter, disk writes can be parallelized and this can in fact help with perceived performance, although it an also make the system so busy it appears to "freeze up" during a save. Since saving a PNG file takes several minutes even on fairly fast computers I can sympathize with the desire to make it go faster. > so if one would allocate a target memory area in RAM first and then fill the > mem map with the to-be-saved data one could open a file handle right from the > start and copy the mem portions to disk as they get filled by the compression > algo. The problem with this is that you don't know in advance how much memoro to allocate or where to write, because the compression varies depending on patterns of light and dark (for example) in the image. > Or another approach would be make a copy of the image in RAM and do the save > in the background. That way when using the same file name one would even > narrow the state transition of the file to a minumum. It's done in a separate process right now, but copying the image in memory, if it's, say, a one gigabyte image, might be problematic. And the images that need to be sped up are the fast ones. It might be faster in some cases for gimp to do a "merge visible layers" before a save, I don't know. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
Am Thursday 18 October 2012 21:05:35 schrieb Jernej Simončič: > On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote: > > I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. > > If you're talking about saving a file, there's not much that can be done - > saving isn't something that can be parallelized. Well... writing to disk sure can't, but I guess there are image compression algos that can utilize multicores? After all, formats as png and jpg as far as I know, correct me if I'm wrong, tile the image and work on the tiles first. so if one would allocate a target memory area in RAM first and then fill the mem map with the to-be-saved data one could open a file handle right from the start and copy the mem portions to disk as they get filled by the compression algo. Or another approach would be make a copy of the image in RAM and do the save in the background. That way when using the same file name one would even narrow the state transition of the file to a minumum. Just an idea. -- -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(+)@ s-:+ a C UL++ P+>++ L+++> E-- W++ N o? K- w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ b++(+++) DI+++ D- G++ e* h>++ r* y? --END GEEK CODE BLOCK-- ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On 10/18/2012 09:05 PM, Jernej Simončič wrote: On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote: I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. If you're talking about saving a file, there's not much that can be done - saving isn't something that can be parallelized. It's not only saving. When you save a .png, you compress it. Saving with Gimp is slow because it compress .png . Saving .xcf is very quick because no compression, I think... Greetings -- Maderios "Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On Thu, 18 Oct 2012 13:47:56 +0200, maderios wrote: > I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. If you're talking about saving a file, there's not much that can be done - saving isn't something that can be parallelized. -- < Jernej Simončič ><><><><>< http://eternallybored.org/ > ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On 10/18/2012 07:10 PM, scl wrote: Alexandre Prokoudine wrote: On Thu, Oct 18, 2012 at 3:47 PM, maderios wrote: Any solution about a multi-threaded Gimp ? Not in the stable version, sorry. What about the 'Number of processors' option in the Preferences/Environment dialog? Preferences/Environment processors to use 8 Regards -- Maderios "Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
Alexandre Prokoudine wrote: On Thu, Oct 18, 2012 at 3:47 PM, maderios wrote: Any solution about a multi-threaded Gimp ? Not in the stable version, sorry. What about the 'Number of processors' option in the Preferences/Environment dialog? Kind regards, Sven ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On 10/18/2012 01:55 PM, Alexandre Prokoudine wrote: On Thu, Oct 18, 2012 at 3:53 PM, maderios wrote: Not in the stable version, sorry. May be in the future ? Sure :) Thanks. So we wait... Regards -- Maderios "Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On Thu, Oct 18, 2012 at 3:53 PM, maderios wrote: >> Not in the stable version, sorry. > > May be in the future ? Sure :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
Re: [Gimp-user] multi-threaded Gimp
On Thu, Oct 18, 2012 at 3:47 PM, maderios wrote: > Hi > When saving png image (ex 4496 × 3000 pixels) Gimp is very slow. > I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. > Any solution about a multi-threaded Gimp ? Not in the stable version, sorry. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
[Gimp-user] multi-threaded Gimp
Hi When saving png image (ex 4496 × 3000 pixels) Gimp is very slow. I have a Core I7 with 8 cpu. I noticed Gimp use only 1 cpu to save image. Any solution about a multi-threaded Gimp ? Best regards -- Maderios "Art is meant to disturb. Science reassures." "L'art est fait pour troubler. La science rassure" (Georges Braque) ___ gimp-user-list mailing list gimp-user-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-user-list
