Compiler optimization for Geode, migrating to F8, build system

[Bernardo Innocenti]

Brian Carnes wrote:

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

Let me know.  I used to be a gcc developer too, so I'm very interested
in these things.


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

For now, it's just glibc and a bunch of other higher level libraries we
need for Sugar.  And for some things, such as the X server and xkb data,
we're even ahead of F8.

After Christmas, I'd consider rebasing on F8 a useful and worthwhile
objective.  It's not as hard as it may sound.  I even think I could do
it on my own in a temporary fork to avoid disrupting the others.

Such a project would have to be agreed upon by the developers beforehand,
of course.


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

Due to lack of time, I've not done much.  We're also in semi-freeze
now so any disruptive work we do would have to be kept separate from
the stable and wannabe-stable builds.

I'd be happy to help you out if you decide to rebuild everything
with a new version of gcc.

The hard part is not gcc iteslf: it's convincing RPM to rebuild
all these packages with your new compiler, and fixing the small
glitches that are likely to appear here and there.

Dennis Gilmore may be able to provide assistance if you need to
use Koji for this.  But you'd probably save time by just using
mock to start with.


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


We have a bit of naming confusion here.  What we called "build system"
so far, used to be called "compose tools" in Fedora jargon.

Our build system builds the distribution images starting from
binary RPMs.  It does not actually "build" the packages.

For now, we're still using koji.fedoraproject.org as our build
system.  Dennis is probably going to create a local koji server
once he starts working with us, but I think this is still undecided.



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

Yes, I think the latest version is this one:
  http://www.gnashdev.org/olpc/glibc-2.6-5.olpc.src.rpm 

(also see Rob's comment on #118).

Please, use a checkout of Fedora's cvs to rebase it, so I can easily
review and commit the diff:

  cvs -d :pserver:anonymous at cvs.fedora.redhat.com:/cvs/pkgs checkout glibc


> 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 think someone already did it.  Certainly Carl Worth did.  There's
a benchmark mode in Mozilla, ask around.


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

Yes.  The problem is that building a package or two in a separate
environment is feasible, but rebuilding a whole distribution from
scratch is *hard*.  It requires you to install and configure local
copies of pilgrim, mock, createrepo, yum...

Using "koji build --scratch" might also be an option.  Do you
already have a Fedora account?  If not, I suggest you apply.

Instead of making custom distribution, you could rebuild a bunch
of performance critical packages such as, say, libz and openssl
and create a yum repo for them.


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

Since it doesn't really build anything, I'd say no :-)


> 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 just did the very first bit of it: addding geode to Makefile.common
in Fedora CVS.

This RPM bit still has to go upstream:

--- /usr/lib/rpm/redhat/rpmrc.orig	2007-11-05 21:03:34.000000000 +0100
+++ /usr/lib/rpm/redhat/rpmrc	2007-11-05 21:03:05.000000000 +0100
@@ -5,6 +5,7 @@ optflags: i486 %{__global_cflags} -m32 -
 optflags: i586 %{__global_cflags} -m32 -march=i586 -fasynchronous-unwind-tables
 optflags: i686 %{__global_cflags} -m32 -march=i686 -mtune=generic -fasynchronous-unwind-tables
 optflags: athlon %{__global_cflags} -m32 -march=athlon -fasynchronous-unwind-tables
+optflags: geode %{__global_cflags} -m32 -march=geode -fasynchronous-unwind-tables
 optflags: ia64 %{__global_cflags}
 optflags: x86_64 %{__global_cflags} -m64 -mtune=generic

And there may be more instances in tools such as yum, createrepo,
pilgrim, koji, etc.

An easy way to find places where "geode" needs to be added is grepping
for "athlon" or "i686".

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