gcc/gsl

[Patrick Dupre]

Hello,

I am not sure this issue is entirely relevant on this mailing list.
Maybe you could redirect me.

The same application (relatively heavy code), provides different values when it
is run and compiled on 2 different machines.
Both F40 (last update)
gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
One 
Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
The other one
Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
Actually, this happens when I use the gsl library.
gsl-devel-2.7.1-8.fc40.x86_64
for integration (gsl_integration_cquad).
Before integration, the values are strictly identical.
The same Makefile is used.
Now, if I copy the code generated by the machine A on machine B,
I get the same results as it had been run on machine A.
The size of both codes are slightly different.
I conclude that the issue is due to the compiler.
Indeed, the difference in the generated values seems pretty constant,
i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
i.e. a lot higher than the accuracy of the machine: < 1e-35.

Which one is the good one?
Why this behavior?
Can I solve the issue?

Thank for any help.

===========================================================================
 Patrick DUPRÉ                                 | | email: [e-mail]
===========================================================================

[home user]

On 11/13/24 11:32 AM, Patrick Dupre via users wrote:
> Hello,
>
> I am not sure this issue is entirely relevant on this mailing list.
> Maybe you could redirect me.
>
> The same application (relatively heavy code), provides different values when it
> is run and compiled on 2 different machines.
> Both F40 (last update)
> gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> One
> Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> The other one
> Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> Actually, this happens when I use the gsl library.
> gsl-devel-2.7.1-8.fc40.x86_64
> for integration (gsl_integration_cquad).
> Before integration, the values are strictly identical.
> The same Makefile is used.
> Now, if I copy the code generated by the machine A on machine B,
> I get the same results as it had been run on machine A.
> The size of both codes are slightly different.
> I conclude that the issue is due to the compiler.
> Indeed, the difference in the generated values seems pretty constant,
> i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> i.e. a lot higher than the accuracy of the machine: < 1e-35.
>
> Which one is the good one?
> Why this behavior?
> Can I solve the issue?
>
> Thank for any help.

(just some thoughts)

It's been a long time, but I recall that some libraries are linked in during the build, and some (shared libraries?) are linked in at run time.  Is the gsl identical (version, size, etc.) on both machines?  Is the gsl linked during the build or at run time?

Maybe try simple math programs (a square root, a trig function, and so on), same source code on both machines.  If the answers are different, then it seems likely to be the gsl.

Does the diff command confirm that source, makefile, and libraries are identical?  (Copy from one machine to the other, then do the diff.)

Does the diff command confirm that input data files are identical?

[Patrick Dupre]

> Sent: Wednesday, November 13, 2024 at 8:11 PM
> From: "home user via users" 
> To: [e-mail]
> Cc: "home user" 
> Subject: Re: gcc/gsl
>
> On 11/13/24 11:32 AM, Patrick Dupre via users wrote:
> > Hello,
> >
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > The same application (relatively heavy code), provides different values when it
> > is run and compiled on 2 different machines.
> > Both F40 (last update)
> > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> > One
> > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> > The other one
> > Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> > Actually, this happens when I use the gsl library.
> > gsl-devel-2.7.1-8.fc40.x86_64
> > for integration (gsl_integration_cquad).
> > Before integration, the values are strictly identical.
> > The same Makefile is used.
> > Now, if I copy the code generated by the machine A on machine B,
> > I get the same results as it had been run on machine A.
> > The size of both codes are slightly different.
> > I conclude that the issue is due to the compiler.
> > Indeed, the difference in the generated values seems pretty constant,
> > i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> > i.e. a lot higher than the accuracy of the machine: < 1e-35.
> >
> > Which one is the good one?
> > Why this behavior?
> > Can I solve the issue?
> >
> > Thank for any help.
>
> (just some thoughts)
>
> It's been a long time, but I recall that some libraries are linked in during the build, and some (shared libraries?) are linked in at run time.  Is the gsl identical (version, size, etc.) on both machines?  Is the gsl linked during the build or at run time?

