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 > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
