Slow Visual 2010

[Cyan]

Hi

I just had recently a try at the new Visual Studio 2010.
I was expecting some kind of improvements over the pretty good 2008 version, whatever it could be (layout, compatibility, performance...)

In fact, quite the contrary for the last bullet point.
Binaries compiled with VS2010 are about 10% slower than VS2008. Quite a huge drop.

Anyone having noticed such an effect ? or found a solution ?

[Edit] : after a few more tests, it seems that multi-threaded programs, on the other end, benefit from VS2010. Looks like it was the emphasis of this build. But single-threaded programs seems nonetheless adversely affected.

Regards

[Piotr Tarsa]

Maybe MS is pushing Intel Quad core sales

[Shelwien]

Might make sense to compare the option sets.
Presuming that we're talking about results with GUI defaults.

[Cyan]

Projects are transferred from 2008 to 2010.
Options are supposed to be rigorously equivalent.
I checked that by hand too, and found no difference.

While at it, i've also compiled an old program (LZP2), and in this example, there is no speed difference between 2008 and 2010.
So i guess the -10% rule is not universal...

[Gribok]

Hi

Anyone having noticed such an effect ? or found a solution ?

On my test cases speed is slower by 5% if compile bsc by Visual Studio 2010 vs Visual Studio 2008. But Intel C++ is a speed king in any way.

[encode]

Using newest VCs, don't forget to add this line at the top of each source:

#define _CRT_DISABLE_PERFCRIT_LOCKS

These days will switch myself to a newer Visual C++ 2010 Express...

Shelwien, what do you think about this new MS VC release? How it works with the ICL?

[Shelwien]

I mostly use console compilers (and also libs from VS6 to reduce bloat),
and I didn't test the new VS anyway, so dunno.
Though its clear that VS doesn't affect the performance, if you use
it with IntelC

Btw, sometimes I make portable compiler rips like this:
http://nishi.dreamhosters.com/IC_11-0-74.rar
(used as Compiler/icl.bat 1.cpp; although might not work
without the license file).

This one is a bit old though, but I can make a new version
if anybody's interested.

[M4ST3R]

ICL 11.1 can't be integrated in VS 2010. So you can't compile projects. Of course it's not a big deal if you only use the console.
During the installation of ICL, VS was not automatically detected. I had to manually edit some bat files with the correct paths.
Then expect some not important warnings (ICL doesn't not understand some new MS extensions thingies in the VS2010 headers)
The main issue I encountered is that VS2010 introduces new c++0x features not supported by ICL yet. The problem is that some (not all) VS2010 headers contains such things like rvalue reference. So ICL refuses to compile.

Full VS2010 compatibility will be avalaible in ICL 12.x (no release date AFAIK)

[Skymmer]

This one is a bit old though, but I can make a new version
if anybody's interested.

It would be very nice Shelwien

[Vacon]

Hello everyone,

I'd like to encourage you too, Shelwien


Best regards!

[osmanturan]

Shelwien, you may count me as well

[Shelwien]

Well, what about this then:
http://nishi.dreamhosters.com/IC_11-1-65.rar

[osmanturan]

Thanks!

[Fu Siyuan]

Very nice, Shelwien, Thanks!

[Shelwien]

Btw, this is the original version:
http://registrationcenter-download.i...p_11.1.065.exe
It should install using the lic-file from my rip.
It also includes x64 compilers and "extras" like IPP.

[Vacon]

Hello everyone,

thanks, Shelwien

Best regards!

Edit: No luck with Athlon 1700+

[joerg]

@Shelwien:

thank you very much!

wonderful !
унікальний !
класс !

best regards!

[Shelwien]

@Vacon:
If you mean paq8, you can make it more portable by
replacing /QxN with /arch:ia32 /DNOASM in make_paq.bat
...or by looking up "iccpatch" and patching the compiled executables :)

[Vacon]

Hello everyone,

@Vacon:
If you mean paq8, you can make it more portable by
replacing /QxN with /arch:ia32 /DNOASM in make_paq.bat
...or by looking up "iccpatch" and patching the compiled executables

First of all -> I knew that IC is a abriviation of "IntelCompiler" (or at least something similar). So it is no big surprise that there is something "strange" happening when running on a AMD
But what the compiler gave me is a bit more than a little patching of a compiled executable. It simply says: "The processor has to support the Intel SSE2 commands. Exiting..." Just at this moment I'm not able to reproduce this message or attach a screenshot, because I'm running xPUD right now (side-note: not too bad -> Online in a minute and 5 seconds after pushing the power-switch).

Best regards!

[Vacon]

Hello everyone,

so here is the screenshot.

Best regards!

[Shelwien]

Well, I guess now even their compiler is built with SSE2.
And their weird cpu detection is well known already.
So I guess, people with non-intel cpus would have to
patch at least icl.exe and mcpcom.exe

http://files.people.overclockers.ru/...r/iccpatch.rar
http://lunatics.kwsn.net/index.php?m...id=50;mirror=1

[Raymond_NGhM]

Here,
this is another ICC patch, forced to remove the "cripple AMD" function
from their compiler, Written by Tronix (C) 2010,
Based on Perl version (C) Copyright M. D Mackey 2004
For more info. look at "Readme.html" & GUI Screenshot...

it's good thing to improve speed during on load time for AMD's CPUs.

[VoLT]

To now, Microsoft released localized-version VS2010 for the following language:

• English
• French
• German
• Italian
• Japanese
• Russian
• Spanish

[Skymmer]

Here,
this is another ICC patch, forced to remove the "cripple AMD" function
from their compiler, Written by Tronix (C) 2010,
Based on Perl version (C) Copyright M. D Mackey 2004
For more info. look at "Readme.html" & GUI Screenshot...

it's good thing to improve speed during on load time for AMD's CPUs.

Nice tool. Thanks for file Raymond! But I'm curious. I just passed fa_compress.dll file through all 4 patchers, including the script from Shelwien and compared them. Only 2 files are identical - from Tronix patcher and patcher from Mackey. Well, no surprise - Tronix is based on Mackey's source. But interesting thing... Only Shelwien's script removed the

GenuineIntel

string from file at offset 0x53858. Don't know if its important or not. Also it would be nice to hear the opinion from somebody experinced - which patcher is most correct ? Test files are provided.