Geode optimization effort

This page is a placeholder for discussing getting libraries (and possibly apps) built with Geode-specific optimizations.

Summary Email (Brian Carnes)

Greetings all,

It was great to get such helpful and varied responses to this inquiry.

The original request from the developers page I was responding to was asking for Geode optimizations in gcc. After digging deeper, and reading the replies on this list, and getting involved w/ the Trac enhancment request behind this, I think I can summarize the current state as follows:

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.

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

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

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).

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

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)

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

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

6. Work to get the Fedora project Koji to build geode specific modules in the long run.

I'm intentionally overlooking some of the suggestions from the list to go rewrite existing applications to run better on the Geode, mostly because the above gives us more bang for our development-time-buck.

I think our profiling and benchmarking efforts above will shed lots of light on whether application-level tuning in future is warranted. I imagine we can get quite far by just expanding what are built as geode-specific libraries, targeting the number-crunching libraries like FFTW, BLAS, etc.

The geode-specific 3DNow "pfrsqrtv" (for square root) would be nice to get used in all applications, but that would involve setting up our own build system (Koji or otherwise), or getting the Fedora project to target the geode as an i386 variant.

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.

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?

Let me know.

 - Brian

Resources:

• related trac entry: https://dev.laptop.org/ticket/118
• patched GCC 4.2 w/ geode experiment writeup: http://wiki.gnashdev.org/wiki/index.php/Building_OLPC_Tools
• original compiler request: http://wiki.laptop.org/go/Developers_program
• Geode instruction set page
• Geode page

People involved going forward:

Rob Savoye (?owner of the gnashdev.org effort, using latest gcc from svn?)
Bernardo Innocenti (gcc geode backports to 4.2.1)
Brian Carnes (me, wanting to help)
Alexandre Oliva (would like to help)
András Rafás (NoiseEHC, would like to finish the Geode asm docu)
others?