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. -- Martin Brown
OT Recompiling GCC libraries in MinGW environment
Started by ●September 11, 2023
Reply by ●September 11, 20232023-09-11
On 2023-09-11 05:58, Martin Brown wrote:> > 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. >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> Seems like a well-known problem. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●September 13, 20232023-09-13
On 11/09/2023 17:39, Phil Hobbs wrote:> On 2023-09-11 05:58, Martin Brown wrote: >> >> 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. >> > 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> > > 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
Reply by ●September 13, 20232023-09-13
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: >>> >>> 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. >>> >> 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> >> >> 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
Reply by ●September 16, 20232023-09-16
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: > >> On 2023-09-11 05:58, Martin Brown wrote: > >>> > >>> 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. > >>> > >> 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> > >> > >> 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 ElectronicsHaving 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.
Reply by ●September 16, 20232023-09-16
amal banerjee <dakupoto@gmail.com> wrote:> 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: >>>> On 2023-09-11 05:58, Martin Brown wrote: >>>>> >>>>> 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. >>>>> >>>> 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> >>>> >>>> >>>> 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 > > 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. >For a code like that, I’d just use static linking and forget about it. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics
Reply by ●September 16, 20232023-09-16
On 9/15/2023 11:39 PM, amal banerjee wrote:> 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.The OP wants to benchmark existing compilers (which don't imply specific libraries) on a specific target platform. So, changing microprocessors isn't in the cards.