The final binary code is generated with the option -lgsl
(dynamic )
> Maybe try simple math programs (a square root, a trig function, and so on), same source code on both machines.  If the answers are different, then it seems likely to be the gsl.

As I said, the maths are OK until the integration
> Does the diff command confirm that source, makefile, and libraries are identical?  (Copy from one machine to the other, then do the diff.)

The c code and the Makefile are strictly identical (cp -a)
libraries are strictly identical
> Does the diff command confirm that input data files are identical?

No input file (input parameters are in the c code).
> --
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jeffrey Walton]

On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users
 wrote:
> I am not sure this issue is entirely relevant on this mailing list.
> Maybe you could redirect me.
>
> The same application (relatively heavy code), provides different values when it
> is run and compiled on 2 different machines.
> Both F40 (last update)
> gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> One
> Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> The other one
> Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> Actually, this happens when I use the gsl library.
> gsl-devel-2.7.1-8.fc40.x86_64
> for integration (gsl_integration_cquad).
> Before integration, the values are strictly identical.
> The same Makefile is used.
> Now, if I copy the code generated by the machine A on machine B,
> I get the same results as it had been run on machine A.
> The size of both codes are slightly different.
> I conclude that the issue is due to the compiler.
> Indeed, the difference in the generated values seems pretty constant,
> i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> i.e. a lot higher than the accuracy of the machine: < 1e-35.
>
> Which one is the good one?
> Why this behavior?
> Can I solve the issue?

I would take the issue to the libgsl folks at
https://www.gnu.org/software/gsl/. The help-gsl 
users mailing list looks like the right place.

I would not be surprised if they knew the problem based on your description.

Jeff

[Barry]

> On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
>
> Why this behavior?

Do both versions produce the same results when copied to the other machine?

Might be compiler defaults are different. Do you have config for gcc in $HOME somewhere?

Try creating a new user on both machines and see how if the problem respoduces.

Barry

[Patrick Dupre]

> > On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
> >
> > Why this behavior?
>
> Do both versions produce the same results when copied to the other machine?

The results depends on the machine which has compiled the code, not on the machine
where the code is run.

Is there a way to specify the architecture i7 or i5 ?
> Might be compiler defaults are different. Do you have config for gcc in $HOME somewhere?

No
> Try creating a new user on both machines and see how if the problem respoduces.
>
> Barry

[Roger Heflin]

How different are the values?      How many significant figures match?  0? 5?

On Wed, Nov 13, 2024 at 12:33 PM Patrick Dupre via users
 wrote:
> Hello,
>
> I am not sure this issue is entirely relevant on this mailing list.
> Maybe you could redirect me.
>
> The same application (relatively heavy code), provides different values when it
> is run and compiled on 2 different machines.
> Both F40 (last update)
> gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> One
> Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> The other one
> Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> Actually, this happens when I use the gsl library.
> gsl-devel-2.7.1-8.fc40.x86_64
> for integration (gsl_integration_cquad).
> Before integration, the values are strictly identical.
> The same Makefile is used.
> Now, if I copy the code generated by the machine A on machine B,
> I get the same results as it had been run on machine A.
> The size of both codes are slightly different.
> I conclude that the issue is due to the compiler.
> Indeed, the difference in the generated values seems pretty constant,
> i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> i.e. a lot higher than the accuracy of the machine: < 1e-35.
>
> Which one is the good one?
> Why this behavior?
> Can I solve the issue?
>
> Thank for any help.
>
> ===========================================================================
>  Patrick DUPRÉ                                 | | email: [e-mail]
> ===========================================================================
>
> --
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Patrick Dupre]

