Lightning Talk: Is Polymorphism in C++ Really That Bad? - Paul Tsouchlos - CppCon 2023
Вставка
- Опубліковано 5 тра 2024
- cppcon.org/
---
Lightning Talk: Is Polymorphism in C++ Really That Bad? - Paul Tsouchlos - CppCon 2023
github.com/CppCon/CppCon2023
Case study of how we used polymorphism at my work to solve a problem with hardware control. I'll present what we did wrong at first, how we corrected it and the performance we can achieve for our particular application. I'll also briefly mention ways we can further improve our design.
---
Paul Tsouchlos
I'm a C++ dev that enjoys coding outside work and writing open source libraries and applications. I've worked with C++ for ~8 years and enjoy implementing algorithms and have a great interest in AI and high performance computing.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp - Наука та технологія
Very concise and straight to the point, love it!
Im not sure about the "right" answer. Whatever that looks like. I do believe inheritance can get in the way of code reuse. I guess type erasure (external polymorphism) solves this. Whats you guy's approach to interface abstraction?
Interesting talk. I'm very curious if he's just mentioning the overhead of polymorphism because it's generally assumed, or if they were actually able to measure it. Because after watching ua-cam.com/video/i5MAXAxp_Tw/v-deo.html , I'm more weary of just assuming virtual functions will be slower.
A lot of the data oriented design people who swear up and down how bad C++, abstraction, and object-oriented programming are, would probably end up implementing this with a struct that takes function pointers, and a static array of function pointers to switch between behaviors for different devices. You see this a lot in C code, and it's pretty clever. Unfortunately for them, it incurs the *exact same* "runtime overhead" as polymorphism does (in fact this is how polymorphism is implemented under the hood), except with none of the benefits. People always compare the "overhead" of an abstraction vs having code that does nothing, and never the overhead of the abstraction vs being forced to re-implement the same patterns without abstractions, the compiler, or the type system to help you.
The idea behind data oriented design (or, a better name for it would be "performance oriented design") is to batch similar things together and process them in a way that is SIMD friendly and doesn't waste memory bandwidth by fully utilizing loaded cache lines.
It doesn't have to do much with abstraction or polymorphism other than the fact that c++ compilers will NEVER rearrange or batch your data in classes to enable that kind of processing.
Other thing to be aware of is that excessive abstraction of things makes finding strategies for performance design very hard. Often, one needs to dismantle lots of abstractions to get to the essence of what can be bundled together and what can't.
Yes and c++ itself sucks now
The Hardware/Communication/Robots example was too specific, thus hard to follow
Nevertheless, I liked the talk! There are too few people telling you "it's fine to use the naive approach, unless you know you need something different "
Without numbers this talk was beyond useless.
The conclusion was something we already knew and what you already stated in your intro "polymorphism has some overhead". Ok?? How much overhead? Did using "final" help? What was the point of this talk exactly?