#118 LOW Future : GCC optimizations
Zarro Boogs per Child
bugtracker at laptop.org
Thu Nov 1 17:32:00 EDT 2007
#118: GCC optimizations
--------------------------+-------------------------------------------------
Reporter: jg | Owner: bernie
Type: enhancement | Status: assigned
Priority: low | Milestone: Future Release
Component: distro | Version:
Resolution: | Keywords:
Verified: 0 |
--------------------------+-------------------------------------------------
Comment(by rsavoye):
Replying to [comment:13 bernie]:
> I do that by putting "%optflags -O2 -march=geode" in my ~/.rpmmacros,
but eventually it has to be done on the specific packages we want to
rebuild for geode.
I'm not 100% sure how you do your builds, but for most packages, setting
CC to "gcc -march=geode -mtune=geode" works fine.
> For now, rebuilding everything with -march=geode is not an option, or we
loose the ability to use prebuilt packages from upstream. With some
collaboration from the Fedora engineers, maybe we can add geode as a new
i386 variant besides i686 and athlon.
Using -march=geode would only effect the packages built with this
compiler. There shouldn't be any problem mixing these executables with
prebuilt upstream packages.
> > It sounds like gcc 4.1 geode optimizations are a good start; if we get
them working in this project, we can see where the gcc 4.3 release (w/
better geode tuning) is, and discuss how to leverage those changes for the
XO.
The geode optimizations for GCC are a minor tweak to the existing pentium
support. It would be entirely possible to migrate the GCC patch to GCC
4.1.x. I've found a multitude of bugs in Gcc 4.1.2, but I think applying
this patch to gcc 4.2l.1 makes sense, and it's a better compiler in
general than 4.1.x. So maybe adding a hacked 4.2.1 is better than GCC 4.3,
as 4.3 isn't released yet, it's basically just a SVN snapshot.
> An interesting project would be providing a few benchmarks showing how
much these optimizations could benefit us in interesting test cases.
When I get back from this conference, that's my plan. The geode-perf tests
this work is based on aren't setup this way, but my plan was compile some
standard benchmarks with the unmodified GCC/GLIBC, and then again with the
modified version to see if there are any real world improvements. Testing
the GLIBC tweaks in isolation has shown a 20% improvement in performance,
but the real test is how this effects regular applications.
> Then, working closely with our upstream would be best so we can benefit
indirectly. Again, we'd all be reluctant to diverge too much for small
gains, because we lack engineering resources to maintain hundreds of
packages.
If the GLIBC improvements do offer some improvement by itself, then any
application dynamically linked against GLIBC would use the better
performing version when installed on an X0.
--
Ticket URL: <http://dev.laptop.org/ticket/118#comment:14>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs
mailing list