Tricks for Compiling Sources?

[Onno Garms]

Notice I was responding to Jim's post...

I saw the message tree, but as you quoted both, I assumed that you replied do both...

[Onno Garms]

I would assume that the one who compiled the sources can do this job significantly better than the author.

I spend a lot of time when a new version of icc comes out to see if there are any new things to try with optimizations... I care very much about speed.

I see. I agree that the loads of compiler switches are a good reason to outsource the compilation.

However, Jim has already confirmed that he compiled better than some authors. Not better than every author of course.

[mcostalba]

Not better than every author of course.

Nobody among SF developers can do something as fast as Jim's build and for what I have seen till today nobody has ever done a faster build using the compatible setup that Jim uses: there have been cases of binary compiled in 64 bit mode with POPCOUNT enabled that reached Jim's binary speed but this is not a fair comparison because Jim's doesn't enable POPCOUNT that alone gives a 3-4% speed boost.

[FrancoisK]

Long ago, I ran a bench to know how much PGO gained over non-pgo and the gain was signficant (around 10%).
I just ran another bench, and i was very surprised to discover that my PGO exe is slower than my non-PGO exe. I tested with different number of games for PGO training : 1,5 and 10 selfplay games (40/5). The performance does seem to increase with the number of games, but 10 games do not seem to be enough to reach the pure LTCG performance. Do my results seem right to you ? They don't to me.
I am using msvc 2008 with /O2.

François

[ldesnogu]

I have always wondered about PGO in general. Given the way it works, it's obviously extremely dependent on the training input. Many people test the improvement by using the same training set for both pre- and post-PGO, which is probably a best case scenario.

So I'd be very interested to read what people have found about PGO

[bob]

I have always wondered about PGO in general. Given the way it works, it's obviously extremely dependent on the training input. Many people test the improvement by using the same training set for both pre- and post-PGO, which is probably a best case scenario.

So I'd be very interested to read what people have found about PGO

It has always worked for me. What you are "learning" is how often each branch is taken or not taken. Then you make the most common case the "fall through" case and the less common case turns into a jump to the proper code. This makes cache usage a bit better because you avoid fetching stuff you are going to skip over most of the time... I usually see a 10-15% improvement. If you see none, or even things get worse, that suggests your "training" is wrong. I use 25 or so positions, searched for 10+ seconds per position, and I carefully chose opening, middlegame and endgame positions, and even one heavy-hitter EGTB position to train it on egtb execution...

[ldesnogu]

It has always worked for me. What you are "learning" is how often each branch is taken or not taken. Then you make the most common case the "fall through" case and the less common case turns into a jump to the proper code. This makes cache usage a bit better because you avoid fetching stuff you are going to skip over most of the time... I usually see a 10-15% improvement. If you see none, or even things get worse, that suggests your "training" is wrong. I use 25 or so positions, searched for 10+ seconds per position, and I carefully chose opening, middlegame and endgame positions, and even one heavy-hitter EGTB position to train it on egtb execution...

Branch prediction was exactly what made me wonder about the applicability of PGO: provide an input set where a given branch does not the exhibit the properties of real workload and you could end with a program running slower.

Thanks for explaining how you do your training.

[Dann Corbit]

Jim,

Has you tried MINGW under windows? What is its performance?

thanks

Hi Fermin,

Not so good under Windows. Compiles are around 20% slower than comparable Intel/Msvc ones.

Jim.

With the very latest version, I have found excellent performance. With PGO, it even outperformed Intel with PGO.

I am sure that there are lots of variables that go into this equation, of course.

[Kempelen]

Jim,

Has you tried MINGW under windows? What is its performance?

thanks

Hi Fermin,

Not so good under Windows. Compiles are around 20% slower than comparable Intel/Msvc ones.

Jim.

With the very latest version, I have found excellent performance. With PGO, it even outperformed Intel with PGO.

I am sure that there are lots of variables that go into this equation, of course.

Does anybody knows how pgo exactly works? I am an ignorant in this field

[Dann Corbit]

Jim,

Has you tried MINGW under windows? What is its performance?

thanks

Hi Fermin,

Not so good under Windows. Compiles are around 20% slower than comparable Intel/Msvc ones.

Jim.

With the very latest version, I have found excellent performance. With PGO, it even outperformed Intel with PGO.

I am sure that there are lots of variables that go into this equation, of course.

Does anybody knows how pgo exactly works? I am an ignorant in this field

The idea of PGO is very simple. If we run the program, we can see what code paths are exercised and make better branch predictions from statistics.

For example:
if (in_check()) generate_evade_capture_or_blocks();
else generate_normal_moves();

Checks are less common than normal moves so we can predict that it would be better to branch to generate_normal_moves(). But the compiler does not know this so it does not know which code path to predict. The solution is to instrument the program and run it. As we run the program, it captures statistics about what the code is really doing. Because of this, the optimizer can make better choices.

Typically PGO has three phases:
1. Compile with instrumentation
2. Run the program over typical usage patterns (e.g. run 10 games, run some EPD endgame problems, run some EPD normal problems, run some EPD quiet positions -- at least that is what I do)
3. Compile with option to use the instrumentation data.

All of the major compilers have PGO now. That includes Microsoft, GCC, and Intel, as well as others.