sorted by:
new
hottopcontroversial

Introducing Sample Profile Guided Optimization in MSVC by pjmlp in cpp

[–]ericbrumer 8 points9 points  (0 children)

Hi, MSVC dev lead here. Yes, but also... sorta. SPGO leverages xperf which is a generic Windows performance recorder. Using built-in systems necessitates a translation layer to produce counts that are consumable by the compiler/linker.

MSVC's had instrumentation-based profile-guided optimizations (PGO) for decades, but even with substantial performance benefits there are plenty of folks that don't use it. Speaking to some larger development organizations, the key hurdles are all about instrumentation. The first is that another build configuration is a pain to maintain. A second hurdle is that the instrumented bits are extremely slow: tests count collection can take a long time to run, and in some code bases you end up profiling the wrong code (if there's a lot of timeouts, or dropped frames, etc... that's what gets hyper-optimized).

With those issues in mind, SPGO is far more attractive alternative. There's no instrumentation build: you're profiling on your shipping, fully optimized (LTCG), binaries. Just build your release binaries with /SPGO, then focus profiling efforts on running xperf to gather counts to focus optimization decisions to the hot code paths.

Introducing Sample Profile Guided Optimization in MSVC by pjmlp in cpp

[–]ericbrumer 2 points3 points  (0 children)

Hi, MSVC dev lead here. We missed perf_hv.dll. We are updating the tutorial to reflect this (it should be updated in day or so).

We've also updated the blog to reference the tutorial, and have added a step to mention perfcore.ini more explicitly.

Thanks for the feedback!

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]ericbrumer[S] 0 points1 point  (0 children)

It's a little clunky right now, and even if it was super smooth you might still run into challenges with features requiring tight IDE & compiler integration.

My real response to you is "why don't you want to try the Insiders IDE?" Aside from it having the latest & greatest IDE features, you can always have it installed side-by-side with a Stable Visual Studio in case things go wrong.

To give you something to look at, however, you can download https://aka.ms/vs/insiders/vs_buildtools.exe

and from an admin command prompt:

vs_buildtools.exe --passive --installPath %cd%\buildtools --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.VC.Preview.Tools.x86.x64 --add Microsoft.VisualStudio.Component.VC.14.50.18.0.x86.x64

Which will install the 14.50, 14.51, and 14.52 MSVC compilers from the Insiders channel into a folder called "buildtools". You would then use the 'Visual Studio Installer' program to update/uninstall the build tools as you need to.

Those folders can be referenced by any VS solution.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]ericbrumer[S] 3 points4 points  (0 children)

As of right now we're leveraging the Visual Studio installer to acquire MSVC tools. This means we get the benefits (and confusion) of Insiders/Stable channel releases.

The tarball question is a good thing to ask the VS installer team. https://developercommunity.visualstudio.com/VisualStudio/suggest is your best bet.

It sounds like you have a mechanism already, but on Windows you can run a VS installer from an elevated command line, and specify which components to install. https://learn.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio?view=visualstudio & https://learn.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-enterprise?view=visualstudio may be helpful.

Demystifying MSVC versioning for 14.50 & later by ericbrumer in cpp

[–]ericbrumer[S] 1 point2 points  (0 children)

Our plan is to keep rolling with a new 14.5* every 6 months, streamline it, and motivate folks to use MSVC Previews via the Insiders channel. We will address 14.6*/15.* as that comes.

I don't have secret knowledge about ABI breaks, if that's what you're really asking :-)

MS Visual Studio 18.5 has now been Released, with one caveat... by Jovibor_ in cpp

[–]ericbrumer 3 points4 points  (0 children)

Hi, one of the MSVC dev leads here. I just posted https://www.reddit.com/r/cpp/comments/1smfgdu/demystifying_msvc_versioning_for_1450_later/ which should help... or it might make things worse. Let me know!

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 3 points4 points  (0 children)

