Re: Speed of Gimp
VosSedai wrote: > > Before I get flamed for this... I know its slightly off topic and doesnt > help but.Photo shop is what? lets see here version 6 from US $609 GIMP > is .. > free. "nuff said" > > VosSedai why be flamed for that? word i say -- tobbe www.phatsidedesign.com
Re: Speed of Gimp
Before I get flamed for this... I know its slightly off topic and doesnt help but.Photo shop is what? lets see here version 6 from US $609 GIMP is .. free. "nuff said" VosSedai "Cynics are made, not born." K.Marx ___ Tired of slow Internet? Get @Home Broadband Internet http://www.home.com/xinbox/signup.html
Re: Speed of Gimp
On Tue, Nov 28, 2000 at 05:33:42PM +0100, Robert Schiffers <[EMAIL PROTECTED]> wrote: > i'm wondering if jean-louis meant that he compiled his LINUX system for >multiprozessor support or GIMP. it shouldn't make any difference for the tests he made. all the operations he did are single-threaded inside gimp. (i guess you could get more speed out of async-i/o, but the last time that was tried to became very complicated and buggy. This will not be addressed before 1.2). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
RE: Speed of Gimp
Hello I recompiled the kernel 2.2.13 with the SMP option AND Gimp where there is an option for multi processor. When i run "xosview", i can see the 2 processor running at the same time only when opening Gimp. Otherwise, most of other tasks of gimp are monoprocessor. Anyway, as it didn't appear very well in my first message, Gimp is running much slower than XV which is an rpm package : 1st modification with curves on a file of 40 Mo : 18 sec with gimp < 1 sec with xv following modifications with curves : 35 sec with gimp < 1 sec with xv But i also tried with the mono processor kernel and that does not make much difference except for opening Gimp itself : maybe 5 sec vs. 7 or 8 sec. What i don't understand is that xv is running obviously exactly on the same configuration. > -- > De : Robert Schiffers[SMTP:[EMAIL PROTECTED]] > > hi > > i'm wondering if jean-louis meant that he compiled his LINUX system for > multiprozessor support or GIMP. > if he meant his system i think he couldd have 10 processors in his machine > and it wouldn't change > anything on gimp. only if he would start working on two images at the same > time the system will use the > power off the two processors. gimp has no tools to use the strenght of > both. > > am i wrong? please tell me, cause i also use a multiprocessor machine > (perfect with radiance for > rendering, but this soft implements some routines to use multiprocessor > power). > > Marc Lehmann wrote: > > > On Tue, Nov 28, 2000 at 12:33:38PM -, "Louer, Jean Louis" > <[EMAIL PROTECTED]> wrote: > > > I am using a PC with 2 celeron processors, 192 Mo of ram, and a G200 > matrox > > > graphic card. I made some experiences to see how fast goes Gimp under > Linux > > > > Strange: Dual P-II 333 with Millenium II, and a 45Mo image: > > > > >Photoshop (win)Gimp(linux) > > > gaussian blur (20 pixels) :20 sec 2 min 32 sec > > > 3 min 57sec > > > > 32s calculation + 15s I/O (there shouldn't be I/O imho) > > > > > undo :< 1sec 17 sec > < 1 > > > sec > > > > This is really strange. this took 22s here, with LOTS of I/O. Did you > have > > lots of I/O yourself? That would explain the difference. > 22 sec when you undo, Marc ? So, data are corresponding because you use a 45 Mo picture and 2 333mz processors instead of 2 400mz for me. Yes, there are a lot of i/o on disk during undo. > > > > I have a tile cache size of 128MB. 8000x2000 image at 4 bytes/pixel is > 64MB. > > I did load the image it into a fresh gimp and just did a gaussian blur > and an > > undo: > > > > # ps avx|grep gimp > > 2952 pts/3S 0:26 108640 1702 167093 166460 64.7 gimp > > # ls -l /localvol/root/.gimp/gimpswap.2952 > > -rw--- 1 root root 191926272 Nov 28 14:26 > /localvol/root/.gimp/gimpswap.2952 > I will check this at home. > > > > What on earth requires MORE than 320MB to store a 64MB image + 1 undo > > step? That makes 5 copies of the image (1 image, 1 undo, 3 projection > > buffers or what is wrong here?) > > > > > Mo and 2 processors. So my question is : > > > What can i do to have better results with Gimp ? > > > > more memory probably ;) can you verify that (most) of the speed penalty > comes > > from added i/o due to bad memory usage? How do you do that ? > > > > -- > > -==- | > > ==-- _ | > > ---==---(_)__ __ __ Marc Lehmann +-- > > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > > The choice of a GNU generation | > > | > Jean-Louis Louere
Re: Speed of Gimp
hi i'm wondering if jean-louis meant that he compiled his LINUX system for multiprozessor support or GIMP. if he meant his system i think he couldd have 10 processors in his machine and it wouldn't change anything on gimp. only if he would start working on two images at the same time the system will use the power off the two processors. gimp has no tools to use the strenght of both. am i wrong? please tell me, cause i also use a multiprocessor machine (perfect with radiance for rendering, but this soft implements some routines to use multiprocessor power). Marc Lehmann wrote: > On Tue, Nov 28, 2000 at 12:33:38PM -, "Louer, Jean Louis" ><[EMAIL PROTECTED]> wrote: > > I am using a PC with 2 celeron processors, 192 Mo of ram, and a G200 matrox > > graphic card. I made some experiences to see how fast goes Gimp under Linux > > Strange: Dual P-II 333 with Millenium II, and a 45Mo image: > > >Photoshop (win)Gimp(linux) > > gaussian blur (20 pixels) :20 sec 2 min 32 sec > > 3 min 57sec > > 32s calculation + 15s I/O (there shouldn't be I/O imho) > > > undo :< 1sec 17 sec < 1 > > sec > > This is really strange. this took 22s here, with LOTS of I/O. Did you have > lots of I/O yourself? That would explain the difference. > > I have a tile cache size of 128MB. 8000x2000 image at 4 bytes/pixel is 64MB. > I did load the image it into a fresh gimp and just did a gaussian blur and an > undo: > > # ps avx|grep gimp > 2952 pts/3S 0:26 108640 1702 167093 166460 64.7 gimp > # ls -l /localvol/root/.gimp/gimpswap.2952 > -rw--- 1 root root 191926272 Nov 28 14:26 >/localvol/root/.gimp/gimpswap.2952 > > What on earth requires MORE than 320MB to store a 64MB image + 1 undo > step? That makes 5 copies of the image (1 image, 1 undo, 3 projection > buffers or what is wrong here?) > > > Mo and 2 processors. So my question is : > > What can i do to have better results with Gimp ? > > more memory probably ;) can you verify that (most) of the speed penalty comes > from added i/o due to bad memory usage? > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > |
Re: Speed of Gimp
On Tue, Nov 28, 2000 at 12:33:38PM -, "Louer, Jean Louis" <[EMAIL PROTECTED]> wrote: > I am using a PC with 2 celeron processors, 192 Mo of ram, and a G200 matrox > graphic card. I made some experiences to see how fast goes Gimp under Linux Strange: Dual P-II 333 with Millenium II, and a 45Mo image: >Photoshop (win)Gimp(linux) > gaussian blur (20 pixels) :20 sec 2 min 32 sec > 3 min 57sec 32s calculation + 15s I/O (there shouldn't be I/O imho) > undo :< 1sec 17 sec < 1 > sec This is really strange. this took 22s here, with LOTS of I/O. Did you have lots of I/O yourself? That would explain the difference. I have a tile cache size of 128MB. 8000x2000 image at 4 bytes/pixel is 64MB. I did load the image it into a fresh gimp and just did a gaussian blur and an undo: # ps avx|grep gimp 2952 pts/3S 0:26 108640 1702 167093 166460 64.7 gimp # ls -l /localvol/root/.gimp/gimpswap.2952 -rw--- 1 root root 191926272 Nov 28 14:26 /localvol/root/.gimp/gimpswap.2952 What on earth requires MORE than 320MB to store a 64MB image + 1 undo step? That makes 5 copies of the image (1 image, 1 undo, 3 projection buffers or what is wrong here?) > Mo and 2 processors. So my question is : > What can i do to have better results with Gimp ? more memory probably ;) can you verify that (most) of the speed penalty comes from added i/o due to bad memory usage? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
