Community
cancel
Showing results for 
Search instead for 
Did you mean: 
TimP
Black Belt
118 Views

/Qprotect-parens

I noticed from the end-of-beta survey that option protect-parens was introduced, presumably to comply with that part of C and C++ standards while permitting optimization of sum reduction when /fp:fast is set (as it is by default in ICL).

protect-parens shows excellent results in my testing of C and Cilk(tm) Plus code, with performance gains up to 40%, even though several cases of pessimization in violation of parens had already been corrected (where previously /fp:source was needed to optimize).

It kills simd optimization of several cases of C++ accumulate() and inner_product().  Was that expected? 

I suppose it's credible that protect-parens makes /fp:fast consistent with Microsoft compiler for STL, but I hate to revive the old argument that STL is incompatible with simd optimization or the mis-used terminology "code modernization."

0 Kudos
17 Replies
TimP
Black Belt
118 Views

Somewhat curiously, the linux spelling -fprotect-parens is borrowed from gfortran (where it is always set unless -fno-protect-parens is set); gcc/g++ had such an option only briefly and so the closest gcc equivalent is -fno-fast-math (which is a default).

Kittur_G_Intel
Employee
118 Views

Hi Tim,
Thanks for letting us know and I'll touch base with the developers on this to find out more. In the meantime, do you have any test case that shows the case where you mention it kills simd optimization of several cases of C++ accumulate() and inner_product()? Thanks
_Kittur

Kittur_G_Intel
Employee
118 Views

Hi Tim, yes our developer would like a test reproducer from you for the case where it kills simd optimization, appreciate much.

_Kittur 

TimP
Black Belt
118 Views

In principle, both cilk (tm) plus reducers and omp simd reduction offer alternatives to stl accumulate and inner_product, so it might not be a total surprise that Qprotect-parens disfavors the stl.  Evidently, simd optimization of stl reducers requires gcc options implying -fassociative-math (which can be a difficult combination) or icl -fp:fast.  I'll make a premier submission if that site too doesn't fall victim to captcha.

Kittur_G_Intel
Employee
118 Views

Thanks Tim, that would be perfect.

_Kittur 

Kittur_G_Intel
Employee
118 Views

Tim, thanks for creating and attaching a test reproducer in IPS. I've filed the issue with the developers and will touch base with you on any update thereof accordingly, appreciate much.

_Kittur

Kittur_G_Intel
Employee
118 Views

Hi Tim, this is an interesting issue apparently. Is it possible for you to attach a runnable test reproducer that can be executed instead of just compilation?  I'll request this in the issue in IPS as well, thx.
_Kittur

TimP
Black Belt
118 Views

In one of the cases in this benchmark, Qprotect-parens defeats vectorization occurring under #pragma omp simd safelen.

The others where vectorization makes a large difference to performance are inner_product and accumulate STL syntax.

Among Visual Studio updates there appear to be large differences in optimization (not affecting ICL).  I just noticed that the AVX2 support in VS2015 is better than the AVX support which dates back to VS2012.  There are cases now where STL transform() is vectorized by MSVC (even one inside an omp parallel).  VS itself still doesn't support OpenMP newer than 2.0.

Case attached to the IPS issue.  They are also available on github.com/tprince/lcd

I find that in order to run against Visual Studio 2015 RTM with Intel headers on path, it's necessary to copy in the headers associated with <float.h> from an earlier Visual Studio.  It seems that Microsoft no longer supports any version of C fully.  2015RC had not deleted these headers which Intel headers expect even if not used explicitly in the application.  They are missed only when compiling with CL rather than ICL.

 

Kittur_G_Intel
Employee
118 Views

Great, thanks for the attachment Tim which I've passed on to our developers. I'll update you accordingly in the IPS issue as well.

_Kittur

Melanie_B_Intel
Employee
118 Views

Tim Prince wrote:
 

I find that in order to run against Visual Studio 2015 RTM with Intel headers on path, it's necessary to copy in the headers associated with <float.h> from an earlier Visual Studio.  It seems that Microsoft no longer supports any version of C fully.  2015RC had not deleted these headers which Intel headers expect even if not used explicitly in the application.  They are missed only when compiling with CL rather than ICL.

 

Can you send an example of a test where some of the float headers are missing?  What do you mean they are missed only when compiling with CL?

TimP
Black Belt
118 Views

