Am 03 Sep 2001 17:45:13 -0700 schrieb Brian Weber:

>     So if I understand you correctly, since the gimps main purpose is
> perform bitwise manipulation that 64 bit won't give much of a benefit.

No, it's doing bytewise operation on 8, 16, 24 or 32bit data and it has
to because many processors won't operate on several 8bit channels at
once because they lack cpu commands to do so. It would be a nice speedup
to work on 4x8bit at once for processors that support it and for 64bit
we could even do 2 RGBA pixels at once if the processors supports it.

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

Actually we considered using a chunked memory region instead of tiles
however this also has several drawbacks but would probably speed up
imaging a lot if enough memory is available (which is probably not an
issue anymore with todays memory prices). In theory a tilebased system
has huge advantages when working with pictures that are bigger than
the available memory because only tiles which are being worked on
would have to be in physical memory. 

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

It is (at least) twice as fast if you have data that needs 64bit
precision because emulated 64bit operation is really heavyweight. With
imaging software one normally operates with byte or doublebyte data
data which is why aren't to big speedups possible at the moment. 

> 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 :)

If you do that take a PPClike design and add lots units and a better
dispatcher. :)


Gimp-developer mailing list

Reply via email to