A suggestion for the WIKI/build instructions...

[roadapathy]

May I suggest adding this?

cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_FLAGS="-O3 -march=native" -DCMAKE_C_FLAGS="-O3 -march=native" -DCMAKE_C_FLAGS="-O3 -march=native";make -j$(nproc)

That command right there will build Openspades using the highest possible optimization. The Binary will be so tweaked that it won't run any a lesser CPU than what it's compiled on. On my system, I explicitly use bdver2 instead of native, but whatever. GCC knows your CPU and will pick the correct one with native.

That make command will ask GCC to use all CPU cores/threads- which could overheat some laptops, so beware. ;-)

[noway]

looks interesting, any hint of potential performance gain? fps could be a metric

[NotAFile]

I think compiler flags like -j[n] should be left to the person compiling.

Performance increases from this should be minimal to non-existant, while causing issues with older CPUs, so I don't think this is a great idea.

[Kurtoid]

I wouldn't blindly turn on high optimization. I think their should be left as a configuration options. On Wed, Feb 8, 2017, 7:48 PM Way, No <[email protected]> wrote: looks interesting, any hint of potential performance gain? fps could be a metric — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#574 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSzEWmo3oOKwDB3LlNKSmEqYv1nWM1Uks5ramJ1gaJpZM4L7jVv> .

[roadapathy]

There appears to be a performance bump, but I hope you understand that these are for the original compiling person's system and not to be distributed to others! If you distribute to others that which was compiled solely for your CPU, and that person has a different CPU, it will crash. For that you want to use -mtune, not -march!

You could distribute a version that runs on 64bit CPUs only, or Core2 or newer. There's no reason to support really old 32bit CPUs when there are so many new CPU operations that are being wasted.

NOTE: If you do this on your own system, and you don't share the binary, it will not cause CPU compatibility issues because GCC knows the capabilities of your CPU when it's explicitly set.

[roadapathy]

Sorry, I forgot to mention that this will also work for library files that Openspades depends on! So for example, you could use this technique to compile SDL2 and point your Openspades source/compiling to that new library!!

It works a little differently though:

First try ./configure --help in order to see what features you can add or remove from SDL2. Obviously, if you remove video drivers that have nothing to do with your system, then you get small, lighter, possibly faster code.

Then use this + your options:

./configure CFLAGS="-O3 -march=bdver2" CPPFLAGS="-O3 -march=bdver2" CXXFLAGS="-O3 -march=bdver2" X_CFLAGS="-O3 -march=bdver2"

I have tried to add CUDA and OpenCL optimizations but OpenCL made things less stable, and CUDA maybe don't add because it's already using the GPU. Vulkan? I can't answer that except that the video driver and some parts of MESA/X user some Vulkan.

[NotAFile]

Can you quantify "performance bump"? Have you done any measurements? Is the improvement from -O3 or from -march?

[roadapathy]

Good question. Both would give better performance because -O3 includes general optimizations, and doesn't spare binary size, and -march=native will add specific CPU optimizations. Here is what GCC can see on my system:

gcc -march=native -E -v - </dev/null 2>&1 | grep cc1

/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu - -march=bdver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -fstack-protector-strong -Wformat -Wformat-security

Will those op codes and features make the code faster on my system? I would think so.

[roadapathy]

http://www.phoronix.com/scan.php?page=article&item=gcc_49_optimizations&num=1

[NotAFile]

Have you had the chance to test the performance implications in OpenSpades? If so, we can look at those and discuss this further. Optimizations are not a magic bullet that can just double framerates, nor are compiler options. The benefits and drawbacks always depend on the specific application and can not be generalized.

[roadapathy]

I certainly would... if the game had a benchmark feature other than me just playing the game.

[feikname]

Related: #513

[roadapathy]

Hey guys, a friend of mine just made a pretty awesome point. He said, "Oh, you're optimizing the code just like how the console game developers do it. Those games only run on that console and that's why it is more optimized than PC." So I think there's something to it.

The first time I compiled the Linux Kernel for my specific CPU, it felt like I upgraded the whole system. Ha! So, try it out and see.