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
