Optimized release for x86-64 v4 architecture

[brechtsanders]

Would it be useful to have an optimized release for the most recent CPUs?

In particular the x86-64 v4 architecture supported by GCC via compiler flag -march=x86-64-v4.

Or x86-64 v3 architecture is supported by GCC via compiler flag -march=x86-64-v3, which may support a wider viriety of recent CPUs.

See this link for a list of which CPUs are included in these microarchitecture levels.

But as this could trigger issue #285 it would be best to disable AVX instructions using compiler flag -mno-avx.

Basically this would optimize for the 2017 Intel Skylake-X architecture, excluding Intel-specific instructions so AMD Zen4 or newer processors are also supported.

A release built with these compiler flags has been published here (x86-64 v4) and here (x86-64 v3).

[pschneider1968]

Please don't drop support for x86-64-v2, while you are at it. I still have some old machines that work perfectly fine and reliably from the Sandy Bridge and Ivy Bridge generations, so there's no reason to scrap them, as long as there is software support.

It's already bad enough that Red Hat (and thus Oracle Linux) require v3 as a minimum, so I can't even run RH/OEL VMs any more on my (still quite powerful!) 2-socket Ivy Bridge Xeon E5-2697 v2 server (24C/48T) w/ Proxmox VE. Luckily there is Alma Linux who still supply a complete EL distribution built for x86-64-v2.

And my main desktop PC w/ Windows where I use Winlibs GCC/MinGW is still a Sandy Bridge Intel Core i7-2600K which still is good enough for my purposes!

So: progress is good, but make it sustainable by avoiding unnecessary computer waste, please keep support for older microarchitectures, too!

[brechtsanders]

@pschneider1968 Thanks for your valuable feedback. I'm not planning to raise the CPU requirements, as I'm well aware a lot of people use older hardware.

This was mainly an experiment to see if there is even any speed benefit at all.

[pschneider1968]

Thanks for this clarification! 🙏

I tend to think that for most people, it's sufficient that they can generate code for new microarchitectures (which they can, of course). Whether or not the compiler makes use of those itself should not be that important, because I believe the performance gains are more of an academical nature than hard big numbers.

The areas where v3/v4 offer significant better performance are, AFAIK, the SIMD/AVX2/AVX512 instructions. I'm not sure whether GCC or any compiler would make big use of those, right?! 🤔

This is more the area of ffmpeg and friends, video encoding/decoding, graphics/audio processing, chess engines (I know Stockfish makes big use of those). But GCC/Clang? I don't think so...

[brechtsanders]

I'm pretty sure you're right about that.
And I had to switch of AVX anyway because 32-byte alignment is needed for that but not supported by GCC on Windows.

[sisyphus]

According to cpuid_tool output I have x86-64-v4. The system info I have says "11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz (2.50 GHz)".

But the experimental v4 build is posix threads, msvcrt compiler - and the msvcrt compilers create issues for me that the ucrt builds evade. So I've given the experimental v3 build a run in preference to the v4. (I also prefer the compilers with mcf threads - but that's merely a whimsical preference.)
Perhaps the following issue is because I've used the v3 build instead of the v4 build ? I've assumed that "v3" means "at least v3", but I don't really know.

If we want to use the long double printf() formats (La, Le, Lf, Lg) then, on the UCRT builds I'm finding that I need to define __USE_MINGW_ANSI_STDIO. Otherwise. we just get garbage values printed out.

The demo script (try.c):

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(void) {

long double ld;
long double i;

for(i = 35.0L;  i < 42.0L; i += 1.0L) {
  ld = powl(2.0L, i);
  printf("%.21Lg\n", ld);
}

return 0;
}

If I build that script using any of the UCRT winlibs compilers that I've tried && I don't define__USE_MINGW_ANSI_STDIO then I get:

D:\C>gcc -o try.exe try.c

D:\C>try
1.77221876374754759206e-312
1.77221876374754759206e-312
1.77221876374754759206e-312
1.77221876374754759206e-312
1.77221876374754759206e-312
1.77221876374754759206e-312
1.77221876374754759206e-312

If I then re-run that executable I get a different number (still presented 7 times).
But that's ok - as I said, I can just define __USE_MINGW_ANSI_STDIO.
Using gcc version 15.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r5), that works fine:

D:\C>gcc -o try.exe try.c -D__USE_MINGW_ANSI_STDIO

D:\C>try
34359738368
68719476736
137438953472
274877906944
549755813888
1099511627776
2199023255552

But here's what I get when I do the same thing with the experimental v3 build:

D:\C>gcc -o try.exe try.c -D__USE_MINGW_ANSI_STDIO

D:\C>try
34359738368
68719476736
137438953471.:
274877906943.:
549755813887.:
1099511627776
2199023255552

Where do those 3 instances of the trailing ".:" come from ?

That's pretty much the full extent of the issues I've found building various configurations of perl 5 with gcc version 15.2.0 (MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders, r1-x86-64-v3).
It causes just 2 tests in perl's test suite to fail.
There's another failing test where exp(Inf) is returning a large but finite value (instead of Inf), but I haven't investigated that yet.

[brechtsanders]

@sisyphus Yes any feature level is still supported by higher feature level CPUs.

I may have done one bit of experimenting too much: I built the entire 15.2.0mcf-13.0.0-ucrt-r1-x86-64-v3 build with -D__USE_MINGW_ANSI_STDIO=0, and judging from your feedback that may not have been a good idea.

[sisyphus]

I built the entire 15.2.0mcf-13.0.0-ucrt-r1-x86-64-v3 build with -D__USE_MINGW_ANSI_STDIO=0

I think there's a good chance you'll get away with that on the msvcrt builds. The demo script I posted doesn't need to have __USE_MINGW_ANSI_STDIO defined to a true value when built using your "v4" experimental build.
I was actually surprised to find out that the UCRT builds need it - and it took me way longer than I'm prepared to admit to work out just what was triggering the strange output.
(With perl, we still have -D__USE_MINGW_ANSI_STDIO=1, but I had come to think that it wasn't still needed.)

[sisyphus]

FWIW, the problem with exp(inf) that arises with long doubles using the "v3" compiler seems to be nothing more than it appears to be:

D:\C>type exp.c
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main(void) {

long double ld;
ld = strtold("Inf", NULL);
printf("ld: %.21Lg\n", ld);

printf("exp(inf): %.21Lg\n", expl(ld));

return 0;
}

D:\C>gcc -o exp.exe exp.c -D__USE_MINGW_ANSI_STDIO

D:\C>exp
ld: inf
exp(inf): 1.18973149535723176502e+4932

For long doubles, 1.18973149535723176502e+4932 is nextbelow(inf), so it's an off-by-one-ULP error.

Running the same script with the "v4" compiler I get:

D:\C>gcc -o exp.exe exp.c

D:\C>exp
ld: inf
exp(inf): inf

[brechtsanders]

That's still a problem. Maybe you should report it to the GCC team as a bug?

[sisyphus]

That's still a problem. Maybe you should report it to the GCC team as a bug?

I'm loath to approach them (at this time) about this problem with expl() because it is something that has arisen only with this particular "v3" experimental build of gcc.

It "feels" to me that the bug is probably in the way that gcc has been built, rather than in GCC itself.
It's not present in gcc version 15.2.0 (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r5).
But if the bug ever does show up in one of your regular builds, then I'll be sure to report it.