Ticket #118 (new enhancement)

Opened 8 years ago

Last modified 6 years ago

GCC optimizations

Reported by: jg Owned by: dgilmore
Priority: normal Milestone: 9.1.0-cancelled
Component: distro Version:
Keywords: rel-8.2.0:? Cc: cscott, rsavoye, bmcarnes, mstone, jg, dgilmore, bernie, andresambrois
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

GCC has a mechanism for setting the flags used by default for a particular installation of a compiler (the gcc specs file). For those people doing self-hosted development, it would indeed be good to craft a Geode GX GCC specific configuration file for GCC to use. By default, it uses a build-in spec file. To see the built in defaults, type "gcc -dumpspecs". See section 3.15 of the gcc manual.

Knowing what flags are "best" obviously has value to us, though there are always judgement calls about setting default options.

And there may be specific packages where there is enough performance to be gained to bother to compile with specific flags for OLPC (e.g. codecs and similar CPU bound codes). Those we should handle separately from this trac bug.

Beyond this, what is probably more important in the long term is for people who are friendly with gcc to work on a march=geode implementation. The code scheduling for floating point in particular could be improved to give significant performance gain, as it differs enough from other x86 implementations to be significant.

Also, if you have an FP intensive application, the performance difference between single and double precision is larger than typical of other x86 systems. Bothering to ensure single is used where feasible in those particular applications may be helpful.

Change History

follow-up: ↓ 2   Changed 8 years ago by blizzard

  • status changed from new to assigned

Jim, do you have the code that has the perf optimizations for the Geode that was mentioned in Weekend?

in reply to: ↑ 1   Changed 8 years ago by jg

Replying to blizzard:

Jim, do you have the code that has the perf optimizations for the Geode that was mentioned in Weekend?

They are in git, of course.

See the geode-perf project in Git.

http://dev.laptop.org/git?p=geode-perf;a=summary

but this is orthogonal to improvements in gcc; this is about improvements in glibc and other places....

  Changed 7 years ago by jg

  • milestone set to CTest

We should remember to ensure the GCC folks, both in RH and elsewhere, know we are moving to LX. It does have some significant differences.

  Changed 7 years ago by jg

  • owner changed from blizzard to bernie
  • status changed from assigned to new
  • verified unset

  Changed 7 years ago by bernie

I've talked it over with Rob Savoye. He made the olpc toolchain based on gcc 4.3 and integrated AMD's string operations in glibc. I will leverage his work and push it upstream.

Meanwhile, I'm asking the GCC maintainers when they plan to release 4.3 because it already contains several performance improvements that we'd probably like to have.

The current svn trunk is in a good shape, but they may soon start merging a long queue of pending projects that will likely disrupt stability. I'm begging them to postpone this work to 4.4 and branch 4.3 now.

  Changed 7 years ago by bernie

  • status changed from new to assigned

  Changed 7 years ago by bernie

We have the geode optimizations in the gcc-4.1 shipped with F7, but we're not turning on -march=geode on any builds we make.

I'd like to ask some Fedora developer if we can add geode to the list of archs supported in Makefile.common.

This would make it easy for us to build all our custom rpms for the geode. python, glibc, cairo and xorg are pretty performance critical.

  Changed 7 years ago by bernie

I got a Fedora developer to add "geode" in Makefile.common. I've not yet figured out how to ask koji to build an RPM for geode, though.

My local builds of glibc for the geode make applications crash istantaneously. glibc problems are hard to debug and I had no time to investigate further.

It could be an issue with my build enviroment (environment variables creeping in, etc). This is why I wanted to build in Koji.

  Changed 7 years ago by jg

  • milestone changed from Trial-3 to V1.1

  Changed 7 years ago by cscott

  • cc cscott added

If/when we set up our own build environment, we could consider building all our packages with geode optimizations turned on.

  Changed 7 years ago by bernie

I would recommend that too.

I have a full koji server setup running on my desktop, with some outstanding problems. Koji is quite complicated and takes a lot of time to install, so we may want to start from there and maybe move it to a proper server later.

follow-up: ↓ 13   Changed 6 years ago by bmcarnes

Are the glibc problems with geode optimizations still present?

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

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.

Let me know how I can help.

in reply to: ↑ 12 ; follow-up: ↓ 14   Changed 6 years ago by bernie

  • cc rsavoye added

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

