Intel C++ Compiler
-
Anyone using the Intel C++ Compiler? Is it really anything more than a wrapper over Microsoft compiler. Does it provide anything of note other than optimised math libraries? I've been trying it out for 64 bit Windows builds which is just about working and I was wondering if it's any good for cross compiling. It seems to have some attempted GCC compatibility but I can't really see why if it back-ends onto cl anyway?:confused: Not a programming question, just fishing for relevant experiences.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Anyone using the Intel C++ Compiler? Is it really anything more than a wrapper over Microsoft compiler. Does it provide anything of note other than optimised math libraries? I've been trying it out for 64 bit Windows builds which is just about working and I was wondering if it's any good for cross compiling. It seems to have some attempted GCC compatibility but I can't really see why if it back-ends onto cl anyway?:confused: Not a programming question, just fishing for relevant experiences.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
I don't use it (anymore). Last time I tried it, it was significantly better than MSVC. But that was back when MSVC couldn't really be taken seriously. From what I could find quickly, it seems that MSVC does not use AVX/AVX2 when auto-vectorizing, but ICC can.
-
I don't use it (anymore). Last time I tried it, it was significantly better than MSVC. But that was back when MSVC couldn't really be taken seriously. From what I could find quickly, it seems that MSVC does not use AVX/AVX2 when auto-vectorizing, but ICC can.
I guess that's where you'd expect Intel to be up to scratch and MSVC was certainly horribly out of date in terms of backend instruction set usage until fairly recently. At the moment the only differences I've encountered are a few corner cases with the linker. xilink seems to be pretty strict, picking up a few things that ld from MinGW-GCC 4.7.1 missed. I have one particularly nasty template related linker conundrum where MSVC, GCC, Clang and Embarcadero all behave differently with MSVC being the most relaxed, happily accepting what is clearly incorrect code and actually making a working executable and GCC being the devil's own nightmare to make work as it keeps changing its mind on whether to instantiate templates or not dependent on some hidden internal state. Clang is the only one so far that actually accepts what is in my opinion correct code but it's linker is essentially non operational on Windows so I can't test the link. Embarcadero also spits its dummy over me trying to dllexport functions written in header files so I can't check the link there but I know it will require me to manually add a hand written explicit default destructor for every template instantiation :wtf: Anyway I'm rambling 'cause I'm waiting for the link to complete again it it's just dropped. Looks good, I'm liking xilink :)
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
I guess that's where you'd expect Intel to be up to scratch and MSVC was certainly horribly out of date in terms of backend instruction set usage until fairly recently. At the moment the only differences I've encountered are a few corner cases with the linker. xilink seems to be pretty strict, picking up a few things that ld from MinGW-GCC 4.7.1 missed. I have one particularly nasty template related linker conundrum where MSVC, GCC, Clang and Embarcadero all behave differently with MSVC being the most relaxed, happily accepting what is clearly incorrect code and actually making a working executable and GCC being the devil's own nightmare to make work as it keeps changing its mind on whether to instantiate templates or not dependent on some hidden internal state. Clang is the only one so far that actually accepts what is in my opinion correct code but it's linker is essentially non operational on Windows so I can't test the link. Embarcadero also spits its dummy over me trying to dllexport functions written in header files so I can't check the link there but I know it will require me to manually add a hand written explicit default destructor for every template instantiation :wtf: Anyway I'm rambling 'cause I'm waiting for the link to complete again it it's just dropped. Looks good, I'm liking xilink :)
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Anyone using the Intel C++ Compiler? Is it really anything more than a wrapper over Microsoft compiler. Does it provide anything of note other than optimised math libraries? I've been trying it out for 64 bit Windows builds which is just about working and I was wondering if it's any good for cross compiling. It seems to have some attempted GCC compatibility but I can't really see why if it back-ends onto cl anyway?:confused: Not a programming question, just fishing for relevant experiences.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
Matthew Faithfull wrote:
Is it really anything more than a wrapper over Microsoft compiler.
It's definitely not a wrapper over Microsoft compiler; I believe the front-end is licensed from EDG. Historically, it used to have some advanced optimizations that MSVC lacked, but I don't know whether it is still the case.
-
Matthew Faithfull wrote:
Is it really anything more than a wrapper over Microsoft compiler.
It's definitely not a wrapper over Microsoft compiler; I believe the front-end is licensed from EDG. Historically, it used to have some advanced optimizations that MSVC lacked, but I don't know whether it is still the case.
Interesting. The docs I've read say is calls cl.exe to 'do the things the Intel compiler can't do' :confused: In practice it moans like mad if cl is not in the path but seems to go ahead and compile anyway although not to link which is more confusing as the docs say both that it uses link.exe, the Microsoft linker and that it uses xilink which is clearly not a wrapper for link.exe as it behaves quite differently.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
That all sounds very familiar.. It's like compilers each have their own unique personality, in a way.
Ah, that would explain GCC then, why it's such a cross compiler. It suffers from multiple personality disorder, which must be why you need a __gxx_personality() function in the C++ support library to find out which one it is today. :laugh:
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
Anyone using the Intel C++ Compiler? Is it really anything more than a wrapper over Microsoft compiler. Does it provide anything of note other than optimised math libraries? I've been trying it out for 64 bit Windows builds which is just about working and I was wondering if it's any good for cross compiling. It seems to have some attempted GCC compatibility but I can't really see why if it back-ends onto cl anyway?:confused: Not a programming question, just fishing for relevant experiences.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
I did an evaluation of icc about 18 months ago. It is it's own thing. I never ran across any reference that it used cl.exe nor did I see it do so. It was the best compiler I've used, by far (with one oddball exception.) The downside is that you get the best optimization only if you are targeting Intel processors (which we were.) The oddball exception was a function where icc tried to persist a temporary value in a loop. I tried tricking icc into not doing this, but nothing worked. In the end, I was laid off and the project cancelled, so it didn't much matter anyway.
-
I did an evaluation of icc about 18 months ago. It is it's own thing. I never ran across any reference that it used cl.exe nor did I see it do so. It was the best compiler I've used, by far (with one oddball exception.) The downside is that you get the best optimization only if you are targeting Intel processors (which we were.) The oddball exception was a function where icc tried to persist a temporary value in a loop. I tried tricking icc into not doing this, but nothing worked. In the end, I was laid off and the project cancelled, so it didn't much matter anyway.
Interesting. It's certainly building smaller binaries than MSVC or MinGW-GCC and build times are comparable with MSVC 11 without multiprocessor build. The linker did a good job up to a point but now it's failing to find a vtable for the type_info class so nothing is working. :mad: Elephanting link issues. Maybe the binaries are smaller because it's throwing away vtables when it shouldn't :rolleyes:
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)