> 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.
Reply by Phil Hobbs●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 amal banerjee●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 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.
Reply by Phil Hobbs●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 Martin Brown●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 Phil Hobbs●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.
>
Reply by Martin Brown●September 11, 20232023-09-11
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