11 replies to this topic

[wood_brian]

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, 11 June 2012 - 02:57 PM.

[wood_brian]

Sorry, but I still haven't figured this out.

[mrbastard]

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, 14 July 2012 - 04:07 PM.

[wood_brian]

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...

[krippy2k8]

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.

[mrbastard]

And here is a bit more information on the choice of crt, in case you're still lost.

[wood_brian]

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?

[mhagain]

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.

[wood_brian]

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.

[krippy2k8]

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, 16 July 2012 - 05:45 PM.

[wood_brian]

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.

Thanks. Here VS11 is over 15% slower than VS10 with 5 million for input. The point about the pre-release software may have something to do with it, but I'd like to point out again that the numbers are reversed on the Ebenezer side -- the Ebenezer test with VS10 is over 20% slower than when built with VS11.

Edited by wood_brian, 16 July 2012 - 09:04 PM.

[krippy2k8]

Obviously you're using different C++ language features and/or library functions. Boost tends to reach into the deeper, darker recesses of C++ metaprogramming, which while inherently fast, typically gets less developer time for optimizations.

Edited by krippy2k8, 16 July 2012 - 11:44 PM.