Intel C++ and Microsoft Compiler - c++

I am working on a high performance scientific application and found that pushing the computations into Intel compiler gives a lot of speedups by generating fast code, vectorization and better auto parallelization. But my main application is till in Microsoft C++ and uses COM. My questions are
1) Is it possible to build an assembly in Intel C++ compiler and load it into an application built with Microsoft compiler? Will it have incompatibilities?
2) What is the level of support for COM in Intel compilers.
Any advice in this area is appreciated.
Thank you
--Sai

Posting Sai Venkat comment as an answer:
Here is the reply I received from Intel. Intel compiler has 100% support for Microsoft compiler as long as we don't use /clr in compilation

Related

What is the default recommended compiler for mex compiling C++ source files that require Intel MKL as linear algebra package?

Is it Intel’s proprietary C/C++ compiler, or does it also work with Microsoft Visual C++?
After many days of experimenting, I have got stuck with dependencies, so I have come to the decision to ask this question here.
I highly appreciate any answer from more experienced members of StackOverflow. Thank you in advance.
I presume that the MinGW64 compiler is not supported in this case.
In my opinion, the question in the header must be the most common use case on Windows.
My setup: Windows 10, MATLAB R2091b, Intel MKL.

Visual Studio C++ performance vs Intel C++ compiler 15

Visual Studio 2015 has got a lot of changes on the C++ compiler side and I'm looking for a benchmark/performance comparison between the Intel C++ compiler and Visual Studio 2015 !
About performance, I mean the performance of the generated code, something like this : https://software.intel.com/en-us/c-compilers/iss
Is there an interest to use the Intel C++ compiler ? Will it produce faster code ?
Thanks
Few year ago, i did some tests on a mac-pro with intel proc.
Results:
icc+linux
vc+win
icc+win
gcc+linux
icc+linux was the very best.
vc+win, icc+win were pretty close.
Explanation: the more the software editor can exploit assertion on the system+hardware, the more it can design a compiler generating fast running code.
Intel is the best because it can exploit its processor and the system (open source).
VC under windows works great too, they know their OS.
Now, this depends of the kind of software. If your program will load a lot of data from disk the best will certainly be vc+win (they have great implementation of internal buffers...). If your program is very multithreaded, icc+linux is gonna win for sure. These are only 2 examples I can talk about because I tested these use cases.
I compared ICC and VC on Windows, and they were very close in terms of performance. I was able to make ICC beat VC only by using the "profile guided optimization" feature.

Xcode versus Visual Studio: Difference in runtime for compiled C++ programs

I have a small sorting program in C++ developed using XCode on a 2.4 GHz i7 Macbook Pro (I didn't change any of the configurations, so Xcode is probably using LLVM as compiler).
The program only incorporates very standard operations like calculating sums over (parts) of lists (i.e. no explicit use of pointers or so) and is only using standard types and vectors.
When compiling the same code using CL within Visual Studio 2010 on a 2.4 GHz i5 Notebook the runtime is significantly slower (at least by factor 100).
Are there any well-known performance issues with translations from Xcode to VS like the one I just described?
I haven't changed much in Visual Studio 2010 either: Are there some options for CL to be turned on or off that do the job?
Many thanks in advance.
The i7 and i5 processors have similar architecture. The two you speak of have the same clock rate, but are different tiers. Therefore, the i5 and i7 are not comparable on a benchmark like this. Only if you installed Windows on your Mac would you get a valid timing for both programs. The i7 is more powerful than the i5. #Jerry Coffins also has a point there.
Check out the difference between i5 and i7
In addition to #Jerry Coffin's comment, you need to use Shift+F5 combination to run your code without the debugger (yes, there is a debugger for release build as well).

Which C/C++ Compilers do enterprises use on Linux?

I have been using the GCC Compiler for months, which is great, and works very well. But I wonder which C++ Compiler do big/medium enterprises use for high optimizations/performance in Linux (x86, PowerPC...).
It may seem a very stupid question, but I havent found the answer anywhere.
As far as I know, the best PowerPC Compiler is the XL, but x86 I dont know anything.
EDIT: Thanks a lot for all the answers. They were all very helpful. You have convinced me to use GCC ;) Regards!
In the places I have worked we have always used gcc, even for embedded applications/software.
Performance improvements are much more likely to come from your code rather than your compiler choice anyway!
Intel sells its own compilers which are supposed to generate very performant code...at least on Intel CPUs.
The nice thing about ICC compared to GCC is that ICC uses EDG's C++ frontend, which means that it has better support for some advanced C++ features than GCC.
Everyone uses GCC - most Sun sites (for example) I've worked at replace their crappy Sun development tools (And boy, are they crappy) with Open Source ones like GCC.
For embedded PowerPC, check out the Wind River Diab Compiler.
Intel Compiler Collection, Sun ONE Studio, IBM XL C Compiler, Open64, Open Watcom, and of course GCC.
I presume some companies must be using Sun ONE & xlC for porting large projects as there is no reason why anyone would normally to use them.
EKOPath 4 Compiler Suite
https://github.com/path64/repositories
http://www.pathscale.com/ekopath-compiler-suite
PathScale is freely releasing the
source to the EKOPath 4 Compiler
Suite. EKOPath 4 is a high-performance
compiler that up until now has been
proprietary and costs nearly $2000 USD
per license, but now it's open-source
and can sharply outperform GCC in many
computationally-intense workloads.
The community indeed is excited for EKOPath now being open-source (GPLv3)

