build: Set march to IvyBridge for supported platforms

[GXTX]

It's safe to assume the vast majority of users are using a AVX1 capable CPU as the earliest supported Intel architecture is Sandy Bridge which is now at least 12 years old. Users on these older platforms can still run xemu although it's showing it's age quite severely. I run Ivy Bridge and have trouble with most things beyond, perhaps, MS Dash, and nxdk applications.

My reasons for not enabling march=haswell which would bring AVX2 support are obviously selfish (being I use an Ivy Bridge CPU), but a quiet poll in the Discord has found enough users that I believe it's still appropriate.

Now I can't say I've seen any real, or noticeable improvements, but looking quickly at the executable (23MB wow!) the compiler is vectorizing some things.

[j8r]

Pre-ryzen AMD processors such as Bulldozer, including FX series, don't have AVX2 too.

Sandy bridge should be able to run Xemu, especially with overclocking, maybe use -march=corei7-avx.

It can be also safe to enable SSE4.2.

Finally, the gains should be analysed. If there aren't any, this may not be worth the trouble - in addition to reduce compatibility, it might introduce bugs.

[GXTX]

Pre-ryzen AMD processors such as Bulldozer, including FX series, don't have AVX2 too.
Sandy bridge should be able to run Xemu, especially with overclocking, maybe use -march=corei7-avx.

This actually got me to look at what options were being enabled with march=ivybridge, even setting sandybridge would open the possibility to break compatibility with some AMD chips that do support AVX. So I think a better approach would be to just enable with -mavx, etc...

Finally, the gains should be analysed. If there aren't any, this may not be worth the trouble

I can't think of a good way to actually test this. There's no performant graphics benchmark application for Xbox, and most CPU based bound applications are already running as quick as the TSC is letting it. I have https://github.com/GXTX/xbox-bmarks but no real improvements can't be noticed.

it might introduce bugs.

This isn't worth much thought. QEMU is a globally used program and it's likely many users are compiling themselves with march=native, thus any bugs would be with xemu itself and should probably be fixed.

[j8r]

You can run a game title screen of some sort and see if the CPU is lower after the optimization than before. The processor could be downclocked, or limiting the CPU resources of the program with cgroups to better see the improvements.

If there are none I won't see any advantage of self-imposing such limitation.

[GXTX]

Process hacker to set real time, everything closed, and affinity to set only 4 cores, perhaps 1-2% sitting at the dash with EP/GP real time enabled.

We've have these instructions embedded in our CPUs since at least 2011, and they handle twice the amount of data of SSE2 yet we're so quick to disregard free performance in the name of compatibility. As I stated, I run Ivy Bridge (E3-1290 V2), and I find performance very lacking, anyone with older devices is already going to have a hard time hitting acceptable performance.

How long did it take for most to adopt MMX? It released in 1997, did it only become standard in 2009 or later?

[GXTX]

It is likely for Ubuntu to move to requiring Haswell. I believe given this, Ivy Bridge would be fine.

https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture