Re: gcc/gsl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

--
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux