Where olpc machine spending time when using web broswer

[Vladimir Makarov]

Dan Williams wrote:

>On Tue, 2007-03-13 at 13:22 -0400, Adam Jackson wrote:
>  
>
>>On Tue, 2007-03-13 at 13:15 -0400, Dan Williams wrote:
>>
>>    
>>
>>>>I already did gcc tunning to geode (pipeline description, code costs, 
>>>>i386 port parameter values) and submitted it to the gcc mainline.  As I 
>>>>know Jakub Julinek was going to backport this code to redhat gcc.  So I 
>>>>can guess that if the right compiler and options are used, it will make 
>>>>code faster (and several % smaller because -mtune=geode generates 
>>>>smaller code that any other tuning).
>>>>        
>>>>
>>>I seem to recall that we have a gcc available that does geode tuning.
>>>What's missing is to change the RPM_OPT_FLAGS in the olpc-1 buildroots
>>>and then fork & recompile packages from package-cvs that we want to
>>>optimize with geode.  That by definition means that we try to recompile
>>>only the smallest set of packages we can since it's a branch off of FC6.
>>>      
>>>
>>I'm reasonably sure the olpc buildroot has a sufficient gcc for this.
>>FC6's gcc has a patch entitled gcc41-i386-tune-geode.patch.
>>
>>I'm already doing some custom RPM_OPT_FLAGS action for X, I can add
>>-march=geode and -momit-leaf-frame-pointer if we think it'll help.
>>    
>>
I'd first try to use -mtune=geode because -march=geode means usage of 
mmx and this needs some investigation.

It is hard to say that -momit-frame-pointer improves the code.  I can 
guess there are few functions with high register pressure and without 
calls.  Another thing is usage stack pointer changes stack slot 
addressing in many cases makes displacement bigger (if it is out of 
+-128 range more bytes needed for displacement)  and as consequence code 
bigger (geode is sensitive to code locality. It means the code will be 
slower too).

So I'd do one step at a time (-mtune=geode and it is ok, than try 
-momit-frame-pointer).

By the way, the register allocator is critical part for x86_64 code. 
 I've been working more 2 years on a new register allocator for gcc, 
I've got a good improvement for x86 (in code size and code speed). 
 Unfortunately it will be ready only for gcc4.4 if everything is ok.

>Could you run a build of X with the geode options and we'll get Chris to
>do some benchmarks and see if stuff gets faster?
>
>  
>