> Sent: Wednesday, November 13, 2024 at 8:58 PM
> From: "Jeffrey Walton" 
> To: "Community support for Fedora users" 
> Cc: "Patrick Dupre" 
> Subject: Re: gcc/gsl
>
> On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users
>  wrote:
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > The same application (relatively heavy code), provides different values when it
> > is run and compiled on 2 different machines.
> > Both F40 (last update)
> > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> > One
> > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> > The other one
> > Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> > Actually, this happens when I use the gsl library.
> > gsl-devel-2.7.1-8.fc40.x86_64
> > for integration (gsl_integration_cquad).
> > Before integration, the values are strictly identical.
> > The same Makefile is used.
> > Now, if I copy the code generated by the machine A on machine B,
> > I get the same results as it had been run on machine A.
> > The size of both codes are slightly different.
> > I conclude that the issue is due to the compiler.
> > Indeed, the difference in the generated values seems pretty constant,
> > i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> > i.e. a lot higher than the accuracy of the machine: < 1e-35.
> >
> > Which one is the good one?
> > Why this behavior?
> > Can I solve the issue?
>
> I would take the issue to the libgsl folks at
> https://www.gnu.org/software/gsl/. The help-gsl 
> users mailing list looks like the right place.
>
> I would not be surprised if they knew the problem based on your description.

There a version 2.8 of gsl but is not available for fedora
> Jeff

[Jakub Jelinek]

On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote:
> > > On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
> > >
> > > Why this behavior?
> >
> > Do both versions produce the same results when copied to the other machine?
>
> The results depends on the machine which has compiled the code, not on the machine
> where the code is run.
>
> Is there a way to specify the architecture i7 or i5 ?

i7 vs. i5 don't mean anything for the compiler, the set of ISAs those CPUs
support and their generation is what matters.
Though, unless you compile with -march=native or -mcpu=native (or unless the
build system of the projects injects compiler flags depending on the current
CPU), the CPU on which you compile it shouldn't affect the flags with which
the code is compiled and same compiler + same source + same command line
flags should result in identical assembly.
If you are using -march=native or -mcpu=native, you've asked for it, you can
then use
gcc -march=native -v -S -xc /dev/null -o /dev/null 2>&1 | grep cc1
to print what exact flags does that turn.

Jakub

[Patrick Dupre]

> Subject: Re: gcc/gsl
>
> On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote:
> > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
> > > >
> > > > Why this behavior?
> > >
> > > Do both versions produce the same results when copied to the other machine?
> >
> > The results depends on the machine which has compiled the code, not on the machine
> > where the code is run.
> >
> > Is there a way to specify the architecture i7 or i5 ?
>
> i7 vs. i5 don't mean anything for the compiler, the set of ISAs those CPUs
> support and their generation is what matters.
> Though, unless you compile with -march=native or -mcpu=native (or unless the
> build system of the projects injects compiler flags depending on the current
> CPU), the CPU on which you compile it shouldn't affect the flags with which
> the code is compiled and same compiler + same source + same command line
> flags should result in identical assembly.
> If you are using -march=native or -mcpu=native, you've asked for it, you can
> then use
> gcc -march=native -v -S -xc /dev/null -o /dev/null 2>&1 | grep cc1
> to print what exact flags does that turn.

on i5
 /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=skylake -quiet -dumpbase null -version -o /dev/null

on i7
/usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -quiet -dumpbase null -version -o /dev/null
>

[Stephen Morris]

On 14/11/24 08:52, Roger Heflin wrote:
> How different are the values?      How many significant figures match?  0? 5?
>
> On Wed, Nov 13, 2024 at 12:33 PM Patrick Dupre via users
>  wrote:
> > Hello,
> >
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > The same application (relatively heavy code), provides different values when it
> > is run and compiled on 2 different machines.
> > Both F40 (last update)
> > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> > One
> > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> > The other one
> > Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> > Actually, this happens when I use the gsl library.
> > gsl-devel-2.7.1-8.fc40.x86_64
> > for integration (gsl_integration_cquad).
> > Before integration, the values are strictly identical.
> > The same Makefile is used.
> > Now, if I copy the code generated by the machine A on machine B,
> > I get the same results as it had been run on machine A.
> > The size of both codes are slightly different.
> > I conclude that the issue is due to the compiler.
> > Indeed, the difference in the generated values seems pretty constant,
> > i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> > i.e. a lot higher than the accuracy of the machine: < 1e-35.
> >
> > Which one is the good one?
> > Why this behavior?
> > Can I solve the issue?

