Re: [Gimp-developer] Solaris 64bit compile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



    So if I understand you correctly, since the gimps main purpose is to
perform bitwise manipulation that 64 bit won't give much of a benefit.  If
someone were to go in and change the memory management scheme of the gimp to
make use of the OS instead of gimps tiles than we would probably see a
benefit in the load time and save time.  I could also see that breaking
other OS's unless it was done to work across platforms.
    I don't know why but for some reason I got it in my head that 64 bit
would be twice as fast for any application that was processor intensive.
Thinking that you can have, I don't know how many more, many more
instructions and the system buss would be twice the width allowing twice the
amount of data to go between ram and the CPUs.  Maybe when I design my new
processor I will include that in :)



----- Original Message -----
From: Daniel Egger <egger@xxxxxxx>
To: Brian Weber <brian.weber@xxxxxxxx>
Cc: GIMP developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, September 03, 2001 8:21 AM
Subject: Re: [Gimp-developer] Solaris 64bit compile


> Am 25 Aug 2001 22:21:58 -0700 schrieb Brian Weber:
>
> > I did get a successful compile of 64 bit gimp.  I ran it and used so
> > of the limited functionality that I usually use with no problems at
> > all.
>
> I wouldn't expect them either. I ran GIMP before on 64bit USparc, PPC
> and Itanium without any quirks.
>
> > The other thing I didn't see is any performance increase.
>
> Bad luck. :)
>
> > My machine is an Ultra 2 with dual 168 mhz and 192 Meg of ram.  I
> > grabbed a relatively small bitmap and used the globe plugin for 10
> > iterations to make sure that I had enough time to get some statistics.
> > I wasn't using any swap space and one of the processors was pegged
> > about 3/4s of the time.  The other process got pinged a couple times
> > but that was probably more os and vmstat.
>
> Ok, two reasons for that: GIMP is not requesting a single big chunk of
> memory from the system but rather does it's own memory management using
> a tile based system. So if you do not excessivly utilize your system or
> lie about your memory size then GIMP will probably never hit SWAP at
> all.
> The second CPU will be only used for tile rendering if GIMP is compiled
> with the MP option, however it doesn't give much of a benefit, is rather
> untested and will definitely result in a deterioriation on a single CPU
> system because of the additional checks (which is also why it is not
> activated by default).
>
> > My question is, am I expecting too much from 64 bit?
>
> Yes you are.
>
> > Does the C code actually have to change to get the benefit from 64
> > bit?
>
> Yes. I don't exactly know how your machine is organized and how USPARC
> addresses memory but it maybe that differently aligned memory might
> show benefits here. Also I have some ideas how to optimize the GIMP
> to give bigger benefits on 64bit architectures but cannot benchmark
> it due to unavailability of those systems; the trick here would be to
> reorganize memory utilisation to use the full 64bit capabilites of your
> machine. Those architectures normally shine while handling big chunks
> of data and suffer when addressing small amounts of data (say bytewise)
> with a lot of instructions because they are clocked so slowly.
>
> > Is this the right list to be asking this question?
>
> Sure it is.
>
> Servus,
>        Daniel
>
>



[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux