OT Recompiling GCC libraries in MinGW environment...

[Martin Brown]

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

 

[Phil Hobbs]

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

 

[Martin Brown]

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

 

[Phil Hobbs]

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

 

[amal banerjee]

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.

 

[Phil Hobbs]

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

 

[Don Y]

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.