Compiler optimization for Geode

[Brian Carnes]

Bernie,

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

Excellent.  I'll set myself up a F7 environment, and look into the
compiler behavior and take a look at the compiler source rpms to see if it
supports the limited SSE extensions and the two new Geode-only
instructions.

F8 is almost released - I can take a look at any compiler/geode changes
that we'll get for free in that too.  (I saw email about OLPC migrating to
that over time, at least for i18n, right?)

My strengths are in compilers and optimization, which is why I'm trying to
help out in this way.  If you and Rob have everything under control, or
have a road-map in mind for the future, do please let me know.

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

I know - I hope you saw that I acknowledged you as having done this when
listing the people involved.  Above I was I referring to you and Rob both
having made contributions to this effort, with the dividing line fuzzy
from what I could find after the fact.

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

How does this change with the recent email that went out about OLPC having
its own build system now?  Is that just to rebuild the OLPC-specific bits,
and everything else still comes from Fedora?


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

Great.  Shall I take the src.rpms on the gnashdev.org wiki as
incorporating the latest version of your hand coded asm?  Or are your
patches available somewhere else?

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

Someone else suggested web page rendering as a metric.  I'll see about
instrumenting the browser to give us accurate timings for page draws under
a debug flag.  We can then test out different apps and libraries on local
html (including a decent amount of graphics) to see if the improvement is
noticeable.

> I'd suggest delaying such actions until after both these conditions are
> satisfied:
>
>  - we get past stable releases for mass production

I think most of this can be done in parallel, in private builds and tests,
so it'll be ready to integrate with the main project after your big
release.


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

Very much agreed.  This was in response to info from Rob about issues with
getting his own glibc builds to work with the modified compiler, and
issues with getting a private instance of Koji working well.

Is the OLPC build system in a state where we can request it to build a
custom glibc (with your inline asm patches) with a custom gcc?  Or do we
need some sort of private build system for this effort in the meantime?


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

I saw some email traffic about getting geode added as a supported
architecture in Fedora, and not knowing how to request Koji to build a
geode-variant of some or all packages.  Has this gotten better?

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

Sounds good.  We'll leave it here for now.


Thanks for all your info.

  - Brian