Hi,
     Just my 2 cents worth. I develop at work in a language called SAS, 
which is interpretive like Python is. I see the sort of precision issues 
you are highlighting all the time, and the software vendor has written 
papers (which I can't lay my hands on atm) around the fact that they are 
expected because of the way computers work. There arguments are that 
when dealing with decimal numbers, because computers work in binary, 
there are certain numbers that cannot be accurately represented in 
binary, therefore you will get differences in the representation of 
those numbers. It may also have something to do with the fact that SAS 
stores numbers as double precision floating point. I've seen an upstream 
application supply us with a number to six decimal places and when we 
store that number in SAS the internal representation of that number does 
not match what we were supplied. One of the recommended solutions to 
this issue is to round numbers to the level of precision that you 
actually need.

regards,
Steve
> > Thank for any help.
> >
> > ===========================================================================
> >   Patrick DUPRÉ                                 | | email:[e-mail]
> > ===========================================================================
> >
> > --
> > _______________________________________________
> > users mailing list [e-mail]
> > To unsubscribe send an email [e-mail]
> > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

[Patrick Dupre]

> How different are the values?      How many significant figures match?  0? 5?

relatve difference: 2.7e-8
"noise" ~ 1e-35
values < 2e-23
> On Wed, Nov 13, 2024 at 12:33 PM Patrick Dupre via users
>  wrote:
> > Hello,
> >
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > The same application (relatively heavy code), provides different values when it
> > is run and compiled on 2 different machines.
> > Both F40 (last update)
> > gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3)
> > One
> > Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
> > The other one
> > Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
> > Actually, this happens when I use the gsl library.
> > gsl-devel-2.7.1-8.fc40.x86_64
> > for integration (gsl_integration_cquad).
> > Before integration, the values are strictly identical.
> > The same Makefile is used.
> > Now, if I copy the code generated by the machine A on machine B,
> > I get the same results as it had been run on machine A.
> > The size of both codes are slightly different.
> > I conclude that the issue is due to the compiler.
> > Indeed, the difference in the generated values seems pretty constant,
> > i.e., it seems proportional to the value itself: of the order 2.7e-8 (relative difference)
> > i.e. a lot higher than the accuracy of the machine: < 1e-35.
> >
> > Which one is the good one?
> > Why this behavior?
> > Can I solve the issue?
> >
> > Thank for any help.
> >
> > ===========================================================================
> >  Patrick DUPRÉ                                 | | email: [e-mail]
> > ===========================================================================
> >
> > --
> > _______________________________________________
> > users mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jakub Jelinek]

On Wed, Nov 13, 2024 at 11:21:46PM +0100, Patrick Dupre wrote:
> > Subject: Re: gcc/gsl
> >
> > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote:
> > > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
> > > > >
> > > > > Why this behavior?
> > > >
> > > > Do both versions produce the same results when copied to the other machine?
> > >
> > > The results depends on the machine which has compiled the code, not on the machine
> > > where the code is run.
> > >
> > > Is there a way to specify the architecture i7 or i5 ?
> >
> > i7 vs. i5 don't mean anything for the compiler, the set of ISAs those CPUs
> > support and their generation is what matters.
> > Though, unless you compile with -march=native or -mcpu=native (or unless the
> > build system of the projects injects compiler flags depending on the current
> > CPU), the CPU on which you compile it shouldn't affect the flags with which
> > the code is compiled and same compiler + same source + same command line
> > flags should result in identical assembly.
> > If you are using -march=native or -mcpu=native, you've asked for it, you can
> > then use
> > gcc -march=native -v -S -xc /dev/null -o /dev/null 2>&1 | grep cc1
> > to print what exact flags does that turn.

