Re: back online again

[Richard Frith-Macdonald]

On 14 Jan 2006, at 23:52, Helge Hess wrote:

> Richard Frith-Macdonald wrote:
> > I'd like to get GNUstep working properly in the 64bit environment ...
> > it seems to be considerably faster than the 32bit environment on the
> > same machine (I had expected it to be about 20% faster but it seemed
> > more like double the speed when I was compiling).
>
> Do you have an idea why this is? I would expect a 64bit env to be  
> quite
> a bit _slower_ than a 32bit one for regular applications (<2GB memory
> requirement, object oriented) due to the massively higher (ptr) memory
> overhead and load times?

I think I  foolishly spoke much too soon and had the wrong impression.

Going back and doing the same things again I found no significant  
speed difference between the two environments, and after thinking  
about it a bit I now suspect that disk i/o is the main issue ... and  
I probably got the spurios impression of a major speed difference  
because I compiled the base library first in the 32bit environment  
(wheren everything had to be read from disk) and later in the 64bit  
environment the system already had everything it needed in memory.

Obviously we need well designed benchmarks run repeatedly rather than  
quick initial impressions of performance.

While the benchmark program in the base library can not be described  
as well designed or comprehensive etc ... I thought it might be  
interesting to run it anyway.  It is at least a test of ObjC code  
perfomance without and disk I/O (other than loading the program  
itsself).

Unfortunately it was written for times when processors were much  
slower .. and takes only about 7 seconds to run ... but it would  
appear to show that the 64bit and 32bit code runs at pretty much the  
same speed.  Repeatedly running the benchmarks I found that the 64bit  
code was consistently a little faster ... typically 7.03 seconds when  
the 32bit version took 7.32 seconds, but I doubt that the difference  
is really very meaningful.