GCC optimizations

[jg]

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.

[blizzard]

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

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

[jg]

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.

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

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

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

[cscott]

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

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

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

[bernie]

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.

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

[bmcarnes]

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?

[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

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

[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

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

[bernie]

Initial porting to glibc 2.7:

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

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

[mstone]

Any progress here?

[andresambrois]

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?

[cscott]

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?

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

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

[dgilmore]

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