You didn't tell if you are actually using -march=native or -mcpu=native
in the gsl compilation or not.
> on i5
>  /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=skylake -quiet -dumpbase null -version -o /dev/null
>
> on i7
> /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -quiet -dumpbase null -version -o /dev/null

The difference is just --param l2-cache-size=X value, that can affect just
loop prefetching.

Jakub

[Michael Hennebry]

On Thu, 14 Nov 2024, Stephen Morris wrote:
> Just my 2 cents worth. I develop at work in a language called SAS, which 
> is interpretive like Python is. I see the sort of precision issues you are 
> highlighting all the time, and the software vendor has written papers (which 
> I can't lay my hands on atm) around the fact that they are expected because 
> of the way computers work. There arguments are that when dealing with decimal 
> numbers, because computers work in binary, there are certain numbers that 
> cannot be accurately represented in binary, therefore you will get 
> differences in the representation of those numbers. It may also have 
> something to do with the fact that SAS stores numbers as double precision 
> floating point. I've seen an upstream application supply us with a number to 
> six decimal places and when we store that number in SAS the internal 
> representation of that number does not match what we were supplied. One of 
> the recommended solutions to this issue is to round numbers to the level of 
> precision that you actually need.

That really does not match OP's problem.
That conversion from floating decimal to floating binary and back
does not necessarily produce the same value has long been known.
OP's problem is more like the same sequence
produces different results on similar machines.
If OP's program has very long decimal strings,
a difference in compilers might make a difference.
Without such decimal strings, C requires round to nearest.

To ensure that rounding of decimal strings is not the issue,
OP could the a literal format that can be exactly
stored in a binary floating point variable.
E.g.  0x5.Fp-3 = (5 + 15./16)/8 .

A more likely issue is different algorithms in the libraries.
a*b + x*y + g*e might be evaluated in different orders in the libraries.

[Roger Heflin]

On Wed, Nov 13, 2024 at 4:25 PM Patrick Dupre  wrote:
> > How different are the values?      How many significant figures match?  0? 5?
>
> relatve difference: 2.7e-8
> "noise" ~ 1e-35
> values < 2e-23

What significant figure is it of the result?   Heavy calculations are
sensitive to the precision of the underlying cpu calculations and one
cpu may pick a different underlying precision to use internally.   Ie
if one machine takes say 3 clock cycles to do a single or a double
then you might as well use a double internally and if the other
machine takes say 3 for a single and 6 for a double then on that
machine the compiler optimization will choose the single (to be
faster) and both may produce a different answer.

And likely NEITHER answer is mathematically exact and/or could even be
correct especially if the calculation is done in the wrong order that
causes significant sensitivities to underlying precision used by the
computer and/or cpu.

[Michael Hennebry]

On Wed, 13 Nov 2024, Roger Heflin wrote:
> On Wed, Nov 13, 2024 at 4:25?PM Patrick Dupre  wrote:
> > > How different are the values?      How many significant figures match?  0? 5?
> >
> > relatve difference: 2.7e-8
> > "noise" ~ 1e-35
> > values < 2e-23
>
> What significant figure is it of the result?   Heavy calculations are
> sensitive to the precision of the underlying cpu calculations and one
> cpu may pick a different underlying precision to use internally.   Ie

Not if both CPUs are supposed to be using IEEE 64-bit floating point.
The 80-bit double extended registers go mostly unused lately.
Their use in double precision arithmetic is supposed to be discoverable:
sizeof(double) != sizeof(double_t)
> if one machine takes say 3 clock cycles to do a single or a double
> then you might as well use a double internally and if the other
> machine takes say 3 for a single and 6 for a double then on that
> machine the compiler optimization will choose the single (to be
> faster) and both may produce a different answer.

Not if both CPUs are supposed to be using IEEE 32-bit floating point.
Again, discoverable: sizeof(float) != sizeof(float_t).

If rounding is indeed the issue,
'tis most likely in the libraries, e.g.,
one evaluates (x+y)+z and the other (x+z)+y .
One might use exp(x)-1 and the other expm1(x) or expl(x)-1 .

OP might swap libraries to test the hypothesis.

[Patrick Dupre]

> On Wed, Nov 13, 2024 at 11:21:46PM +0100, Patrick Dupre wrote:
> > > Subject: Re: gcc/gsl
> > >
> > > On Wed, Nov 13, 2024 at 10:50:38PM +0100, Patrick Dupre via users wrote:
> > > > > > On 13 Nov 2024, at 18:33, Patrick Dupre via users  wrote:
> > > > > >
> > > > > > Why this behavior?
> > > > >
> > > > > Do both versions produce the same results when copied to the other machine?
> > > >
> > > > The results depends on the machine which has compiled the code, not on the machine
> > > > where the code is run.
> > > >
> > > > Is there a way to specify the architecture i7 or i5 ?
> > >
> > > i7 vs. i5 don't mean anything for the compiler, the set of ISAs those CPUs
> > > support and their generation is what matters.
> > > Though, unless you compile with -march=native or -mcpu=native (or unless the
> > > build system of the projects injects compiler flags depending on the current
> > > CPU), the CPU on which you compile it shouldn't affect the flags with which
> > > the code is compiled and same compiler + same source + same command line
> > > flags should result in identical assembly.
> > > If you are using -march=native or -mcpu=native, you've asked for it, you can
> > > then use
> > > gcc -march=native -v -S -xc /dev/null -o /dev/null 2>&1 | grep cc1
> > > to print what exact flags does that turn.
>
> You didn't tell if you are actually using -march=native or -mcpu=native
> in the gsl compilation or not.

No, I do not use such options
> > on i5
> >  /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=12288 -mtune=skylake -quiet -dumpbase null -version -o /dev/null
> >
> > on i7
> > /usr/libexec/gcc/x86_64-redhat-linux/14/cc1 -quiet -v /dev/null -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -quiet -dumpbase null -version -o /dev/null
>
> The difference is just --param l2-cache-size=X value, that can affect just
> loop prefetching.
>
> Jakub

[Patrick Dupre]

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

int main () {
  printf ("Double: %d %d\n", sizeof(double), sizeof(double_t)) ;
  printf ("Float: %d %d\n", sizeof(float), sizeof(float_t)) ;
  return 0 ;
  }

provides
Double: 8 8
Float: 4 4

on both machines
> Sent: Thursday, November 14, 2024 at 3:46 AM
> From: "Michael Hennebry" 
> To: "Community support for Fedora users" 
> Subject: Re: gcc/gsl
>
> On Wed, 13 Nov 2024, Roger Heflin wrote:
> > On Wed, Nov 13, 2024 at 4:25?PM Patrick Dupre  wrote:
> > > > How different are the values?      How many significant figures match?  0? 5?
> > >
> > > relatve difference: 2.7e-8
> > > "noise" ~ 1e-35
> > > values < 2e-23
> >
> > What significant figure is it of the result?   Heavy calculations are
> > sensitive to the precision of the underlying cpu calculations and one
> > cpu may pick a different underlying precision to use internally.   Ie
>
> Not if both CPUs are supposed to be using IEEE 64-bit floating point.
> The 80-bit double extended registers go mostly unused lately.
> Their use in double precision arithmetic is supposed to be discoverable:
> sizeof(double) != sizeof(double_t)
> > if one machine takes say 3 clock cycles to do a single or a double
> > then you might as well use a double internally and if the other
> > machine takes say 3 for a single and 6 for a double then on that
> > machine the compiler optimization will choose the single (to be
> > faster) and both may produce a different answer.
>
> Not if both CPUs are supposed to be using IEEE 32-bit floating point.
> Again, discoverable: sizeof(float) != sizeof(float_t).
>
> If rounding is indeed the issue,
> 'tis most likely in the libraries, e.g.,
> one evaluates (x+y)+z and the other (x+z)+y .
> One might use exp(x)-1 and the other expm1(x) or expl(x)-1 .
>
> OP might swap libraries to test the hypothesis.
>
> --
> Michael   [e-mail]
> "SCSI is NOT magic. There are *fundamental technical
> reasons* why it is necessary to sacrifice a young
> goat to your SCSI chain now and then."   --   John Woods
> --
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jakub Jelinek]

