Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
公告
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Win vs Mac vs Linux?

lklawrie
初学者
865 次查看
Trying to match our releases on the 3 platforms: Win/Mac/Linux (both 32 and 64), we're seeing some substantial diffs between the 3.

And not consistent -- sometimes good agreement between two of the platforms and differing on the third (and not always the same different one).

Yes, we are trying to match all compiler switches to be the same.

Any ideas or how to proceed? Is this just "expected"?

Linda
0 项奖励
7 回复数
Steven_L_Intel1
865 次查看
Not expected. The symptom strongly suggests access of uninitialized storage.
0 项奖励
Wendy_Doerner__Intel
重要分销商 I
865 次查看
Do the differences involve floating point results? I assume the platforms have different processors so that might be source of different floating point results in addition to Steve's suggestion. You can use the /check switch to check for some unitialized data references and this article explains how to get consitent floating point results with our compiler.

Wendy
Intel Developer Support
0 项奖励
Ron_Green
主持人
865 次查看
at optimization, yes different processors can give very slightly different results, and of course complex calculations can magnify those slight differences. And yes, operating systems and the math libraries can give differences.
If you goal is to get identical results, you can use /Od and -O0, /Qnolib-inline -nolib-inline
If you're trying to get optimized code consistent, -fp-model precise often helps. Also look at the new-fimf-arch-consistency option. but keep in mind, getting optimized code consistent across different processors, different OSes is a non-trivial task and may not be a reasonable goal.
ron
0 项奖励
lklawrie
初学者
865 次查看
Yes and yes and yes.

we have /ck uninit on. looking into the uninitialized possibilties.
we don't expect exact agreement, but the diffs are a bit too large to stomach.

thanks for the link.

Linda
0 项奖励
mecej4
名誉分销商 III
865 次查看
Does your application use random numbers? If so, check if the same generator is used and started with the same seed. Not setting the seed can result in different results from different runs on even the same platform.
0 项奖励
lklawrie
初学者
865 次查看
No, does not use random numbers in this instance.

Linda
0 项奖励
jimdempseyatthecove
名誉分销商 III
865 次查看
Linda,

I suggest you follow-up on Ron thoughts where small differences in calculation yield large differences in results. Until you experience one or two occasions of this it is hard to comprehend that your code is at fault. These errors in coding typically involve an assumption by the programmer of infinite precision .or. an assumption that programmers code written with consideration of finite precision is good enough.

Note, the impact of what this means is, the code you relied on written for one machine was likely given bad results or more likely the assumption of the precision of the results was that all digits in the results were accurate.

Knowing whichresults have the greatest disparity, check thecode that produced the results, see if it is sensitive to precision issues. If nothing stands out,starting with the results with the greatest disparity, step backwards in time (sequence of operations on the constituents of the result) and check for when the divergence occures. The purpose of stepping backwards is to narrow the choice of code sections that may be the source of the error.Repeat stepping backwards with occasional half step forwards until you locate the code that is responsible for the variance. Note, this may not necessarily be your code but may include a library call.

Jim Dempsey
0 项奖励
回复