Am 03 Sep 2001 17:45:13 -0700 schrieb Brian Weber: > 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. 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. :) Servus, Daniel