On Thu, Nov 14, 2024 at 09:25:40AM +0100, Patrick Dupre wrote:
> No, I do not use such options

Then I don't believe you can get different assembly from the same compiler
same source same options.  GCC ought to produce the same output
reproduceably (unless the source uses __DATE__, __TIME__ or __TIMESTAMP__
macros) and if you use -frandom-seed= option (without that on rare
occassions some symbols could have different random characters in the names
and unique coverage stamps; but even without -frandom-seed= it randomly
choose how to compile code).  And unless you use PGO and the program differs
between test runs.

Jakub

[Patrick Dupre]

Hello,

I am sorry, but I think that I solved the issue by running a make clean
Now the generated code is the same on both machines.

Probably I have an object from a previous version of gsl which was not recompiled
at the same time on both machines.

My Makefile is probably not optimum.
How can I force a compilation in case of an update of a library like gsl?

Thank to every body for the help.
> Sent: Thursday, November 14, 2024 at 9:56 AM
> From: "Jakub Jelinek" 
> To: "Patrick Dupre" 
> Cc: "Community support for Fedora users" , "Barry" 
> Subject: Re: gcc/gsl
>
> On Thu, Nov 14, 2024 at 09:25:40AM +0100, Patrick Dupre wrote:
> > No, I do not use such options
>
> Then I don't believe you can get different assembly from the same compiler
> same source same options.  GCC ought to produce the same output
> reproduceably (unless the source uses __DATE__, __TIME__ or __TIMESTAMP__
> macros) and if you use -frandom-seed= option (without that on rare
> occassions some symbols could have different random characters in the names
> and unique coverage stamps; but even without -frandom-seed= it randomly
> choose how to compile code).  And unless you use PGO and the program differs
> between test runs.
>
> Jakub

