#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            |  
--------------------------+-------------------------------------------------
Changes (by bernie):

 * cc: rsavoye (added)


Comment:

 Replying to [comment:12 bmcarnes]:
 > Are the glibc problems with geode optimizations still present?

 Rob Savoye gave us a new version of the patches with a problem fixed:

   http://wiki.gnashdev.org/wiki/index.php/Building_OLPC_Tools

 So far I couldn't find the time to re-apply the patches to the glibc rpm
 we use in joyride.


 > I'm volunteering to build some or all of the XO software with
 -march=geode and debug any issues that arise.

 Cool!  But this has to be done in rpm, and possibly using Koji.

 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.

 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.


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

 I'm afraid we can't use gcc 4.3 as our default compiler until we update to
 a new version of Fedora that includes it by default.  The reason is that
 too many packages may need fixing to compile cleanly and we lack
 engineering resources to fix them all.

 But we could certainly add a gcc43 package containing /usr/bin/gcc43 and
 build specific packages against it.


 > Let me know how I can help.

 An interesting project would be providing a few benchmarks showing how
 much these optimizations could benefit us in interesting test cases.

 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.

-- 
Ticket URL: <https://dev.laptop.org/ticket/118#comment:13>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system