#118 LOW Future : GCC optimizations

[Zarro Boogs per Child]

#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