Intel Makes One Line Tweak To GCC To Fix A "Random Performance Penalty"

[phoronix]

Phoronix: Intel Makes One Line Tweak To GCC To Fix A "Random Performance Penalty"

Coming up on my radar today is a commit made to the GNU Compiler Collection (GCC) for adjusting the loop alignment with Intel's generic tuning path. In turn this should address "some random performance penalty in benchmarks" with coping better around cache lines...

https://www.phoronix.com/news/Intel-GCC-Loop-Alignment

[milkylainen]

"it will somehow solve the issue"

Sounds reassuring.
"We don't understand the issue and we don't understand the fix."

[emansom]

"it will somehow solve the issue"

Sounds reassuring.
"We don't understand the issue and we don't understand the fix."

I presume this is speak for "Intel fixed it in their microcode".

[milkylainen]

I presume this is speak for "Intel fixed it in their microcode".

I looked back through the history and I don't really understand this "fix".
For a generic target it needs better motivation. So did the original changes.
Now. I'm not a compiler engineer. But I do know that people immediately forget
why changes where made and with what proof something was a better choice.

The history doesn't really give any confidence or mass of knowledge over time.
It's just bucketloads of modifications, at times over many files and many subjects into a single commit.
Zero factual information or motivation.

To me, this looks like making generic more aligned with older non out of order archs than
modern ones. It doesn't say why. But then wouldn't this "optimization" applicable to
all modern archs? Which it isn't judging by the commit?

Reminds me of famous quotes on compilers that shouldn't have made it out of kindergarten...

[uxmkt]

"it will somehow solve the issue"
Sounds reassuring.
"We don't understand the issue and we don't understand the fix."

but if it makes the Phoronix testsuite run faster, do you really want to understand the fix?

[yoshi314]

"it will somehow solve the issue"

Sounds reassuring.
"We don't understand the issue and we don't understand the fix."

combining theory with practice.

[mdedetrich]

I looked back through the history and I don't really understand this "fix".
For a generic target it needs better motivation. So did the original changes.
Now. I'm not a compiler engineer. But I do know that people immediately forget
why changes where made and with what proof something was a better choice.

The history doesn't really give any confidence or mass of knowledge over time.
It's just bucketloads of modifications, at times over many files and many subjects into a single commit.
Zero factual information or motivation.

To me, this looks like making generic more aligned with older non out of order archs than
modern ones. It doesn't say why. But then wouldn't this "optimization" applicable to
all modern archs? Which it isn't judging by the commit?

Reminds me of famous quotes on compilers that shouldn't have made it out of kindergarten...

This to me speaks as substandard software hygiene. Normally when you have magic constants (which is what this appears to be), its standard practice to either comment or give a proper variable name to provide context (ideally both).

Having said that, I am also not a compiler engineer so I wouldn't be surprised if the entire codebase is just littered with these magic constants since its largely a small set of people that are ultra familiar with the software domain (especially engineers from the actual companies that make the semiconductors themselves) that work on this code and if so its just done this way because thats how its always been done.

[jabl]

With my former compiler developer hat on, no in general the entire codebase is not littered with magic constants. This particular change is to one of the tuning parameters, which is one place where you need such "magic" constants. As a starting point, with some knowledge of the microarchitecture one can make a first guess at what a suitable parameter would be, but typically they are tuned based on benchmarks. So for something like loop alignment, it might be related to the fetch width or something like that. So here they're bumping it to 16 bytes, maybe there are microarchitectural reasons which they aren't telling, or then it's just benchmark results that are better.

If one wants to criticize this patch, it's that there's no explanation of which benchmark was run and on what HW, and what the benchmark result changes were. And in particular, increasing alignment would increase the size of the code, so some analysis of that would be nice to see as well.

[Paradigm Shifter]

(joking) Michael reports in two years that this compiler tweak created a previously unknown race condition during building which can result in maliciously crafted code doing [something nasty] in the resulting compiled binary. (/joking)

Or something.

[carewolf]

"it will somehow solve the issue"

Sounds reassuring.
"We don't understand the issue and we don't understand the fix."

Makes you wonder if you couldnt get better results by doing the same for jump alignment.