RADV vs. NVIDIA Vulkan/OpenGL Performance For Serious Sam 2017

[duby229]

Not sure if you really read my post. I suggested that Gentoo creates different groups of packages, so that you can provide different compiler options for each group. Then one of the groups are those packages that are problematic and/or don't comply with the language specification sufficiently. For that group of packages, you would then of course not use -O3. But, if you want, for others. Or, the other way around, you define named compiler-option-sets, and then each package specifies which set it uses. I believe that, or something in that direction, is also how Clear Linux handles this.

The bottom line would be that Gentoo maintainers determine which packages are problematic (similar to Clear Linux), and there would be two, or more, sets of compiler options. Unless someone fixes those problematic packages, which of course would be even better.

Believe it or not, Gentoo has provided similar functionality to what you describe, plus much more for years. Heck since like 99 or something like that. It's basically what portage profiles do. But I don't believe the developers have ever made defaults per package for compiler optimizations. It's always been left to the end user to configure. After all a user may not want to use gcc for this or that or some packages may need a specific compiler flag or etc.

So that is the whole reason why I said that without some mechanism to detect undefined behaviour, it's left to a users trial and error on Gentoo.
chithanh is well known on Gentoo's forum. He is fully qualified to answer.

[indepe]

Believe it or not, Gentoo has provided similar functionality to what you describe, plus much more for years. Heck since like 99 or something like that. It's basically what portage profiles do. But I don't believe the developers have ever made defaults per package for compiler optimizations. It's always been left to the end user to configure. After all a user may not want to use gcc for this or that or some packages may need a specific compiler flag or etc.

Obviously you are not saying that Gentoo has created groups of packages, such that you can compile one group with one option, for example -O1, and the other groups with -O2.

Or one group with -O2, and the other groups with -O3. (With GCC or clang or whatever you want to.)

Because then the problem would be solved.

EDIT:

So that is the whole reason why I said that without some mechanism to detect undefined behaviour, it's left to a users trial and error on Gentoo.
chithanh is well known on Gentoo's forum. He is fully qualified to answer.

Clear Linux has already solved that problem. Gentoo can do it as well.

[duby229]

Obviously you are not saying that Gentoo has created groups of packages, such that you can compile one group with one option, for example -O1, and the other groups with -O2.

Or one group with -O2, and the other groups with -O3. (With GCC or clang or whatever you want to.)

Because then the problem would be solved.

EDIT:


Clear Linux has already solved that problem. Gentoo can do it as well.

What I'm saying is that Gentoo's Package manager already has a system of configuration that would solve that problem, it's just simply that right now Gentoo's developers don't include compiler optimization in the profiles. It is left up to the user to configure. And again right now trial and error is the only mechanism an end user has.

Portage already supports profiles for many, many years now. Look into it for yourself. You clearly have never used it or else you wouldn't have had to even bother posting the same thing over again.

[indepe]

What I'm saying is that Gentoo's Package manager already has a system of configuration that would solve that problem, it's just simply that right now Gentoo's developers don't include compiler optimization in the profiles. It is left up to the user to configure. And again right now trial and error is the only mechanism an end user has.

Portage already supports profiles for many, many years now. Look into it for yourself. You clearly have never used it or else you wouldn't have had to even bother posting the same thing over again.

The user doesn't have to figure out which packages are compatible with -O3 if Gentoo handles those packages on a separate track (for lack of a better word). That's all I am saying. Which facilities Gentoo already provides, is not the question I am discussing.

[Jabberwocky]

What?

http://gpu.userbenchmark.com/Compare/Nvidia-GTX-980-Ti-vs-AMD-RX-480/3439vs3634

http://www.anandtech.com/show/10446/the-amd-radeon-rx-480-preview/4

http://www.guru3d.com/articles_pages/msi_radeon_rx_480_gaming_x_review,10.html

http://www.guru3d.com/articles_pages/msi_radeon_rx_480_gaming_x_review,14.html

See the last link for a GL test

In what world is the 480 not getting stomped by the 980ti? lol

In the "this is not launch day drivers anymore world". https://www.youtube.com/watch?v=gEw3CaNSbUo

[Enverex]

"All of these Serious Sam 2017 Vulkan/OpenGL Linux benchmarks were driven in a fully-automated and reproducible manner using the open-source Phoronix Test Suite benchmarking software."

Has anyone tried running the pts/sam2017 benchmark? It starts the game but just sits on the pre-menu "Press any key" screen for me.