What are the differences between Visual C++ 6.0 and Visual C++ 2008?

What are the advantages/disadvantages between MS VS C++ 6.0 and MSVS C++ 2008?
The main reason for asking such a question is that there are still many decent programmers that prefer using the older version instead of the newest version.
Is there any reason the might prefer the older over the new?
Advantages of Visual Studio 2008 over Visual C++ 6.0:
Much more standards compliant C++ compiler, with better template handling
Support for x64 / mobile / XBOX targets
Improved STL implementation
Support for C++0x TR1 (smart pointers, regular expressions, etc)
Secure C runtime library
Improved code navigation
Improved debugger; possibility to run remote debug sessions
Better compiler optimizations
Many bug fixes
Faster builds on multi-core/multi-CPU systems
Improved IDE user interface, with many nice features
Improved macro support in the IDE; DTE allows access to more IDE methods and variables
Updated MFC library (in VS2008 Service Pack 1)
support for OPENMP (easy multithreading)(only in VS2008 pro.)
Disadvantages of moving to Visual Studio 2008:
The IDE is a lot slower than VS6
Intellisense still has performance issues (replacing it with VisualAssistX can help)
Side-by-side assemblies make app deployment much more problematic
The local (offline) MSDN library is extremely slow
As mentioned here, there's no profiler in the Professional version
In the spirit of Joel's recent blog post, I've combined some of the other answers posted into a single answer (and made this a community-owned post, so I won't gain rep from it). I hope you don't mind. Many thanks to Laur, NeARAZ, 17 of 26, me.yahoo.com, and everyone else who answered. -- ChrisN
Well, for one thing it may be because the executables built with MSVS 6 require only msvcrt.dll (C runtime) which is shipped with Windows now.
The MSVS 2008 executables need msvcrt9 shipped with them (or already installed).
Plus, you have a lot of OSS libraries already compiled for Windows 32 bit with the 6.0 C runtime, while for the 2008 C runtime you have to take the source and compile them yourself.
(most of those libraries are actually compiled with MinGW, which too uses the 6.0 C runtime - maybe that's another reason).
I would like to add that it's not the case that applications developed using Visual C++ 2008 must require more DLLs than those developed using Visual C++ 6.0. That's just the default project configuration.
If you go into your project properties, C/C++, Code Generation, then change your Runtime Library from Multi-threaded DLL and Multi-threaded Debug DLL (Release and Debug configurations) to Multi-threaded and Multi-threaded Debug, your application should then have fewer dependencies.
Off the top of my head, the advantages of the new Visual Studio are:
stricter adherence to standards
support for x64 / mobile / XBOX
targets
better compiler optimizations
(way) better template handling
improved debugger; possibility to
run remote debug sessions
improved IDE
improved macro support; DTE allows access to more IDE methods and variables
Disadvantages:
IDE seems slower
Intellisense still has performance
issues (replacing it with
VisualAssistX can help)
runtime not universally available
source control integration not up to
par (although in all fairness VC6
lacks this feature completely)
Did you know that MS VC6's implementation of the STL isn't thread-safe? In particular, the reference counting optimization in basic_string blows up even when compiled with the multi-threaded libraries.
http://support.microsoft.com/kb/813810
Besides the deployment mentioned above, the main advantage of MSVC 6.0 is speed. Because it is a 10 year old IDE it feels quite fast on a modern computer. The newer versions of Visual Studio offer more advanced features, but they come at a cost (complexity and slower speed).
But the biggest draw-back of MSVC 6.0 is its non-compliant C++-Compiler and Library. If you intend to do serious C++-Programming this is a show-stopper. If you only build MFC-Applications it is probably not much of a problem.
Visual C++ 6.0 integrates with memory tracking tools, such as Purify, HeapAgent, BoundsChecker and MemCheck, thoroughly and well since those memory tracking tools were actively maintained and aggressively sold after Visual C++ 6.0 came out.
However, since C++ has been out of vogue for a while, the companies that sell memory tracking tools still sell them but never update or integrate them with new Visual C++ versions, including Visual Studio 2008. So, using memory tracking tools with Visual Studio 2008 is frustrating, errorprone and, in some cases, impossible.
Since VC6 most of the focus of Visual Studio has been on C# and .NET, as well as other features, so some C++ old-timers see VC6 as the good old days. Things have improved in Visual Studio for C++ developers since those days, but not nearly as dramatically as for .NET users.
One way that VS2008 is significantly better than VC6 is that it can build C++ projects in parallel. This can result in significantly faster builds even on a single CPU system, but especially if you have multiple cores.
If you install all service packs for VS6 you still have a solid IDE/compiler combo. As a software developer who have to release products in the wild (over Internet) I don't want to o ship the VC++ runtimes and .NET framework everytime (I can't bundle them directly in my installer/executable, its forbidden by Microsoft). You know, several megabytes of runtimes to run kilobytes of code is kinda stupid. VC++ 6.0 only need your executable and 2 .DLL at best.
Also, debug runtimes cannot be distributed with VC++ .NET, not really good when I have a client which need to do some debugging of my products :)
There is in my opinion the major reasons why I still use VC++ 6.0, but the IDE itself is ugly (ie: no tabbing support). I usually bypass the IDE limitations by using codeblocks instead (CodeBlocks support CL.EXE/LINK.EXE for all VC++ versions)
Cobolfoo
Visual C++ 2008 is much more standards compliant (Visual Studio 6 doesn't support the C++ standard set in 1998).
VS2008 has better compiler (much more standards compliant, better optimizations, ...).
VS6 has much faster IDE. VS2008 IDE has many nice features, but it is a low slower than VS6.
Quick list of improvements you'll see going from 6.0 to 2008:
Many bug fixes
Better conformance to the C++ standard
Better compiler optimization
Improved UI (better intellisense, etc)
One thing that people sometimes forget is that VS 6.0 is over 10 years old now! At this point, I don't see how anyone would want to stick with it.
one tough thing we encountered was that "value" became a keyword.
Visual C++ 6 can be very buggy at times compared to 2008. Some things in particular:
Poor template support/oddities (for instance sometemplate<othertemplate<t>> not working, but sometemplate< othertemplate<t> > working)
Not standards compliant
Resource editor is rubbish ("blue lines" seem to move around randomly, among other things)
Only supports editing certain kinds of 8-bit bitmaps (I have to use imagemagick to convert bitmaps saved in paint.net to be able to be seen in picture resources)
Terrible support for working with read-only files / quirky sourcesafe integration.
Sometimes developing in VS6 feels like trying to get websites looking good in internet explorer 5.5