One of my codes has been ported to GCC and whilst it is well behaved and fully optimised in tests on other people's Linux systems I have a minor problem when compiling it x64 on my own Windows 11 box under MinGW.
It all compiles fine and code generation for my own code is properly optimised AVX2 or SSE, but the calls to numerical system library
functions are all using legacy x87 instructions and full 80 bit
arithmetic. This makes it way off the pace for benchmark speed.
It seems that MinGW comes with default numerical libraries that are
maximally compatible with ancient hardware but also glacially slow :(
I need to force it to link in the fast 64bit AVX2 or SSE numerical
libraries but I cannot figure out how to do that or recompile the
libraries from their source code with the right compiler options.
Has anyone encountered the same problem and been able to sort it?
Thanks for any enlightenment.
On 2023-09-11 05:58, Martin Brown wrote:
I'm not a MinGW user, but there are a few hints about possibly related issues: <https://stackoverflow.com/questions/67382785/why-does-mingw-w64-floating-point-precision-depend-on-winpthreads-version>
One of my codes has been ported to GCC and whilst it is well behaved
and fully optimised in tests on other people's Linux systems I have a
minor problem when compiling it x64 on my own Windows 11 box under MinGW.
It all compiles fine and code generation for my own code is properly
optimised AVX2 or SSE, but the calls to numerical system library
functions are all using legacy x87 instructions and full 80 bit
arithmetic. This makes it way off the pace for benchmark speed.
It seems that MinGW comes with default numerical libraries that are
maximally compatible with ancient hardware but also glacially slow :(
I need to force it to link in the fast 64bit AVX2 or SSE numerical
libraries but I cannot figure out how to do that or recompile the
libraries from their source code with the right compiler options.
Has anyone encountered the same problem and been able to sort it?
Thanks for any enlightenment.
Seems like a well-known problem.
On 11/09/2023 17:39, Phil Hobbs wrote:
On 2023-09-11 05:58, Martin Brown wrote:
I'm not a MinGW user, but there are a few hints about possibly related
One of my codes has been ported to GCC and whilst it is well behaved
and fully optimised in tests on other people's Linux systems I have a
minor problem when compiling it x64 on my own Windows 11 box under MinGW. >>>
It all compiles fine and code generation for my own code is properly
optimised AVX2 or SSE, but the calls to numerical system library
functions are all using legacy x87 instructions and full 80 bit
arithmetic. This makes it way off the pace for benchmark speed.
It seems that MinGW comes with default numerical libraries that are
maximally compatible with ancient hardware but also glacially slow :(
I need to force it to link in the fast 64bit AVX2 or SSE numerical
libraries but I cannot figure out how to do that or recompile the
libraries from their source code with the right compiler options.
Has anyone encountered the same problem and been able to sort it?
Thanks for any enlightenment.
issues:
<https://stackoverflow.com/questions/67382785/why-does-mingw-w64-floating-point-precision-depend-on-winpthreads-version>
Seems like a well-known problem.
Thanks very much Phil for the pointer. It seems I'm not alone.
I didn't find that in any of my searches partly because I assumed that
it has always been like that!
It was becoming annoying since nothing I did made it any better. I do
have an older version on another machine so I'll see if that is better behaved. The irony is that I downloaded the latest and greatest version specifically to avoid tripping up over known legacy bugs!
I could see from the debugger that it was using x87 library code and
infer from the error histograms that it was doing 80 bit rather than 64
bit computation and rounding down right at the end. Remarkably accurate
but a tremendous hit when moving non-aligned 10 byte objects around.
I got around it by cloning a chunk of the trig implementations at code
level so that I could benchmark GCC code despite the failings of the
MinGW system libraries. I'm sure I ought to be able to rebuild the full system library if I knew exactly how to do it but that also eludes me.
I have subverted MSC to allow me to use 80 bit computations which make
handy reference implementations with the extra bits for guard digits. I
used to keep a copy of MSC 6.0 around (the last version with native 80
bit FP support) but it too long in the tooth now to be worthwhile.
Martin Brown <'''newspam'''@nonad.co.uk> wrote:
On 11/09/2023 17:39, Phil Hobbs wrote:
On 2023-09-11 05:58, Martin Brown wrote:
I'm not a MinGW user, but there are a few hints about possibly related
One of my codes has been ported to GCC and whilst it is well behaved
and fully optimised in tests on other people's Linux systems I have a >>> minor problem when compiling it x64 on my own Windows 11 box under MinGW.
It all compiles fine and code generation for my own code is properly
optimised AVX2 or SSE, but the calls to numerical system library
functions are all using legacy x87 instructions and full 80 bit
arithmetic. This makes it way off the pace for benchmark speed.
It seems that MinGW comes with default numerical libraries that are
maximally compatible with ancient hardware but also glacially slow :( >>>
I need to force it to link in the fast 64bit AVX2 or SSE numerical
libraries but I cannot figure out how to do that or recompile the
libraries from their source code with the right compiler options.
Has anyone encountered the same problem and been able to sort it?
Thanks for any enlightenment.
issues:
<https://stackoverflow.com/questions/67382785/why-does-mingw-w64-floating-point-precision-depend-on-winpthreads-version>
Seems like a well-known problem.
Thanks very much Phil for the pointer. It seems I'm not alone.
I didn't find that in any of my searches partly because I assumed that
it has always been like that!
It was becoming annoying since nothing I did made it any better. I do
have an older version on another machine so I'll see if that is better behaved. The irony is that I downloaded the latest and greatest version specifically to avoid tripping up over known legacy bugs!
I could see from the debugger that it was using x87 library code and
infer from the error histograms that it was doing 80 bit rather than 64 bit computation and rounding down right at the end. Remarkably accurate but a tremendous hit when moving non-aligned 10 byte objects around.
I got around it by cloning a chunk of the trig implementations at code level so that I could benchmark GCC code despite the failings of the
MinGW system libraries. I'm sure I ought to be able to rebuild the full system library if I knew exactly how to do it but that also eludes me.
I have subverted MSC to allow me to use 80 bit computations which make handy reference implementations with the extra bits for guard digits. I used to keep a copy of MSC 6.0 around (the last version with native 80
bit FP support) but it too long in the tooth now to be worthwhile.
Can’t you hack up the linker script to get the 64-bit libraries?
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics
On Wednesday, September 13, 2023 at 7:49:03 PM UTC+5:30, Phil Hobbs wrote:
Martin Brown <'''newspam'''@nonad.co.uk> wrote:
On 11/09/2023 17:39, Phil Hobbs wrote:Can’t you hack up the linker script to get the 64-bit libraries?
On 2023-09-11 05:58, Martin Brown wrote:
I'm not a MinGW user, but there are a few hints about possibly related >>>> issues:
One of my codes has been ported to GCC and whilst it is well behaved >>>>> and fully optimised in tests on other people's Linux systems I have a >>>>> minor problem when compiling it x64 on my own Windows 11 box under MinGW. >>>>>
It all compiles fine and code generation for my own code is properly >>>>> optimised AVX2 or SSE, but the calls to numerical system library
functions are all using legacy x87 instructions and full 80 bit
arithmetic. This makes it way off the pace for benchmark speed.
It seems that MinGW comes with default numerical libraries that are
maximally compatible with ancient hardware but also glacially slow :( >>>>>
I need to force it to link in the fast 64bit AVX2 or SSE numerical
libraries but I cannot figure out how to do that or recompile the
libraries from their source code with the right compiler options.
Has anyone encountered the same problem and been able to sort it?
Thanks for any enlightenment.
<https://stackoverflow.com/questions/67382785/why-does-mingw-w64-floating-point-precision-depend-on-winpthreads-version>
Seems like a well-known problem.
Thanks very much Phil for the pointer. It seems I'm not alone.
I didn't find that in any of my searches partly because I assumed that
it has always been like that!
It was becoming annoying since nothing I did made it any better. I do
have an older version on another machine so I'll see if that is better
behaved. The irony is that I downloaded the latest and greatest version
specifically to avoid tripping up over known legacy bugs!
I could see from the debugger that it was using x87 library code and
infer from the error histograms that it was doing 80 bit rather than 64
bit computation and rounding down right at the end. Remarkably accurate
but a tremendous hit when moving non-aligned 10 byte objects around.
I got around it by cloning a chunk of the trig implementations at code
level so that I could benchmark GCC code despite the failings of the
MinGW system libraries. I'm sure I ought to be able to rebuild the full
system library if I knew exactly how to do it but that also eludes me.
I have subverted MSC to allow me to use 80 bit computations which make
handy reference implementations with the extra bits for guard digits. I
used to keep a copy of MSC 6.0 around (the last version with native 80
bit FP support) but it too long in the tooth now to be worthwhile.
Cheers
Phil Hobbs
--
Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC /
Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics
Having worked on embedded Linux(and still do) your suggestion, I am
afraid is going to lead to endless
misery, unless the person writing the hack knows exactly what he|she is doing. All the OP has to do is
get a new motherboard, the matching microprocessor, RAM and a solid state harddrive.
Linux distributions, in particular Fedora and Ubuntu are very easy to
install these days. Once the OS is
installed, the good old gcc compiler is readily installed using:
sudo su -
dnf install gcc
And then .. happy programming days. I have recently configured a machine
this way to do band structure
calculations wit Quantum Expresso.
Having worked on embedded Linux(and still do) your suggestion, I am afraid is going to lead to endless
misery, unless the person writing the hack knows exactly what he|she is doing. All the OP has to do is
get a new motherboard, the matching microprocessor, RAM and a solid state harddrive.
Linux distributions, in particular Fedora and Ubuntu are very easy to install these days. Once the OS is
installed, the good old gcc compiler is readily installed using:
sudo su -
dnf install gcc
And then .. happy programming days. I have recently configured a machine this way to do band structure
calculations wit Quantum Expresso.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 83:07:28 |
| Calls: | 6,716 |
| Files: | 12,247 |
| Messages: | 5,358,192 |