Jump to content
  • Advertisement
Sign in to follow this  
wood_brian

Build problem with VS 11

This topic is 2193 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm in the process of updating this performance comparison page using the latest version of Boost and newer compilers. I've updated the Linux results already but am having a problem getting a test case to build on Windows. Previously with VS 10 I used:


cl -O2 -I /Users/Store/boost_1_50_0_beta1/ -EHsc bser.cc /link /nodefaultlib:msvcprt /nodefaultlib:libcmt libboost_serialization-vc110-1_50.lib


The include directory was different of course with an earlier version of Boost. When I use that command with VS 11 I get errors like this:
libboost_serialization-vc110-1_50.lib(basic_archive.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in bser.obj

I built the serialization library with this command:
bjam variant=release link=static

This is on Windows 7. Thanks in advance. Edited by wood_brian

Share this post


Link to post
Share on other sites
Advertisement
The error message says you are trying to link something using the dynamic (MD) crt with something using the static (MT) one.

link

Either change your project to use the static crt or (better) build a version of boost dynamically linking the crt. Edited by mrbastard

Share this post


Link to post
Share on other sites

The error message says you are trying to link something using the dynamic (MD) crt with something using the static (MT) one.

link

Either change your project to use the static crt or (better) build a version of boost dynamically linking the crt.


I'm using the command line and makefiles. I added /MT when compiling the test case (bser.cc) but got the same errors.

I've always been able to get the tests to build using the static version of the Boost library in the past...

Share this post


Link to post
Share on other sites
link=static in your bjam command will build Boost as a static library, but by default I believe it will still use the dynamic CRT library. If you are using the /MT switch in your project, you need to add runtime-link=static to your bjam command so that your boost libraries reference the static version of the CRT.

Share this post


Link to post
Share on other sites

link=static in your bjam command will build Boost as a static library, but by default I believe it will still use the dynamic CRT library. If you are using the /MT switch in your project, you need to add runtime-link=static to your bjam command so that your boost libraries reference the static version of the CRT.


I got my testcase to build by rebuilding the boost library with runtime-link=static and then using this command:


cl -O2 -I /Users/Store/boost_1_50_0 -EHsc bser.cc /link libcpmt.lib libboost_serialization-vc110-s-1_50.lib


However, the executable is 306176 bytes. The testcase hasn't changed and previously using VC 10, the executable was 160768 bytes. The new executable is also slower than the older version was. On the other hand, the Ebenezer testcase is faster when built with VC 11 than it was with VC 10. Should I do something differently? Why?

Share this post


Link to post
Share on other sites
In the days of 1TB+ hard disks a ~160k increase in executable size hardly seems worth worrying about, but...

The key difference is that you're now statically linking boost with the CRT. That's going to pull in a whole lot more object code and link it into your executable, so hence you get a bigger executable.

As regards performance, VC11 is more than just a different compiler - it adds new headers, new libs, new everything. This happened before with the jump from 9 to 10 where libcmt.lib (x86 version, for example) went from ~9mb to ~16mb, which means a lot more code, a lot more happening, and consequently different performance characteristics are to be expected.

There's also the matter of VC11 still being pre-release software, so oddities are also to be expected.

Share this post


Link to post
Share on other sites

In the days of 1TB+ hard disks a ~160k increase in executable size hardly seems worth worrying about, but...

The key difference is that you're now statically linking boost with the CRT. That's going to pull in a whole lot more object code and link it into your executable, so hence you get a bigger executable.


Well, the Boost testcase is now between 2.8 and 3.0 times slower than the equivalent Ebenezer test. The link I referenced in the OP (as of today, still) says the Boost test was between 1.7 and 1.8 times slower than the Ebenezer using Boost 1.48 and VC 10. The testcase hasn't changed and from doing some diffs between Boost 1.48, 1.49 and 1.50, I haven't noticed any changes that would affect the performance of this test.

Iiuc, the way I used to build the boost testcase wasn't by dynamically linking anything, but isn't the same as what I did here either. I'm wondering if there's another way to build things that might yield better results for Boost. I'd like to avoid publishing flawed numbers here. If someone would like to check the numbers -- either on Linux or Windows -- that would be appreciated. I'll be happy to provide an archive of the tests and assistance in getting going.

Share this post


Link to post
Share on other sites
FWIW I did a quick test with boost 1.50 on VS10 and VS11 on the same machine using the first Boost test code on your page, with the same settings.

I ran each version several times with a command line of 5000000 (500000 was too close and too small).

VS10
------
File size: 270,336
Clock range: 213-215

VS11
------
File size: 316,416
Clock range: 238-243


So VS11 is roughly 10% slower than VS10 for that test case. Can't say for sure why, but the fact that it is pre-release software as mentioned is likely to have something to do with it. Edited by krippy2k8

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!