[ut2004] Linux 3236 with fixed load times...

[Nathan Van Eps]

That is totally not true about .NET. The programs generally explode your
server after three runs.

On Tue, 2004-06-22 at 19:16, J. Ryan Earl wrote:
> 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:
> 
> switch_to_gcc34.sh
> build.ut2004
> mv ucc-bin ucc-bin-gcc34
> make clean
> switch_to_gcc33.sh
> 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 
> compliance?
> 
> C++
> 
>     * 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,
> -ryan