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 -0000, "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/3    S      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

Reply via email to