[ut2004] Linux 3236 with fixed load times...
J. Ryan Earl
heretic at clanhk.org
Tue Jun 22 20:16:53 EDT 2004
Ryan C. Gordon wrote:
> As for gcc 3.4: Maybe in a few years. :) Let's see how this gcc
> does first.
And that's why Linux games are typically performing much worse than the
Windows versions: inferior binary generation. People doing Windows
development with Visual Studio .NET and/or using the Intel compiler are
getting much better binaries that are typically 20-30% faster than the
This is killing me. I hate running Windows servers, but for many games
they perform so much better because of this exact reason and I have no
choice in the matter. Furthermore, it's easy to keep gcc-3.4 and
gcc-3.3 both live on your system. You can easily switch back and forth
between profiles for packages that won't compile with gcc-3.4. 3.4 is
stable on Gentoo for x86_64; mark my words, gcc-3.3 will not be around
as long as gcc-3.2.
Switching to 3.4 was painless, and I haven't had any packages not
compile yet with: CFLAGS = -march=k8 -O3 -pipe Not only is everything
at least as stable--some 900 bugs fixed that won't be in gcc33--it
generates noticeably more efficient binaries. How can you resist this
part of the ChangeLog?
* Tuning for K8 (AMD Opteron/Athlon64) core is available via
|-march=k8| and |-mcpu=k8|.
* Scalar SSE code generation carefully avoids reformatting
penalties, hidden dependencies and minimizes the number of uops
generated on both Intel and AMD CPUs.
* Vector MMX and SSE operands are now passed in registers to improve
performance and match the argument passing convention used by the
Intel C++ Compiler. As a result it is not possible to call
functions accepting vector arguments compiled by older GCC version.
* Conditional jump elimination is now more aggressive on modern CPUs.
* The Athlon ports has been converted to use the DFA processor
* Optimization of indirect tail calls is now possible in a similar
fashion as direct sibcall optimization.
* Further small performance improvements.
* |-m128bit-long-double| is now less buggy.
* |__float128| support in 64-bit compilation.
* Support for data structures exceeding 2GB in 64-bit mode.
* |-mcpu| has been renamed to |-mtune|.
Look vector performance love in that, how can that not swoon you when
you're working on 3D applications? Still not convinced??? How about a
faster C++ library?
Runtime Library (libstdc++)
* Optimization work:
o Streamlined |streambuf|, |filebuf|, separate synched with C
Standard I/O |streambuf|.
o All formatted I/O now uses cached locale information.
o STL optimizations (memory/speed for list, red-black trees as
used by sets and maps).
o More use of GCC builtins.
o String optimizations (avoid contention on
increment/decrement-and-test of the reference count in the
empty-string object, constructor from input_iterators speedup).
* Static linkage size reductions.
* Large File Support (files larger than 2 GB on 32-bit systems).
* Wide character and variable encoding |filebuf| work (UTF-8, Unicode).
* Generic character traits.
* Also support |wchar_t| specializations on Mac OS 10.3.x, FreeBSD
5.x, Solaris 2.7 and above, AIX 5.x, Irix 6.5.
* The allocator class is now standard-conformant, and two additional
extension allocators have been added, mt_alloc and bitmap_allocator.
* PCH support: -include bits/stdc++.h (2x compile speedup).
* Rewrote |__cxa_demangle| with support for C++ style allocators.
* New debug modes for STL containers and iterators.
* Testsuite rewrite: five times as many tests, plus increasingly
sophisticated tests, including I/O, MT, multi-locale, wide and
* Use current versions of GNU "autotools" for build/configuration.
Yea, 3.4 uses yet another new libstdc++, but you can release builds done
with both gcc versions.
It should be something easy to script too:
mv ucc-bin ucc-bin-gcc34
mv ucc-bin ucc-bin-gcc33
echo "ln -s ucc-bin-<gcc version you want> ucc-bin" > GCC.README
Or maybe you alter the build script, whatever, I think the above is
probably more simple/elegant.
What's this I hear, still concerned about stability and standards
* G++ is now *much* closer to full conformance to the ISO/ANSI C++
standard. This means, among other things, that a lot of invalid
constructs which used to be accepted in previous versions will now
be rejected. It is very likely that existing C++ code will need to
be fixed. This document lists some of the most common issues.
* A hand-written recursive-descent C++ parser has replaced the
YACC-derived C++ parser from previous GCC releases. The new parser
contains much improved infrastructure needed for better parsing of
C++ source codes, handling of extensions, and clean separation
(where possible) between proper semantics analysis and parsing.
The new parser fixes many bugs that were found in the old parser.
And I -KNOW- you wanna be compliant with open-standards right? That's
your specialty no? I beg of you, please make it run as fast as the
Windows variant, you have the power.
Your adoring ass-kissing admirer,
More information about the ut2004