[George N. White III]

On Wed, Nov 13, 2024 at 3:58 PM Jeffrey Walton  wrote:
> On Wed, Nov 13, 2024 at 1:33 PM Patrick Dupre via users
>  wrote:
> > I am not sure this issue is entirely relevant on this mailing list.
> > Maybe you could redirect me.
> >
> > Which one is the good one?
> > Why this behavior?

Some software uses different code depending on the CPU model.
> > Can I solve the issue?

The normal process to understand problems like this is to isolate a minimal
section of code where the problem occurs.  Sometimes that doesn't work,
e.g., because the real issue is some out-of-bounds overwriitng of the data.

A small example allows you or gsl devs to experiment with compiler options
and use gdb to step thru the code, but at that point you may just be
duplicating
work others have already done, so the main value would be as a learning
exercise.
> I would take the issue to the libgsl folks at
> https://www.gnu.org/software/gsl/. The help-gsl 
> users mailing list looks like the right place.
>
> I would not be surprised if they knew the problem based on your
> description.
>
> Jeff

Same here.  You may be asked to provide a stripped down test case (which
can be added to the existing list of tests).

[George N. White III]

On Thu, Nov 14, 2024 at 12:23 PM Patrick Dupre via users <
[e-mail]> wrote:
> Hello,
>
> I am sorry, but I think that I solved the issue by running a make clean
> Now the generated code is the same on both machines.
>
> Probably I have an object from a previous version of gsl which was not
> recompiled
> at the same time on both machines.

My Makefile is probably not optimum.

How can I force a compilation in case of an update of a library like gsl?
>

I think this is a limitation of make.  New versions of libraries don't
normally
trigger recompiles.  I habituall run `make clean` after any significant
changes
to external packages.

Thank to every body for the help.
>

Glad you found a solution.  I've had some projects run into big trouble
after
linux updates when we couldn't reproduce previous results -- causes have
ranged from bugs in the old library, new bugs in new library, and hardware
failures.