Yeah, it comes down to modeling assumptions on how many different types of exceptions can be thrown, how many actually are thrown, and the shape of the control flow graph of a program at runtime.

You can find one style outperforms the other based on the circumstances of the program, and programmers worried about optimization may someday be able to choose between approaches to meet their performance goals instead of pretending that tables are inherently slow and return codes that they won't even fully implement are inherently fast.

My point was simply that you can't just say "oh but exceptions are not zero-cost" without actually comparing to the alternative of laboriously carting return codes all through the call graph, as done in the research you show here and as also done by Khalil Estell elsewhere for ARM embedded.

A specific presentation I'd point to is Khalil Estell's presentation on reducing exception code size on embedded platforms at https://www.youtube.com/watch?v=bY2FlayomlE

But honestly you'd get vast majority of the benefit just by skimming through the slides at https://github.com/CppCon/CppCon2024/blob/main/Presentations...

With a couple of symbols you define yourself a lot of the associated g++ code size is sharply reduced while still allowing exceptions to work. (Slide 60 on)

> I think I read something about this but couldn't figure out how to use it because the documentation is horrible.

Fair enough.

> So, I found it easier to implement my own, and as it turns out, there are a few HORRIBLE bugs in the LLVM assembler (from cross reference testing)

Interesting claim, do you have any examples?

> I don't have enough time to watch these kinds of presentations.

Then let me pick and share some of my favorites that I found enlightening, and summarize with some information that I found useful.

By far, the most useful one is Khalil Estell's presentation last year [0]. It's a fairly face paced but relatively deep dive into exception mechanics. At the end, he advocates for a new tool that would audit a program to determine what exceptions could be thrown. I think that's a flipping fantastic idea for a tool. Unfortunately I haven't seen any progress toward it -- if someone here knows where his tool is, or a similar tool, please reply! I did send him an email a few months ago inquiring about it, but haven't received a reply. Nonetheless, the whole presentation was excellent in my opinion. I did see that he had another related presentation at ACCU this year [4] with a topic of "C++ Exceptions are Code Compression" (which I totally can believe -- I've seen it myself in binary sizes), but I haven't seen his presentation yet. I'll watch it later today.

Just about anything from Herb Sutter is good. I don't like that he works for Microsoft, but he does great stuff for C++, including the old Guru of the Week series [1]. In particular, his 2019 presentation [2] describes different error handling techniques, some difficulties and pitfalls in combining libraries with different error handling techniques, and leads up to explaining why std::expected came about. He does pontificate a lot though, so the presentation is fairly high level and slow paced.

Dave Watson's 2017 presentation [3] dives into a few different implementations of stack unwinding. It's good to understand how different compilers implement exceptions with low- or zero-cost overhead and what that "overhead" is really measuring.

So, there's about a half of a day of presentations to watch here. I hope that's not too much for you.

[0]: https://www.youtube.com/watch?v=bY2FlayomlE

[1]: https://herbsutter.com/gotw/

[2]: https://www.youtube.com/watch?v=ARYP83yNAWk

[3]: https://www.youtube.com/watch?v=_Ivd3qzgT7U

[4]: https://www.youtube.com/watch?v=LorcxyJ9zr4

Windows uses memory mapped IO for loading all executable processes because it allows you to start executing a process after loading a few pages even if the exe is megabytes. You can use the same to reduce latency for starting to assemble data before the rest of the file loads, the rest can be loaded using more efficienct asynchronous mechanisms. Using for output also means your process doesnt waits on flushes that is also async. And in memory constrained environments the OS doesn’t have to write your data to swap, it can just reload it from the meeting mapped file.

I appreciate that hitting sm_70 through sm_120 in one call isn't the same as hitting RISC-V in one call, but I do a lot of builds just for sm_120 which is closer to a fair comparison.

It's imperfect, but I take any excuse to point out how bad monopolies are for customers. All you have to do is build the driver to see that "low priority" is a pretty broad term on the allegedly elite trillion dollar toolchain.

I'm not saying CUDA is unimpressive, its a very, very, very hard problem. But if they were in an uncorrupted market ptxas would be fast instead of devastating znver5 workstations with 6400MT DDR5.

Ditto. Perfect hashing strings smaller than 8 bytes has been the fastest lookup method in my experience.