Unexpected FTZ (/Qftz not set)

[Andrew_Smith1]

Hi

This standalone example illustrates my problem:

#include <iostream>

int main()
{
  double x = 1.2e-154;
  double y = 6.0e-156;

  x *= y;
  std::cout << x << std::endl;
}

Compiling with both MSVC11 and Intel 16.0 update 1, 64bit release with /fp:precise and (for Intel) /Qftz is NOT set.

Output:

$ ./ftz_msvc11.exe
7.2e-310

$ ./ftz_icpc16.exe
0

Same thing on linux, gcc returns the denormal, icpc returns zero.

So it seems that the Intel code is flushing the denormal even though I haven't actually asked it to. Is this expected behaviour? The full command line is

/GS /W3 /Gy /Zc:wchar_t /Zi /O2 /Fd"x64\Release\vc110.pdb" /fp:precise /D "__INTEL_COMPILER=1600" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Qipo /Zc:forScope /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Qprof-dir "x64\Release\" /Fp"x64\Release\ftz.pch" 

Many thanks,

Andrew

[Light_Intel]

I have tried to reproduce your issue using a x64 Windows* system with ICL 16.0 update I and VS 11 as specified in your post. I have used your code sample (thanks). However, I have not been able to reproduce it. See below:

icl /GS /W3 /Gy /Zc:wchar_t /Zi /O2 /fp:precise /D "__
INTEL_COMPILER=1600" /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNIC
ODE" /Qipo /Zc:forScope /Oi /MD /EHsc /nologo test.cpp
test.cpp
ipo: remark #11001: performing single-file optimizations
ipo: remark #11074: Inlining inhibited by limit max-size
ipo: remark #11074: Inlining inhibited by limit max-total-size
ipo: remark #11075: To get full report use -Qopt-report:4 -Qopt-report-phase ipo

ipo: remark #11006: generating object file C:\Temp\3\ipo_1320811.obj

$test.exe
7.2e-310

I have used a command line. Did you use a command line as well or did you run it from within VS?

Regards,

Noga

Intel Developer Support

[TimP]

Qftz is included in icl default fp:fast while in gcc the usual way to get it is -ffast-math. This is among the similarities between fp:fast and fast-math.

Beginning with introduction of avx, intel CPU shouldn't incur a performance penalty for additions involving denormal.  This improvement seems to have been intended to deal with usual gcc practice.  Multiplication still may require ftz for full performance.

I haven't heard of anyone changing practices regarding ftz usage to take advantage of current CPU. 

When Windows x64 was introduced, we were informed that the os would set ftz prior to starting a user task. Apparently, this has changed. 

[Andrew_Smith1]

Thanks for looking into it Noga

It's odd that you cant replicate it given I immediately got the same on a completely different machine, so here's the simplest way I've found for recreating the issue (this time on linux, source as per original post). Note no optimisation now. Be grateful for confirmation if anyone can/can't replicate this

blah@blah:~/dev/ftz $ g++ ftz.cpp -o gcc;./gcc
7.2e-310
blah@blah:~/dev/ftz $ icpc ftz.cpp -o icc;./icc
0

blah@blah:~/dev/ftz $ g++ --version
g++ (GCC) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
blah@blah:~/dev/ftz $ icpc --version
icpc (ICC) 16.0.1 20151021
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

blah@blah:~/dev/ftz $ cat /proc/cpuinfo | grep "model name" | tail -1
model name : Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz

PS. I originally encountered the issue on a Xeon E5-1650, for what it's worth.

Thanks,

Andrew

[Andrew_Smith1]

...or you could use this code. Which emphasises that the multiplication is flushing (and that DAZ is not enabled for that matter)

#include <iostream>

int main()
{
  double x = 1.2e-154;
  double y = 6.0e-156;
  double z = 7.2e-310; //=x*y
  std::cout << x * y << std::endl; 
  std::cout << z << std::endl;
}

blah@blah:~/dev/ftz $ icpc ftz.cpp -o icc;./icc
0
7.2e-310

[Andrew_Smith1]

Update, having read Tim's comment realised was missing -fp-model precise, and indeed now it's not doing FTZ (unless I explicitly use -ftz).

So the question now is why was the original Windows version seemingly ignoring the /fp:precise flag. In answer to Noga, yes I was using the IDE , and the command line I posted was from the project settings dialog.

Thanks,

[Light_Intel]

I will look into it to see if their is an issue with the IDE integration.

Noga

[Andrew_Smith1]

Hi Noga,

Yes I can confirm it's the IDE - command line compilation behaves as expected. Looking at one of the generated log files I see the following:

$ cat icl.command.1.tlog
¦¦^ E : \ D E V \ T E S T \ F T Z \ F T Z \ S O U R C E . C P P
 / c   / Q m 6 4   / Z i   / n o l o g o   / W a l l   / O 2   / O i   / Q i p o   / Q f t z   /
 D   _ _ I N T E L _ C O M P I L E R = 1 6 0 0   / D   W I N 3 2   / D   N D E B U G   / D   _ C
 O N S O L E   / D   _ U N I C O D E   / D   U N I C O D E   / E H s c   / M D   / G S   / G y
 / f p : p r e c i s e   / Q o f f l o a d - o p t i o n , m i c , c o m p i l e r , " "   / Z c
 : w c h a r _ t   / Z c : f o r S c o p e   / F o " X 6 4 \ R E L E A S E \ \ "   / F d " X 6 4
 \ R E L E A S E \ V C 1 1 0 . P D B "   / T P   E : \ D E V \ T E S T \ F T Z \ F T Z \ S O U R
 C E . C P P

...which looks incorrect, specifically it contains /Qftz.

Thanks,

Andrew

[Light_Intel]

Hi Andrew,

I have checked your code sample within VS and was able to duplicate your original issue. It seems that indeed we have an issue with the IDE integration. I have escalated it to our engineers [DPD200379834]. Thank you again for flagging this issue.

Regards,

Noga

[Andrew_Smith1]

Thanks Noga,

While this is being fixed do you have any suggestion on a possible workaround? Sadly, due to the size of our codebase (~3M lines) switching to command-line compilation is not a realistic option.

Andrew

[Light_Intel]

Hi Andrew,

In Properties --> Command Line, add "/Qftz-" in Additional Options to ensure FTZ is not utilized.

Regards,

Noga

[Andrew_Smith1]

Thanks Noga, that works

[Light_Intel]

This issue had been fixed in the 2016 Update 3 compiler