[Corollax]

wine fs2_open_3_6_12r_INF_SSE2.exe seems to work equally well as  [i\./s2_open_3_6_12_INF_r[/i]. This might sound like a stupid question, but if wine is installed, is there a reason to prefer the native executable to the windows version?

Now that wxlauncher is in such fine shape, launcher6.exe is no longer a compelling answer. But if the windows version has extra optimizations built in, I could imagine it having better performance than the native version. (But then, you guys would know more about this than me!)

Thanks for the help, and happy FREDing!

[niffiwan]

Well, you'll probably get better support for fixing bugs found in native rather than in windows+wine   And I don't believe that there are any extra optimisations in the Windows version, so speed wise I'd expect native to run slightly faster due to not having to go through the wine compatibility layer.  Having said that, when I played WCS:DD using wine it seemed to perform about as well as FSO normally does (based purely on my observations, not any test data)

[chief1983]

Actually, I'm not sure Linux will ever compile with things like SSE2 optimizations on by default.  We could possibly add some configuration settings for that to the makefile, but right now I think it's still compiling with basic GCC options.  So a SSE2 Windows build might run as well or faster because of that.  But you're definitely right about the support, if you're going that route you're pretty much on your own, as we barely have enough Linux devs to keep the native binary running.

[Corollax]

Well, both of them work marvelously for myself and everyone I've shared them with. If I ever do experience problems, I certainly know which binary I should ask about, but for now I'm just a very happy pilot. For the time being, I think I'll run the windows version, if only because wxlauncher doesn't yet compile into a standalone executable yet.

Thanks for answering my silly questions. Fly sharp!   

[niffiwan]

Actually, I'm not sure Linux will ever compile with things like SSE2 optimizations on by default.  We could possibly add some configuration settings for that to the makefile, but right now I think it's still compiling with basic GCC options.  So a SSE2 Windows build might run as well or faster because of that. 

Well, the linux 32bit compile doesn't use SSE2 by default (we'd have to enable it in configure.ac), but the 64bit one does

Code: (configure.ac) [Select]

    x86_64-*-linux*)
        # linux
        echo "Using 64-bit Unix defines (for $host_os)"
        fs2_os_unix="yes"
        D_CFLAGS="$D_CFLAGS -m64 -march=athlon64 -ansi"
        D_CFLAGS="$D_CFLAGS -DLUA_USE_LINUX"


k8, opteron, athlon64, athlon-fx
    AMD K8 core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.)

and

-mfpmath=unit
    Generate floating point arithmetics for selected unit unit. The choices for unit are:

    `387'
        Use the standard 387 floating point coprocessor present majority of chips and emulated otherwise. Code compiled with this option will run almost everywhere. The temporary results are computed in 80bit precision instead of precision specified by the type resulting in slightly different results compared to most of other chips. See -ffloat-store for more detailed description.

        This is the default choice for i386 compiler.
    `sse'
        Use scalar floating point instructions present in the SSE instruction set. This instruction set is supported by Pentium3 and newer chips, in the AMD line by Athlon-4, Athlon-xp and Athlon-mp chips. The earlier version of SSE instruction set supports only single precision arithmetics, thus the double and extended precision arithmetics is still done using 387. Later version, present only in Pentium4 and the future AMD x86-64 chips supports double precision arithmetics too.

        For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default.

        The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit.

        This is the default choice for the x86-64 compiler.

[pecenipicek]

i really need to start looking at those funny interesting little bundles of joyful code. (when i was compiling, i specifed the -march=corei7 option for my compilation, and notice the -march=athlon64 sillyness in the compilation output log... now i know where to go to change that )

[ni1s]

You don't need to edit configure.ac to change your CXXFLAGS, just do
CXXFLAGS="-march=native -O3 -omg-optimize" ./configure

[pecenipicek]

yeah, so? i dislike having two different -march declarations when giving the compiler its options. look at the compiler output next time.


(also, -O3 vs -O2 is known as "abso****inglutely no difference at all" in the case of FSO)

[chief1983]

I think ni1s was being sarcastic with that, however, I'm not sure why -O3 wouldn't do its normal more-aggressive optimization hunting that it always does with GCC.  Care to elaborate on why there's no difference?  I'm not saying you should use it, at least in the case of a world flag, the Gentoo documentation discourages it, but I'm not sure how much testing FSO specifically has had with -O3.

[pecenipicek]

I think ni1s was being sarcastic with that, however, I'm not sure why -O3 wouldn't do its normal more-aggressive optimization hunting that it always does with GCC.  Care to elaborate on why there's no difference?  I'm not saying you should use it, at least in the case of a world flag, the Gentoo documentation discourages it, but I'm not sure how much testing FSO specifically has had with -O3.

my own testing, with the bp-massivebattle and general testing during tap development havent shown any, if much difference. i should probably get frametime graphs or something, to see a general performance comparison, but -O3 hasnt given me any observeable improvements.