Re: Speed of Gimp

2000-11-29 Thread Tobias Gärder

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



Speed of Gimp

2000-11-28 Thread Louer, Jean Louis

Hello

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
2.2.13 that i recompiled for SMP. So, i compared Gimp version 1.1.22
(recompiled smp) with XV and Photoshop 5.5 under windows. Here are the
results i got with the same picture of 40 Mo in tiff format with no
compression :

 Photoshop (win)Gimp(linux)
XV(linux)
opening the picture :4 sec  7 sec   4
sec

modifing the curves :4 sec  35 sec   1
sec

gaussian blur (20 pixels)   :20 sec 2 min 32 sec
3 min 57sec

undo: 1sec 17 sec   1
sec

save file under (tiff)  :5 sec  4 sec1
sec

The parameters of photoshop are defaults ones, and of course with one
processor because of windows. I changed the parameters of Gimp in
preferences environement. These results are obtained with a cache of 100
Mo and 2 processors. So my question is :
What can i do to have better results with Gimp ?
Thanks

Jean-Louis Louere



Re: Speed of Gimp

2000-11-28 Thread Marc Lehmann

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

2000-11-28 Thread Robert Schiffers

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

2000-11-28 Thread Louer, Jean Louis

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