Compiler optimization for Geode

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

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

  - 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


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)
 others?