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.
>
> 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
>
> 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                       |
>                                                          |

Reply via email to