[ut2004] Linux 3236 with fixed load times...
Nathan Van Eps
nathanvaneps at yahoo.com
Wed Jun 23 00:00:12 EDT 2004
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:
> 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