Is there an Intel C++ Compiler 10 update to Visual Studio 2008?
No doubt, there will be, when it is ready. Did you read the earlier post about late changes in VS2008 breaking much of the work invested in 10.1 compilers? The VS2008 OpenMP compatibility is working well for me now.
No I didnt. Well then I guess it will need some months to be released...
For me the Intel Compiler 10 has been a great improvement over the 9.1. Specially the build 026. Using it with Max precision and SSE3 it gives me an incredible low jitter not comparable to Visual C++ 2005/2008.
In digital audio software VC++ is really noisy compared to the clean and detailed Intel C++ 10. How important is a good compiler...
And if you worked with fixed instead of floating point numbers you would have even more details and less noise.
I wouldn't rush to get VS2008, I just tested it and I didn't like what I saw.
You can't please everyone. They've removed support for non-thread-safe code and for x87 code generation, and added openmp (at least in the professional version). So, it's less well suited for my 5 year old laptop, and likely to surface some problems in buggy numerical code. They still don't support auto-vectorization.I hear rumors that late changes make it difficult for other vendors to keep on schedule with modifications to their products. It would be more of a surprise if that didn't happen. ICL 10.1 and MKL 10 already added compatibility with Microsoft OpenMP, and it works in my tests.I hope they improved conformance to standards, but haven't looked into that. I set the icl.cfg switch to vc9, which may remove some legacy Microsoft strangeness from ICL.
You can't please everyone. They've removed support for non-thread-safe code and for x87 code generation, and added openmp (at least in the professional version).
Eh, if by x87 code you mean FPU code, it is still there, I saw it in ASM file. (some sort of) OpenMP was supported in VS 2005 too. So nothing new there except a load of shovelware installed which I will never use, and the Platform SDK has to be installed separately to compile x86 and x64 code.
By shovelware I mean this (and I selected only C++ during setup mind you):
Microsoft .NET Framework 2.0 Service Pack 1 365.00 MB
Microsoft .NET Framework 3.0 Service Pack 1 313.00 MB
Microsoft .NET Framework 3.5 28.54 MB
Microsoft Visual Studio Web Authoring Componenet 25.00 MB
Microsoft Windows SDK for Visual Studio 2008 Headers and Libraries 114.00 MB
Microsoft Windows SDK for Visual Studio 2008 Reference Assemblies and IntelliSense 6.65 MB
Microsoft Windows SDK for Visual Studio 2008 Tools 15.56 MB
Microsoft Windows SDK for Visual Studio 2008 Win32 Tools 18.58 MB
Windows SDK you see in this list several times is not Platform SDK. What is even worse if you remove one of those components (Web Authoring for example) and later need to add or remove something from the main Visual Studio installation (for example add C# support) it won't allow you to do it until you first let it repair that removed component which it does by reinstalling all of the above again in order. To cut it short, worst setup experience I ever saw for a product so far.
Well, this (infortunately) depends strongly on the code you're
compiling. My performance critical application which heavily depends on
templates runs 2 times slower when compiled with ICC. Sad but true -
ICC optimizes well C code. When it comes to advanced C++ features...
It's difficult to compare. Microsoft VC9 has /GL set as a default, which may help a lot with the C++ templates. ICL/icc have a corresponding -ipo option. The ipo or whole program optimizations aren't compatible in mixed Intel/Microsoft compiler builds, where /GL- must be set for VC9.As there are differences between Microsoft STL and gnu libstdc++, it would not be surprising to find situations where VC9 does a better job with the special Microsoft templates. If you can submit a case to premier.intel.com, where you can make a case that ICL is missing an optimization of general applicability, please do so.I've noticed cases where ICL/icc optimize better when the library templates are over-ridden by user code. If those are important to you, I would recommend submitting issues on them as well.
Great, thank you! It really is important and I think it should be for Intel too, since it is all about the now-hot interactive ray tracing :)
Question for tim18:
Any idea why Intel 10.1.014 chokes on CRT files from VC2008 (because of CodeAnnotation and sal.h) and if there is a workaround?
You should submit a full problem report. My own experience with the depths of Microsoft compatibility is limited.
No need for a full-blown report. If you have VS 2008 installed just try to compile some code using ICC which includes CRT headers for new MS runtime libraries and you will see what I am talking about.
Defining this prior to including stdio.h allows the compilation to continue:
#define _USE_DECLSPECS_FOR_SAL 1
Well, if you read the Host Software Requirements on the Download Page ( http://www.intel.com/cd/software/products/asmo-na/eng/compilers/279578.h... ) then you will see that there is support for Visual Studio 2008.
But the question is if this support is the same as for Visual Studio 2005? Can someone help me with this question? How about the integration of 10.1 in 2008?
It looks the same to me, with 10.1.020 (the first update to support VS2008 integration). Of course, the /Qvc9 option is set in place of /Qvc8, in accordance with incompatible changes in Microsoft headers. There are other differences; only multithreaded libraries are available, VC9 supports only SSE2, the default /GL option of VC9 doesn't work in mixed VC9/Intel builds (must set /GL-), while mixed VC9/Intel openmp builds are supported with the /Qopenmp-lib:compat.