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

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

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?

      IA-32/AMD64 (x86-64)

    * 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
      pipeline description.
    * 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
      narrow characters.
    * 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
make clean
build ut2004
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 mailing list