[chithanh]

I need to correct you here.
O3 is better, except for edge cases.

No.
There is an older article from Linux Magazine, which benchmarked different optimization levels, and -O3 was not the winner of the majority of tests.

http://www.linux-mag.com/id/7574/3/

Sure, compilers have gotten better in the meantime, so the validity of these results has been somewhat diminished. But many of the reasons why -O3 frequently performs slower than -O2 have not changed.

But how can this degrade performance where processes work in parallel? (I suppose you mean threads?)

I should have just written parallelism. Because larger processes are more likely to evict each other from cache. Besides, if you have a tight loop which fits into L1 cache, it will execute faster if not unrolled.

if you distribute code to a larger number of users, isn't it worth the effort to actually measure the effect of compiler flags, instead of just defaulting to anything like -O2 ? And what about PGO?

There are trade-offs to everything. Mozilla for example used -Os for GCC builds, before a change in GCC 4's -Os behaviour introduced major performance regressions. Then they switched to -O3. And they hit address space limits when building with PGO on 32-bit architectures.

So as an advanced Gentoo user, what recommendations do you have for us about -how- to use -O3 effectively?

Compiling with -O3 is much more CPU and memory intensive, so use it only where it provides tangible benefit.

You can set per package compiler flags via /etc/portage/package.env for those packages where you know it is beneficial.

And if it is true, as you say, that code is broken in the scenario that if compiled with -O3 it behaves wrong, then doesn't that make it directly a gentoo developer problem? Not just gentoo, but every developers problem?

Gentoo ebuilds already filter -O3 (and -Os) from packages where this is known to break things. If you encounter additional packages where -O3 causes breakage, then report a bug in Gentoo bugzilla.

[indepe]

No.
There is an older article from Linux Magazine, which benchmarked different optimization levels, and -O3 was not the winner of the majority of tests.

http://www.linux-mag.com/id/7574/3/

Sure, compilers have gotten better in the meantime, so the validity of these results has been somewhat diminished. But many of the reasons why -O3 frequently performs slower than -O2 have not changed.

The article you refer to is from 2009, which is really too old to matter today. I have heard several times that -O3 still had problems about 10 years ago.

What I see in more recent tests is that they are more often the same performance, or O3 a tiny bit slower, but in some tests -O3 gives advantages of 20-90%. In other words, I think it is more than worth the effort to test the effects on the performance critical parts of an application (if you are interested in performance at all).

I should have just written parallelism. Because larger processes are more likely to evict each other from cache. Besides, if you have a tight loop which fits into L1 cache, it will execute faster if not unrolled.

There are trade-offs to everything. Mozilla for example used -Os for GCC builds, before a change in GCC 4's -Os behaviour introduced major performance regressions. Then they switched to -O3. And they hit address space limits when building with PGO on 32-bit architectures.

You can fine tune unrolling with specific flags, but in the end you do need to measure and compare speed. Not blindly use either option. Depending on how much time you generally spend on optimizing performance, of course. PGO seems to often result in significant improvements, and for me personally limitations of 32-bit architectures are not relevant.

Compiling with -O3 is much more CPU and memory intensive, so use it only where it provides tangible benefit.

You can set per package compiler flags via /etc/portage/package.env for those packages where you know it is beneficial.

I guess you'd use -Og (for example) during most of the development, in any case, since you need the debug features. However in so far as compilation time or compilation memory is really an issue, even per-file settings targeted for performance critical code are a possibility. (That is, speaking more generally than building Gentoo itself).

Gentoo ebuilds already filter -O3 (and -Os) from packages where this is known to break things. If you encounter additional packages where -O3 causes breakage, then report a bug in Gentoo bugzilla.

Interesting, I was reading about that yesterday but had the impression the end-user might need to do it on a per-package basis. Perhaps Gentoo should update its documentation to clarify this. Some who speak against using -O3, appear to get much of their info from https://wiki.gentoo.org/wiki/GCC_optimization , where it bluntly says "-O3 is also known to break several packages. Using -O3 is not recommended." That seems to be misleading regarding the possible use in Gentoo, if you are correct. (Besides it sounds like the author didn't exactly know anything specific either.)

There still is no specific information about actual problems outside of specific OS packages. Perhaps those simply involve non-standard OS-level trickery, just like some others are incompatible with clang. Or something like assuming that the up-to-date value of a variable is always in memory (as if declared volatile). You don't appear to have such information either.