Where olpc machine spending time when using web broswer

[Dan Williams]

On Tue, 2007-03-13 at 12:04 -0500, Vladimir Makarov wrote:
> William Cohen wrote:
> 
> > William Cohen wrote:
> >
> >> Looked at where the processor spends its time when browsing the web.
> >>
> >> Hardware configuration:
> >>
> >>  OLPC Beta 2 machine
> >>  Linksys USB200M USB 10/100 for ethernet connection
> >>  4GB memorex Mini Travel Drive for storage of image
> >>
> >>
> >> Software configuration:
> >>
> >>  /tmp/olpc-redhat-stream-development-build-299-20070308_1417-devel_ext3.img
> >>  kernel-2.6.21-20070309.olpc1p.dc5079fafb767e4
> >>  oprofile-0.9.2-3.fc6
> >
> >
> >
> > Re ran the experiment on build 301 and installed the 
> > xorg-x11-server-debuginfo-1.1.99.3-0.10.2.olpc1.i386.rpm on the olpc 
> > machine, so I could take a look at where time is being spent in libfb.so.
> 
> I don't know what version of gcc and options were used to compile the 
> packages.  If somebody points me where to look at this, I could be more 
> sure.  It looks to me that the packages were compiled without usage of 
> tunnning gcc to geode.  The div and mod insn are expensive in geode. 
>  Usage of div or shifts are choosen in gcc expmed.c and this is directed 
> by costs defined by -mtune or -march.
> 
> 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.

We'll need to check up on this further.  Vladimir, can you verify that
the version of gcc in FC6-updates right now does Geode optimizations for
us?

Thanks!
Dan

> I somebody need a help to speed up some (critical) code for OLPC by 
> choosing right options (like usage of mmx insn and vectorization and 
> other numerous possibilities), I could help too.  Please let me know. 
>  If I have an OLPC machine, I can do it.
> 
> >
> > # opreport -t 1 -l /usr/bin/Xorg
> > CPU: CPU with timer interrupt, speed 0 MHz (estimated)
> > Profiling through timer interrupt
> > samples  %        image name               symbol name
> > 6514     68.1096  libfb.so                 fbFetchTransformed
> > 613       6.4095  libfb.so                 fbFetchPixel_x8r8g8b8
> > 446       4.6633  libfb.so                 
> > fbCompositeSolidMask_nx8x0565mmx
> > 252       2.6349  libfb.so                 fbStore_r5g6b5
> > 169       1.7670  libfb.so                 fbRasterizeEdges
> > 137       1.4325  libfb.so                 fbCompositeSrc_8888x0565mmx
> > 113       1.1815  libfb.so                 fbCopyAreammx
> > 99        1.0351  libfb.so                 mmxCombineOverU
> >
> > The attached file is a portion of the output from opannotate. There is 
> > a group of MOD operations that are taking a significant portion of the 
> > time. The first column is the number of samples and the second column 
> > is the percentage.
> >
> >    398  6.1099 :                        x1 = MOD (x1, 
> > pict->pDrawable->width);
> >    383  5.8796 :                        x2 = MOD (x2, 
> > pict->pDrawable->width);
> >    336  5.1581 :                        y1 = MOD (y1, 
> > pict->pDrawable->height);
> >    355  5.4498 :                        y2 = MOD (y2, 
> > pict->pDrawable->height);
> >
> > Following this there are also some other expensive operations to 
> > compute r. and put it into buffer[i].
> >
> > -Will
> >
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel