Undefined Behavior in C++: A Performance Viewpoint - Fedor Pikus - CppNow 2022
Ғылым және технология
Slides: github.com/boostcon
CppNow Website: www.cppnow.org
CppNow Twitter: @CppNow
---
Undefined Behavior in C++: A Performance Viewpoint - Fedor Pikus - CppNow 2022
This talk is about You-Know-What, the thing in our programs we don’t mention by name.
What is this undefined behavior every C++ programmer has grown to fear? Just as importantly, what it isn’t? If it’s so scary, why is it allowed to exist in the language?
The aim of this talk is to approach the undefined behavior rationally: without fear but with due caution. We will learn why the standard allows undefined behavior in the first place, what actually happens when a program does something the standard calls “undefined,” and why it must be taken seriously even when the program “works as-is.” As this is a practical talk, we will have live demos of programs with undefined behavior and sometimes unexpected outcomes (if you are very lucky, you might see demons fly out of the speaker’s nose). Also, as this is a practical talk, we will learn how to detect undefined behavior in one’s programs, and how to take advantage of the undefined behavior to gain better performance.
---
Fedor Pikus
Fedor G Pikus is a Technical Fellow and head of the Advanced Projects Team in the Siemens Digital Industries Software. His earlier positions included a Senior Software Engineer at Google and a Chief Scientist at Mentor Graphics (acquired by Siemens Software). He joined Mentor Graphics in 1998 when he made a switch from academic research in computational physics to the software industry. His responsibilities as a Technical Fellow include planning the long-term technical direction of Calibre products, directing and training the engineers who work on these products, design, and architecture of the software, and research in new design and software technologies. Fedor has over 25 patents and over 100 papers and conference presentations on physics, EDA, software design, and C++ language.
---
Videos Filmed & Edited By Bash Films bashfilms.com/
KZread Channel Managed By Digital Medium Ltd: events.digital-medium.co.uk
#Boost #Cpp #CppNow
Пікірлер: 14
Thank you so much, this talk blew my mind on so many levels
@BoostCon
3 ай бұрын
Thank you for your appreciation of Fedor Pikus' presentation and it is a pleasure to hear how impactful you found it.
Fedor works hard in this one to keep the 'audience contributors' in check. But they are very determined to interrupt at every opportunity. It really spoils the flow of the talk. All in all, another great talk, thou. Just gotta silence the 'know-it-alls' in the audience!
The halting problem is unsolvable, not exponential complexity (NP).
I actually witnessed a bug in Samba project, where some packet parsing code was protecting against overflow, but used signed integer arithmetic instead of unsigned. And the code went something like "if (cur_offset + SOME_POSITIVE_CONSTANT < cur_offset) bail_out()" and the compiler would go "I can assume this condition is always false (because it's either false or UB, in which case I can do whatever I want), so I optimize-away the safety check". In one version of GCC it quietly optimized-away the check and then they added a diagnostic.
@flippert0
6 ай бұрын
Overflow with signed integers seems to be a frequently encountered (and cited) example, how C++ implementors (clang and gcc alike) do exploit UB with detrimental effect instead of warning about it.
One of my favorite examples of using UB for good is like auto * ptr = std::get_if( &my_variant ); return *ptr; The program can assume that the variant is not empty and that the index passed to get_if is the current alternative. So it will elide the branch inside get_if because it can never return null if return *ptr isn't UB
@johanneskalmbach5719
Жыл бұрын
Well, shouldn't you use std::get(my_variant) so close to the setting of the variant that the compiler also knows, that it can elide the branch? If you know the type, should it be in a variant at this point at all? But yes, to force an unchecked access to a variant, that possibly could be used.
Great talk. The graph example helped me understand WHY embrace UB. Also I didn’t know you could make GCC insert runtime checks for int overflow :0
1:05:10 How could `p` change? I get that the number that `p` points to could change, but how could the pointer itself change to something else? It's not a reference to a pointer, just a pointer, it's just a local variable in the function.
Regarding the speedup between clang11 and 13 at 38:51. Could it be because the compiler reordered the loop instructions so that lea is not on the critical path anymore ? That is the processor works on an other part of the loop while lea is cooking, thus erasing it's cost.
@LeDabe
2 жыл бұрын
On that note, I'd like to have more details, I could not reproduce the code gen shown in the slides using clang 11 (via godbolt)
42:08 "load and _extend_ address" ? Not "load effective address"?
Re slide 23 - if N is large, L is small, and i1 & i2 point close to the start of s, removing i1 Say N is 1024, L is 16, i2 = s + 16, and i1 = s + 24, with i1 [Its not just doing hundreds more increments and comparison, the CPU would have to fetch more data from RAM.]