performance tuning on boost version 1_64_0
Hello, I recently upgrade boost version of a visual C++ program from an old version of 1_58_0 to 1_64_0. Compared to the original executable, the newly upgraded one runs very slow (more than 6 times longer) even I disable the debug mode and set the optimization to /ox in visual environment. The other difference between the old and the upgrade ones is the visual studio version. The old one is on 2010 and the new one 2013. Anyone has any idea for why it behaves like this? Which kind of performance tuning I need to look into? Thank you so much for your help! Connie Sent from Yahoo Mail. Get the app
From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Connie Zhang via Boost-users Sent: 02 July 2017 20:34 To: boost-users@lists.boost.org Cc: Connie Zhang Subject: [Boost-users] performance tuning on boost version 1_64_0 Hello, I recently upgrade boost version of a visual C++ program from an old version of 1_58_0 to 1_64_0. Compared to the original executable, the newly upgraded one runs very slow (more than 6 times longer) even I disable the debug mode and set the optimization to /ox in visual environment. The other difference between the old and the upgrade ones is the visual studio version. The old one is on 2010 and the new one 2013. Anyone has any idea for why it behaves like this? Which kind of performance tuning I need to look into? Thank you so much for your help! Well, it isn’t much help, but you will need to provide many more clues before anyone can help. It isn’t Boost wide or someone else would have noticed. In general, new compilers are producing better code, so there is no reason to suspect VS compilers generally. (You don’t seem to be using the most recent VS version and update? Is there a reason?) Which Boost libraries are being used? Is it using only headers, or does it use pre-built (or built by you) libraries? Are you completely sure that it isn’t a debug build? (Even if you think that you told it to optimize?) HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Hi, Glen, I can only run /MD under configuration setting on Release. However, the program is slower than /MDd when keeping the other setting the same. Is that the only way to turn off debug completely? I though /Od is to turn off the debug mode. Is that correct? Hi, Paul, This is the legency code developed in old version of boost and VC. We can access the original built executable(.exe) and source code of C++/CLI, but not old version of boost libriary. I also thought the new version is better than the old one. The libraries used in the code is shared_ptr. The program consists of three projects and one setup project. Those three projects have some kind of dependecy. It is expected to generate soluation in exe format and able to run independently on other platform. So it mostly developed by C++/CLI. So the only thing we changed here is new version of boost and VC2013. The original one was built on VC2010. Hope this information can helps. Connie Sent from Yahoo Mail. Get the app On Monday, July 3, 2017, 9:19:37 AM EDT, Paul A. Bristow via Boost-users <boost-users@lists.boost.org> wrote: From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Connie Zhang via Boost-users Sent: 02 July 2017 20:34 To: boost-users@lists.boost.org Cc: Connie Zhang Subject: [Boost-users] performance tuning on boost version 1_64_0 Hello, I recently upgrade boost version of a visual C++ program from an old version of 1_58_0 to 1_64_0. Compared to the original executable, the newly upgraded one runs very slow (more than 6 times longer) even I disable the debug mode and set the optimization to /ox in visual environment. The other difference between the old and the upgrade ones is the visual studio version. The old one is on 2010 and the new one 2013. Anyone has any idea for why it behaves like this? Which kind of performance tuning I need to look into? Thank you so much for your help! Well, it isn’t much help, but you will need to provide many more clues before anyone can help. It isn’t Boost wide or someone else would have noticed. In general, new compilers are producing better code, so there is no reason to suspect VS compilers generally. (You don’t seem to be using the most recent VS version and update? Is there a reason?) Which Boost libraries are being used? Is it using only headers, or does it use pre-built (or built by you) libraries? Are you completely sure that it isn’t a debug build? (Even if you think that you told it to optimize?) HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On 3 July 2017 at 18:05, Connie Zhang via Boost-users < boost-users@lists.boost.org> wrote:
Is that the only way to turn off debug completely? I though /Od is to turn off the debug mode. Is that correct?
No, /Od disables optimisation (the O stands for Optimisation (or rather Optimization)), use /O2 or /Ox instead. The NDEBUG preprocessor directive turns-off debugging. You will also need to link to the release CRT's, i.e. /MD or /MT. On the "Code Generation" options page, there are a number of things you can turn off (like smaller type check, exceptions, security check), which will affect the execution-speed of the code. You can also use the "Profile Guided Optimization" tools on the "General" tab, which will try and optimize the code paths that are actually taken the most in your app, as opposed to the optimiser guessing. But, most of all measure (tricky on Windows) and see what works best for your app. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798
Connie Zhang wrote:
I recently upgrade boost version of a visual C++ program from an old version of 1_58_0 to 1_64_0. Compared to the original executable, the newly upgraded one runs very slow (more than 6 times longer) even I disable the debug mode and set the optimization to /ox in visual environment.
The other difference between the old and the upgrade ones is the visual studio version. The old one is on 2010 and the new one 2013.
This problem sounds like one I had last year when upgrading a vendor library and from Visual Studio 2010 to 2012. I had persistent linker errors like this: error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' I was surprised (and actually angry) when I learned the cause: The Visual C++ 2012 compiler silently changes option /MT to /MTd if the preprocessor macro DEBUG or _DEBUG is set using /D. Some vendor libraries I needed were compiled only with /MT, so the link would always fail. It made no sense to me that a preprocessor macro definition should force a compiler option change like that. You did say that you disabled debugging, but… Are you defining either DEBUG or _DEBUG in the compiler command line? Try removing it if you do. If you use “#ifdef DEBUG” in your code, consider adding your own text to the macro name, such as “MY_PROJECT_DEBUG”. You can still debug your code without using /MTd by adding option /Zi or something similar to the compiler and linker commands. I hope this helps. |+| M a r k |+| Mark Stallard Engineering & Operations Application Development Business Application Services Global Business Services Information Technology stallard@raytheon.com<mailto:stallard@raytheon.com> Raytheon Company 880 Technology Park Drive Billerica, MA 01821 www.raytheon.com<http://www.raytheon.com/> This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive mail for the addressee), you should not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please so advise the sender by reply e-mail and delete this message. Thank you for your cooperation.
participants (4)
-
Connie Zhang -
degski -
Mark Stallard -
Paul A. Bristow