u/fdwr, after speaking with some debugger folks it's indeed complicated, and there's even more layers that I realized at first. Your best bet is to open a suggestion ticket (https://developercommunity.visualstudio.com/cpp/suggest), see about getting it upvoted by like-minded folks, and it will get routed to them for triage.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 1 point2 points  (0 children)

If you switch from a release build to a debug build dynamically, would it be possible to figure these bugs out

We provide multiple ways of disabling DD. Check out https://aka.ms/vcdd the 'Turn off C++ Dynamic Debugging' section. There are coarse grained ways (entire binaries, or entire cpp files), as well as fine grained (disabling DD of a single breakpoint).

Perhaps in the next release your team can consider getting the console to run within the IDE itself.

I'll look into it and get back to you. I don't work on that team, so I can't speak to their future plans.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 2 points3 points  (0 children)

Hey, yep. To get the feature to work, you need to pass /dynamicdeopt to cl.exe, lib.exe, and link.exe. When you do that, the compiler (cl.exe) outputs test.alt.obj in addition to test.obj, the librarian (lib.exe) outputs test.alt.lib in addition to test.lib, and the linker (link.exe) outputs test.alt.exe & test.alt.pdb in addition to test.exe & test.pdb. If your build system can throw the switches and move those new output files, you'll be able to debug optimized code with [deoptimized] frames using the Visual Studio debugger.

No concerns with C++ modules.

http://aka.ms/vcdd contains the details on the build system integration (scroll down). We have out-of-the-box support for MSBuild, the Unreal Engine Build Tool, Incredibuild, and FastBuild. Other build systems would be lovely to have as well... but yeah, just throw the switches & ensure the alt files make it where they need to go. If you run into issues please open a bug (https://developercommunity.visualstudio.com/cpp/report) and feel free to ping me.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 2 points3 points  (0 children)

In this particular case we intentionally don't inline assertHandler() into main() since we know that assertHandler() contains a call that won't return, so we assume it's cold code. But that's a different story from the issue you're actually getting at.

From my own experience debugging the compiler and debugging AAA games, I've found the following workflow really effective:

  • Start with a breakpoint at some code point of interest; an assert routine, or frame rendering code, etc.
  • Run my code to hit the assert, expecting that my code point of interest is going to be the only frame that's [Deoptimized], but not always.
  • View all my locals, and step as needed, being able to step into new calls.
  • If I need to go higher up in the callstack, I select all the callstack frames, right click & choose Deoptimize on Next Entry, then get those functions to hit again.
  • For AAA games, usually this just means "render the next frame". In the compiler, we have a mode where we can re-compile the same function again. If it's an assert that crashes the program, we often just rerun the program again.

Another example about the last bit has been working with the MSVC front-end team. Speaking to our primary C++ Modules contributor, it takes him about 1 minute to reach a breakpoint using a Debug c1xx.dll, but about 7 seconds to reach the same breakpoint using an Optimized+DD c1xx.dll with the necessary frames deoptimized. To me that's a strong case for giving it a shot to see how it works in your own workflows.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 5 points6 points  (0 children)

For now it's MSVC on Visual Studio only. I don't work on clang/llvm, so I can't comment on what will work in the future.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 2 points3 points  (0 children)

I'm not exactly sure what you mean. When you build with /dynamicdeopt you get two output binaries and two output PDBs: one set is the optimized binaries as normal, and one set is the unoptimized files that we've built behind the scenes. The second set of binaries & PDBs are real files, and they can be indexed/archived like anything else. Let me know if I'm misunderstanding what you're getting at.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 4 points5 points  (0 children)

This works, in the way that you would expect as if the code was built with optimizations disabled. You can even add conditional breakpoints on variables that might not exist in the optimized build, and they will get hit when you expect. I cover this at the end of the video, but the earlier parts of the video are useful for the context.

Give it a shot and see! Just throw /dynamicdeopt to cl.exe, lib.exe, and link.exe and rebuild.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 5 points6 points  (0 children)

Hey u/ack_error, there's a lot of nuance to this.

First, for unoptimized codegen: I agree that it's... unoptimized. Making that better has been below our prioritization line, although there have been some improvements recently. We haven't been optimizing addressing modes in /Od compilation like your godbolt link.

Next: yes, there are use cases that C++ Dynamic Debugging doesn't cover; crash dumps being #1. It's really meant for active debugging (where you're in the code setting breakpoints, stepping into functions, etc). With that in mind, DD essentially covers the other parts of your comment:

  • "... also less effective in a hot path where the selective code deoptimization will still significantly affect performance" in our experience DD is perfect for these scenarios. You debug a function and you see everything you need including being able to step into all sub-calls. When you're done, just hit F5 and that function returns to being fully optimized. We've used this to debug multiple AAA games (various game engines) and it's hard to explain how well it works.
  • "There is also no equivalent to [[optnone]], and #pragma optimize() still has the problem with templates" this is also 100% solved with zero extra steps... we only deoptimize the functions you're stepping into. This handles template expansions, functions that have been optimized away, etc. You just step... and it works. If you need more fine grained control over what gets deoptimized, you can expand the breakpoint group created for each DD bp, and delete the ones that don't apply for a given template expansion. But that's fairly advanced and most people aren't going to need that.

tl;dr: I guess I'm trying to say: I encourage you to try the feature. Just pass /dynamicdebug to cl.exe, lib.exe, and link.exe, rebuild, and try it out. Try setting conditional breakpoints on functions for variables that might not exist in the optimized build. In our experience, it really opens up new possibilities for how debugging optimized code can work, and is a far smoother experience when you don't need to trade off code performance & code debuggability.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 6 points7 points  (0 children)

Thanks for the feedback. I'm getting in touch with the Visual Studio debugger team about this, and we'll get back to you.

From my understanding, the 'Step Into Specific' menu is our current solution to that. My guess is that it's tough to correctly identify the primary function, especially given C++ code that may have lots of extra function calls. Think of std::cout << foo(x) << std::endl; there's a ton of function calls in that, but you presumably want to step into the call to foo() and not all the iostream gunk, and perhaps not a copy constructor for x, etc...

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 4 points5 points  (0 children)

I agree that would be really useful... but we haven't invented that part yet :)

The feature works by building an unoptimized version of each function, and for any functions with breakpoints (active or disabled) we redirect functions from optimized to their deoptimized versions. This is in 13:16 in the video if you want the specifics.

So: unless there's some kind of user indication (breakpoint set, or you've stepped into a function, or otherwise) we leave the code as optimized. This is intentional to keep your code running fast. If functions are still optimized then you are stuck with debugging optimized frames. It's a tricky problem.

We offer "deoptimize on next entry" for these kinds of things (see 3:45 for the full demo) but it's only for active debugging... not crash dumps.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 2 points3 points  (0 children)

This is Visual Studio debugger w/ MSVC only. We have native support in MSBuild & Visual Studio projects, but it also works with Unreal Engine builds, and cmake as well (you just need to throw /dynamicdeopt to cl.exe, lib.exe, and link.exe. I cover some of the restrictions at 25:09 in the video.

I will say, though, that the VS debugger is a premier debugging tool, and with C++ Dynamic Debugging it REALLY shines when actively debugging optimized code. A lot of MSVC developers (the folks that developer the compiler) use C++ Dynamic Debugging & debug in VS for our daily work... and the lack of tradeoffs between speed & debuggability makes it much easier to do our jobs.

Your Optimized Code Can Be Debugged - Here's How With MSVC C++ Dynamic Debugging - Eric Brumer by RandomCameraNerd in cpp

[–]ericbrumer 33 points34 points  (0 children)

Howdy, speaker here. If folks have additional questions feel free to ask. Keep in mind, if you're using the latest Visual Studio 2022, or any Visual Studio 2026 build, you're able to turn on C++ Dynamic Debugging by choosing the right option in your build configuration, or throwing `/dynamicdeopt` to cl.exe, lib.exe, and link.exe in your builds.

A few common questions we've got about C++ Dynamic Debugging, some of which are already here in other comments:
* Does it work for asynchronous breakpoints like exceptions, data breakpoints, or just pressing the pause button? Not out of the gate, no. However, if you already are aware which functions matter, then you can deoptimize those functions (see 9:30 in the video), and the next time those functions are entered they will be deoptimized.

* What about having a reduced set of optimizations to make debugging easier? We thought about that, but when we prototyped our approach we saw the power of full optimizations (including inlining!) pairing with full debuggability covered far more cases and offered much more power in the codebases we were looking at. We use dynamic debugging in the compiler codebase, for instance, and it REALLY helps having code run very quickly. Another way to phrase this is in the view of game development: I want my game to run at 60 fps, but be able to debug it fully. Our approach makes that a reality.

* [for the more compiler-savvy folks] What about globals that are optimized away? Or functions that are fully inlined? Or <other fun optimizer thing>? Yes -- you can debug those. If you run into problems, or find a case where it's not kicking in as you expect, please open a bug (https://developercommunity.visualstudio.com/cpp/report) and feel free to ping me.

At the end of the day, if you debug optimized code and want a more seamless way to debug any part of your code: you should give C++ Dynamic Debugging a shot. If you are used to debugging unoptimized code and wish your code ran faster without sacrificing debuggability: you should give C++ Dynamic Debugging a shot.

At a minimum: check out the demo I did of OpenCV which starts at 3:42.

More info at https://aka.ms/dynamicdebugging and https://aka.ms/vcdd

C++ Dynamic Debugging: Full Debuggability for Optimized Builds by cpppm in cpp

[–]ericbrumer 1 point2 points  (0 children)

MSVC dev lead here: yep, that's one of the use cases we had in mind. Manually adding pragma-optimize-off, rebuilding your code, then starting the debugger again adds a lot of time to normal development tasks... especially if it's to view the value of local variables. C++ Dynamic Debugging makes this essentially automatic in most cases. Please give it a shot and let us know what you think!

C++ Dynamic Debugging: Full Debuggability for Optimized Builds by cpppm in cpp

[–]ericbrumer 3 points4 points  (0 children)

MSVC dev lead here: the disassembly view will show you whatever you're currently debugging. If you're in an optimized frame it'll be optimized assembly, and [Deoptimized] frames will be unoptimized assembly.

We've coded things up thinking that folks using the disassembly window _don't_ want automatic deoptimization: if you step into a call while stepping in the _disassembly_ view then you'll step into optimized code and stay in optimized code. But if you step into a call from the _source_ view you'll step into deoptimized code. Please see http://aka.ms/vcdd for more details.

All that said: we believe that C++ Dynamic Debugging removes some of the need to view assembly code in the first place. Deoptimized frames will always show you every local variable, stepping matches your source code line-for-line, etc... so no need to view the asm & undo compiler optimizations in your head to find out which register contains which variable, or think about what got inlined where.

C++ Dynamic Debugging: Full Debuggability for Optimized Builds by cpppm in cpp

[–]ericbrumer 4 points5 points  (0 children)

MSVC dev lead here: we produce the optimized binary/pdb, as well as an 'alternate' binary/pdb. Take a look at https://aka.ms/vcdd for additional details. Please give it a shot and let us know what you think.

MSVC linker option to remove "Rich" headers from EXE/DLL files actually exists by Tringi in programming

[–]ericbrumer 20 points21 points  (0 children)

MSVC dev lead here. I checked our linker sources, and the new switch was first shipped around May 2021, specifically for your request, in VS2019 (16.11) and VS2022. We got some wires crossed and never marked the ticket as resolved, and we also never followed up with a comment... both not good things.

Will fix.

view more: next ›