Flexible particle system - Tools optimization

In this post I will test several compiler options and switches that could make the particle system run faster.

Read more to see how I've reached around 20% of performance improvement!

The Series

• Initial Particle Demo
• Introduction
• Particle Container 1 - problems
• Particle Container 2 - implementation
• Generators & Emitters
• Updaters
• Renderer
• Introduction to Software Optimization
• Tools Optimizations (this post)
• Code Optimizations
• Renderer Optimizations
• Summary

Plan

• Start
• Floating-point semantics mode
• Enable enhanced instruction set
• Additional switches
• Something missing
• Bonus: GCC (mingw)
• Wrap up and What's next

Start

We are starting with those numbers (Core i5 Sandy Bridge):

Core i5 Ivy Bridge:

(time in milliseconds)

The above results come from running 200 'frames' of particle system's update method. No rendering, only CPU work. count means number of particles in a given system. You can read more about this benchmark in the previous post.

And the Visual Studio configuration:

• Optimization: /02
• Inline Function Expansion: Default
• Favor Size or Speed: Neither
• Whole program optimization: Yes
• Enable enhanced instruction set: not set
• Floating point model: /fp:precise (default)

Of course, we are interested in making the above results faster. Also, I am wondering what Visual Studio's compiler options give potential performance improvements.

Floating-point semantics mode

By default Visual Studio uses /fp:precise floating-point semantics mode. It produces quite fast, but safe and accurate results. All calculations are done in the highest available precision. The compiler can reorder instructions, but only when it does not change the final value.

In particle system simulation we do not need so much precision. This is not a complex and accurate physics simulation, so we could trade precision for performance. We use floats only and small errors usually won't be visible.

By using fp:fast compiler relaxes its rules so that more optimization can be applied automatically by the compiler. Computation will be performed in, usually, lower resolution, so we do not lose time on casting from and to 80-bit precision. Additionally, the compiler can reorder instructions - even if it changes the final result a bit.

By switching from fp:precise to fp:fast I got the following results:

Core i5 Sandy Bridge

Core i5 Ivy Bridge

So around 5%...or even 11% of improvement.

Enable enhanced instruction set

Since SIMD instructions are available for a quite long time it would be wise to use those options as well. According to wiki:

• SSE2 appeared in Pentium 4 - 2001 or in AMD's Athlon 64 - 2003
• SSE4 appeared in Intel Core microarchitecture - 2006 or in AMD's K10 - 2007
• AVX are available since Sandy Bridge (2011) or AMD's Bulldozer (2011)

Unfortunately in my case, adding /arch:SSE2 does not make difference. It appe

But when I've used /arch:avx the timings were a bit better:

Core i5 Sandy Bridge

Core i5 Ivy Bridge

This time this is around 20% of improvement on Sandy Bridge and around 15% on Ivy Bridge. Of course, /fp:fast is also enabled.

BTW: When I used /arch:AVX2 the application crashed :)

Additional switches

I've tried using other compiler switches: Inline Function Expansion, Favor Size or Speed, Whole program optimization. Unfortunately, I got almost no difference in terms of performance.

Something missing?

Hmm… but what about auto vectorization and auto parallelization? Maybe it could help? Why not use those powerful features as well? In fact, it would be better to rely on the compiler that should do the most of the job, instead of manually rewriting the code.

In Visual Studio (since VS 2012) there are two important options /Qvec and /Qpar. Those options should, as names suggest, automatically use vector instructions and distribute tasks among other cores.

I do not have much experience using those switches, but in my case they simply do not work and I got no performance improvement.

To know what is going on with `auto' switches you have to use /Qvec-report and /Qpar-report additional compiler options. Then, the compiler will show what loops were vectorized or parallelized, or in which places it had problems. On MSDN there is a whole page that describes all the possible issues that can block 'auto' features.

Definitely, I need to look closer to those 'auto' powerful features and figure out how to use them properly.

BTW: What is the difference between auto vectorization and enable enhanced instruction set options?

Bonus: GCC (mingw) results

Although compiling the full particle demo (graphics) in a different compiler would be quite problematic, there is no such problem with 'cpuTest'. This benchmark is only a simple console application, so I've managed to rebuilt it using GCC (minGW version). Here are the results:

32bit, Ivy Bridge

GCC 4.8.1, -march=native -mavx -Ofast -m32 -std=c++11 -ffast-math

64bit, Ivy Bridge

-march=native -mavx -Ofast -m64 -std=c++11 -ffast-math

It seems that GCC optimizer does a much better job than Visual Studio (764.050ms vs 832.478ms)!

Wrap up & What's Next

This was quite fast: I've tested several Visual Studio compiler switches and it appeared that only floating point mode and enhanced instruction set options improved the performance in a visible way.

Final results:

In the end there is around 20% of speed up (for Sandy Bridge), 15% for Ivy Bridge. This is definitely not a huge factor, but still quite nice. It was only several clicks of the mouse! ;)

Question: Do you know other useful Visual Studio/GCC compiler options that could help in this case?

Next time, I will try to show how to further improve the performance by using SIMD instructions. By rewriting some of the critical code parts we can utilize even more of the CPU power.

Want Help and Test?

Just for an experiment, it would be nice to compile the code with gcc or clang and compare the results. Or use also a different CPU. If you want to help here is the repository here on github and if you have the timings please let me know.

The easiest way is to download exe files (should be virus-free, but please double check!) and save the results to a txt file.

References

• MSDN: Microsoft Visual C++ Floating-Point Optimization
• MSDN: Optimization Best Practices
• Dr.Dobb's: The Most Underused Compiler Switches in Visual C++