Compiler optimization for Geode

[Bernardo Innocenti]

Brian Carnes wrote:

> 1. gcc (unreleased 4.3) has Geode optimizations we'd like to use, but it
> is not out yet, nor is the rest of it stable.

gcc 4.1 in F7 has a backport of these patches.  No need to switch to 4.3
if the only advange is -march=geode.


> 2. People have experimented with backporting just the Geode gcc changes we
> want to gcc 4.1 or 4.2 with success

That would be me :-)


> 3. To leverage existing build systems and package maintenance, we will not
> rebuild all packages to be geode specific, at least at first.

Seems reasonable.  If we diverge too much from upstream, then we need
to rebuild (and debug) all updates ourselves.  And at this time we
clearly lack engineering resources to do it.


> 4. There are big gains to be had: parts of the basic C library showed 20%
> improvement with Geode specific optimizations (unclear if this was
> hand-coded asm in key routines, or compiler geode optimizations overall,
> or both, nor which benchmark was used).

It was hand coded asm for memXXX() and strXXX() function.  The 20% figure
comes from a benchmark that calls them in various ways.


> 5.  Benchmarking of performance gains in real applications has not been done.

Yes, that would be interesting.  It would be great to have it in
our existing tinderbox.


> So it looks like our tasks are:
> 
> 1. Standardize on a compiler release and set of backported Geode patches.
>
> 2. Benchmark performance gains from geode optimizations, and hand-tuned
> assembly in key library routines.
> 
> 3. Measure how these improvements affect real-world responsiveness (pick
> some easy-to-time metrics in common XO apps)
>
> 6. Work to get the Fedora project Koji to build geode specific modules in
> the long run.

I'd suggest delaying such actions until after both these conditions are
satisfied:

 - we get past stable releases for mass production

 - our new build master Dennis Gilmore takes the helm and gets
   comfortable enough with the platform


> 4. Decide for which shared libraries we should maintain our own
> geode-specific builds (glibc certainly, others...)

For glibc, we already do for localization issues, and we already
have detailed benchmark results.  Let's go for it!


> 5. Create a portable and robust build system for the above in the short term.

Creating a new build system from scratch takes a considerable
amount of work, and making it robust takes even more time.

Our strategy seems to be adopting the existing build system of Fedora 7,
which is quite consolidated these days, with mijor tweaks to the
"compose tools" part so we can create our JFFS2 images.


> Since it seems Rob Savoye has already done great work in this area, I'll
> look to him to lend his insight into immediate next steps.

Rob is certainly a good candidate for a toolchain and glibc hacker!


> How should we coordinate moving forward?  Get a separate mailing list for
> this effort, update a wiki page, update the trac ticket, have an IRC
> meeting?

I'd prefer staying on devel at ... The traffic is not much and we'd benefit
from the input of the other OLPC developers.


> I've put up a wiki page for people to dump more ideas and update everyone
> on their status:
> 
>   http://wiki.laptop.org/go/Geode_Optimization_Effort

Great work, thanks!

If you agree with my above observations, please update the page accordingly.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/