in reply to: ↑ 13   Changed 6 years ago by rsavoye

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

follow-up: ↓ 16   Changed 6 years ago by bmcarnes

  • cc bmcarnes added

I agree w/ Rob that we can and should rebuild certain key packages (glibc, perhaps even python and other main interpreters) with geode optimization.

They should mix and match fine, and shouldering the burden of building a few packages might be worth it; the rest can certainly come prebuilt from upstream until there is a Geode-targeting Koji build server.

When does Rob return from conference? What should I do in parallel that'll help but not duplicate his effort?

Shall I try building us a gcc 4.2.2 compiler with the geode patches from 4.3?

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

in reply to: ↑ 15 ; follow-up: ↓ 17   Changed 6 years ago by AlbertCahalan

Replying to bmcarnes:

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

Note that the Geode also includes partial support for SSE1 and SSE2. Being partial, you can't just enable gcc's code generation for those features.

http://wiki.laptop.org/go/Geode_instruction_set

in reply to: ↑ 16   Changed 6 years ago by rsavoye

Replying to AlbertCahalan:

From what I can see of the geode-gcc-4.2.patch on gnashdev.org, it does not do anything for the two new geode-specific 3dnow instructions, which include the very useful inverse sqrt. Shall I take a look to see if it's in gcc 4.3 at all, and try my hand at pulling it into the patch, or adding a peephole optimization for it if it isn't supported in gcc yet?

The patch was originally developed for the Geode GX, so yes, it would be a good idea to add this instruction as I believe it'll help performance on the LX.

follow-up: ↓ 19   Changed 6 years ago by bernie

Does anybody have time to rebase glibc patches on glibc-2.7 from F8? This is the version we need to ship for localization.

The latest RPM by Rob is here:

http://www.gnashdev.org/olpc/glibc-2.6-5.olpc.src.rpm

in reply to: ↑ 18   Changed 6 years ago by rsavoye

Replying to bernie:

Does anybody have time to rebase glibc patches on glibc-2.7 from F8? This is the version we need to ship for localization.

This would actually be very easy. Other than a hack to Makeconfig for using GCC 4.3 (-march instead of -mcpu), all the changes are in a single subdirectory, that merely has to be copied to the correct location. (sysdeps/i386/i686/geode) Glib's configure code is weird, but auto-senses the correct cpu variant when you configure with the --with-cpu=geode option.

  Changed 6 years ago by bernie

Initial porting to glibc 2.7:

http://www.codewiz.org/pub/glibc-geode-2.7/

  Changed 6 years ago by bernie

Seems to work well.

Dgilmore tought yum about the geode. We're now waiting for a geode enabled RPM to move this package in.

  Changed 6 years ago by mstone

  • status changed from assigned to new
  • cc mstone, jg, dgilmore, bernie added
  • priority changed from low to normal
  • owner changed from bernie to dgilmore
  • milestone changed from Future Release to Update.2 (8.2.0)
  • keywords rel-8.2.0:? added

Any progress here?

  Changed 6 years ago by andresambrois

  • cc andresambrois added
  • next_action set to never set

I second the ping above. This looks like an interesting optimization now that gcc-4.3 is being used.

Are the geode-specific optimizations being used in the builds?

  Changed 6 years ago by cscott

  • milestone changed from 8.2.0 (was Update.2) to 9.1.0

Dennis, is this one of the compelling benefits we could obtain by moving to your mash-based system, rebuilding every package in fedora against the olpc3 root? Is there a build root configuration we could do to apply these optimizations by default in 9.1/olpc4/F10?

  Changed 6 years ago by dgilmore

things like glibc and openssl probably definitely should be optimised for geode. we could make the normal fedora build do those optimisations. and using mash we can make sure that we provide the .gedoe rpms. one area that will need to be fixed for this to work correctly is the tools that create the images. they need to learn that we build for geode and they install geode rpms. right now they install i686 glibc and openssl.

  Changed 6 years ago by cscott

Can we start by creating some geode rpms in koji? Then I can futz with pilgrim's configuration and make sure it will pull them.

  Changed 6 years ago by dgilmore

yep :) glibc and openssl seem like obvious ones to start with. what other ones do we think we might need?

Note: See TracTickets for help on using tickets.