At Visual Studio 2015 command prompt:

$ cl -c -EHsc s114.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.22816 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

s114.cpp

At Intel64 vs2015 command prompt:

$ cl -c -EHsc s114.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.22816 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

s114.cpp
C:\Program Files (x86)\Intel_sw_development_tools\compilers_and_libraries_2016.0
.063\windows\compiler\include\float.h(37): fatal error C1083: Cannot open includ
e file: '../../vc/include/float.h': No such file or directory

So the Intel header introduces a dependence on float.h which is no longer present in VS2015 as automatically updated, although it was supported in 2015RC and 2013 and can be copied over into VS2015 as a workaround.  Note that the deleted standard headers include local Microsoft headers which also were deleted.

ICL doesn't fall back to the Microsoft <float.h>:

$ icl -c -EHsc -Qopenmp s114.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Versi
on 16.0.0.063 Beta Build 20150527
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

s114.cpp

I suppose it's difficult for Intel software to depend on including Microsoft headers if they may be removed unexpectedly.  It's difficult to see how Microsoft can claim compliance with any level of C standard if these headers have been removed.  They brag about supporting an additional C99 header at the same time as they remove others.

I attach the pre-processed file for the failed case.  It doesn't help me to understand.

Melanie_B_Intel
Employee
118 Views

They moved where some of the headers are coming from due to "the great crt refactoring"

In the latest RC the float.h is located in /Program Files x86/windows kits/10/include/10.0.10150...

in your s114.i, float.h is in a directory named with 10.0.10056

cl option /showIncludes shows the -I search path that the compiler is using to find include files. Use that to find the name of the "windows kits" directory and be sure that it is there. Maybe your vs2015 installation needs to be repaired. Our soon-to-be released 16.0 compiler will work better with vs2015, 15.0 has some limitations.

I'll find a box with RTM on it and test again

--Melanie

 

TimP
Black Belt
118 Views

There's a mandatory uppercase in showIncludes.

I had already run the 4-hour repair on VS2015; it made no apparent difference, then took 7 hours of defragging (Ultrabook). It's 10 hours to start over from scratch. I guess you're telling me it updated some parts but not others.  The other (big) include directory is labeled 100069.  

I can't find where Microsoft might document the setup.  Why wouldn't they make it automatic?

I'll try removing and installing psxe; I expect that will take several hours.  Is there a problem with 15.0 and 16.0 coexisting with VS2015?

Melanie_B_Intel
Employee
118 Views

I don't know why you wouldn't get your Windows Kits directory updated. I assume that's the missing piece.

I tried the RTM here (Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86) and cl can find <float.h>; it's under a Windows Kits directory numbered 10.0.10150.0

I've been testing pre-release candidates and I always get a new Windows virtual machine before installing the drop. Maybe their install got confused between a pre-release installation and the RTM. Their pre-release has language about being careful

This is my /showIncudes from cl.exe

Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt\float.h
Note: including file:  C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt\corecrt.h
Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\vcruntime.h
Note: including file:    C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\sal.h
Note: including file:     C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\ConcurrencySal.h
Note: including file:    C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\vadefs.h
Note: including file: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\cfloat
Note: including file:  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\yvals.h
Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xkeycheck.h
Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\crtdefs.h
Note: including file:    C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\vcruntime.h
Note: including file:   C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\use_ansi.h

(I thought that was going to show the search path)

The Windows SDK is available for download, https://dev.windows.com/en-us/downloads/windows-10-sdk, and you could post to Microsoft Connect.

Yes 15.0 and 16.0 should be able to co-exist.  I think I don't have the latest info about legacy mode in vs2015 so just ignore that.

Kittur_G_Intel
Employee
118 Views

Hi Tim,
Just letting you know that this issue is fixed in the latest 16.0 update 2 release which you can download and test it out. Thanks for bringing this issue to our attention and patience through this issue as well.
Kittur

TimP
Black Belt
118 Views

Yes, I see excellent C++ performance using this option with the current release.  Thanks.

16.0.2 is required to work without the work-around to disable VS2015.1 NaN support.  The problems mentioned above with earlier VS2015 installations are all settled with the current combination of VS and ICL.

Kittur_G_Intel
Employee
118 Views

Great, thanks Tim for the confirmation. Most importantly, thanks much for catching this issue early and filing accordingly, appreciate much. 

Kittur 

Reply