terrymah

6 ms·

1.
C++ Dynamic Debugging: Full Debuggability for Optimized Builds(devblogs.microsoft.com)
2 points by terrymah 1y ago|0 comments
2.
by terrymah 2y ago
Until yesterday I thought I was the only person in the world who thought the designed behavior was undesirable, though
3.
by terrymah 2y ago
Things are much better in 2024 in MSVC than they were in 2014. The overhead today is mostly the additional metadata associated with tracking the state, and most of the inline compatibilities were worked through (with a ton of work by the co
4.
by terrymah 2y ago
We had a UB version of noexcept for a very, very long time. __declspec(nothrow), the throw() function specifier, etc.
5.
by terrymah 2y ago
No, calling throw in a noexcept function is a defined behavior (call std::terminate), and that behavior is not a diagnostic I think maybe WG21 was concerned a compiler engineer would be clever if throwing in noexcept were UB, for example an
6.
by terrymah 2y ago
Determining if a function throws is a pretty basic bit of information collected in bottom up codegen (or during pre pass of a whole program optimization) and in no sense NP hard. Compilers have been doing it for decades and it’s useful Noex
7.
by terrymah 2y ago
I think WG21 has been violently against adding additional UB to the language, because of some hacker news articles a decade ago about people being alarmed at null pointer checks being elided or things happening that didn’t match their expec
8.
by terrymah 2y ago
Everyone keeps scanning over the inlining issues, which I think are much larger “Zero overhead” refers to the actual functions code gen; there are still tables and stuff that have to be updated Our implementation of noexcept for the single
9.
by terrymah 2y ago
Well, yeah, things can be related to many things, but throwing extern "C"s was one of the motivations as I recall for 'r'. r is about a compiler optimization where we elide the runtime terminate check if we can staticall
10.
by terrymah 2y ago
Nah that was mostly about extern "C" functions which technically can't throw (so the noexcept runtime stuff would be optimized out) but in practice there is a ton of code marked extern "C" which throws
11.
by terrymah 2y ago
Dude I am going to blow your mind
12.
by terrymah 2y ago
Oh, cool! I googled myself and someone actually archived the slides from the talk I gave. I think it holds up pretty well today https://github.com/TriangleCppDevelopersGroup/TerryMahaffeyC... *edit except the stuff abo
13.
by terrymah 2y ago
No, we compile in bottom up order, starting with leaf functions, and collecting information about functions as we go. So "not throwing" sort of trickles up when possible to a certain degree. In LTCG (MSVC)/O3 (GCC/Clang)
14.
by terrymah 2y ago
It absolutely does, and even better, the compiler deduced "this function doesn't throw" doesn't come with the overhead of implementing noexcept proper
15.
by terrymah 2y ago
You can't just look at the codegen of the function itself, you also have to consider the metadata, and the overhead of processing any metadata Specifically here (as I said in other comments) where it goes from complicated/quality
16.
by terrymah 2y ago
In MSVC we've also pretty heavily optimized the whole function case such that we no longer have a literal try/catch block around it (I think there is a single bit in our per function unwind info that the unwinder checks and kills
17.
by terrymah 2y ago
Oh man, don't get me started. This was a point in a talk I gave years ago called "Please Please Help the Compiler" (what I thought was a clever cut at the conventional wisdom at the time of "Don't Try to Help the Co
18.
by terrymah 6y ago
I, too, came for the procedurally generated Doom levels and left disappointed
19.
by terrymah 7y ago
From direct effects, maybe. But no one is immune from the second order effects. Once our customers start going out of business because they are directly exposed, they can't buy our software anymore.
20.
by terrymah 10y ago
It was a joint project, with ms eventually pulling out to work on NT
21.
by terrymah 10y ago
You sort of have to, since everyone else is doing it.
22.
by terrymah 10y ago
This is both C and C++ - they share a common backend (c2.dll) where this work was done. They have different front ends (c1.dll / c1xx.dll).
23.
by terrymah 13y ago
Hmph. You forgot the part where Bubba's friends are watching him drink beer and eat Hungry-Mans, and if they want some, they can force Bubba to throw out all his food and pour all his beer down the drain, and everyone has to go back to
24.
by terrymah 13y ago
I've heard that modern Intel processors have 100 < x < 200 physical registers. I'm not sure they actually document the exact number.
25.
by terrymah 13y ago
It's complicated, but modern processors actually do have many more registers than you can name in the instructions. They use things like "register renaming" to avoid false conflicts between instructions. Registers that you na
26.
by terrymah 13y ago
FWIW, "WOW" stands for "Windows on Windows"
27.
by terrymah 13y ago
> PGO compiles only 0.4% of our application for speed, and our response times are about 20 usecs slower with it on This is a complex issue, but consider abandoning PGO and just compiling for for speed then. PGO doesn't help in each and
28.
by terrymah 13y ago
Following the ABI is only an issue at module boundaries. If you control every callsite of a function, you can invent whatever calling convention you want.
29.
by terrymah 13y ago
Visual C++ Team blog
30.
by terrymah 13y ago
I'm actually about to sit down and write a blog post about VS compiler memory issues, and I had a long talk with the Firefox guys a few weeks ago about this issue. It's not all their fault.

More ›