login
Search
Mark Mitchell announced the availability of GCC 4.1.0 saying, "this release is a major release, containing substantial new functionality relative to previous releases." Among the changes, new features and fixes listed for this new release series are a number of general optimizer improvements, language specific improvements, and some protection from stack-smashing attacks by providing buffer overflow detection and reordering of stack variables.
GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.1.0 from a gcc.gnu.org mirror.
From: Mark Mitchell [email blocked] To: gcc, [email blocked] Subject: GCC 4.1.0 Released Date: Wed, 1 Mar 2006 08:24:18 -0800 GCC 4.1.0 has been released. This release is a major release, containing substantial new functionality relative to previous releases. See: http://gcc.gnu.org/gcc-4.1/changes.html for a list of new features, improvements, and other changes. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in the gcc/gcc-4.1.0 subdirectory. There are two important caveats beyond those listed on the web page above: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. 2. It was discovered after the final release had been made that there is an installation problem when building with Java enabled and when "--enable-version-specific-runtime-libs" is in use . In particular, header files for some of the Java APIs will be placed in "/include" (with no prefix), due to a defect in the Java Makefiles. There are three known work-arounds: a) Disable Java by using "--enable-languages" when configuring GCC. For example, to build just the C and C++ compilers, use "--enable-languages=c,c++". b) Do not use "--enable-version-specific-runtime-libs". c) Use "--with-gxx-include-dir=" to explicitly indicate where you would like the Java header files to be placed. For example, if you use "--prefix=/path/to/prefix" then using: --with-gxx-include-dir=/path/to/prefix/lib/gcc/<target>/4.1.0 will place the header files in the appropriate version-specific location. I expect this problem will be corrected in GCC 4.1.1. If you encounter any difficulties using GCC 4.1.0, please do not send them directly to me. Instead, please http://gcc.gnu.org/ for information about getting help and filing problem reports. We expect to release GCC 4.0.3 (an bug-fix release relative to GCC 4.0.2) in the near future. GCC 4.1.1 (a bug-fix release for GCC 4.1.0) will be released in approximately two months. As usual, a vast number of people contributed to this release -- far too many to thank by name! -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713
Niiiice.
I just ran 4.1.0 vs. 4.0.1 on my Intellivision emulator, jzIntv, benchmarking the video code specifically. This is on an Opteron 246 generating code for x86_64. My average render time went down from 81.5 µsec to 72.7 µsec. (Yes, you read that right, microseconds. It's hella fast code.)
That's what, a 12% speedup?
Edit: I just benchmarked 3.3.5 and 3.4.4 also (since they were installed on my system already). Looks like GCC's been all over the map, but 4.1.0 is the fastest of the 4 versions tested:
3.3.5: 85.2 µsec (17% slower)
3.4.4: 75.7 µsec (4% slower)
4.0.1: 81.5 µsec (12% slower)
4.1.0: 72.7 µsec (baseline)
Whoo hoo!
What is the compile time and
What is the compile time and memory usage of gcc 4.1? Any reductions?
Here's timing.
I didn't measure memory usage. (Incidentally, what's a good way to do that?) Here's the times to build jzIntv, though, with the four compilers:
3.3.5: 7.51 sec
3.4.4: 8.29 sec
4.0.1: 9.20 sec
4.1.0: 11.12 sec
So yes, a definite slowdown in compile time. I do have the optimizations cranked all the way up, so it's not too surprising. I imagine once the RTL optimizations get fully supplanted by Tree SSA equivalents, that number will come back down some.
RE: Here's timing.
Actually most of the slowness is now in the Tree SSA equivalents themselves. The number of passes that GCC runs (i.e. full runs over the code) has more than doubled in GCC 4.1 when you compare it to GCC 3.4.
But people are working on speeding things up there, too (or I should say, not slow down further...).
Also, to put things in perspective: by your numbers GCC 4.1 is something in the order of 50% slower than GCC 3.3, and assuming that number is typical for the slowdown users experience, that means their net compile time is still down by a factor of two because GCC 3.3 is almost 36 months old :-)
We'll see what happens...
The TreeSSA optimizers might be slower than their RTL counterparts in some cases, but I'd hope not dramatically so. Mainly, my understanding is that there is duplicate work on both sides of the optimization fence while the TreeSSA stuff matures. Once those mature, the "old ways" can get disabled and deleted.
At least that's my understanding.
Personally, I don't mind the compile time increase. Folks out there compiling for the sake of compiling... I don't weep for you. Developers out there rebuilding the kernel or other large software packages regularly, I do feel for you.