CppCon 2018: Alan Talbot “Moving Faster: Everyday efficiency in modern C++”

—
—
There seems to be a widely held belief among programmers today that efficiency no longer matters in most situations because processors are so fast and numerous and memory is so large. But from a user’s perspective computers are often slower today than they were 30 years ago despite the enormous increase in measured performance of the hardware. How can this be? If this is true, what are we doing wrong and what can we do about it? Is efficiency an everyday concern for working programmers, or is it only needed for special cases written by specialists?

In this talk we will explore these questions and consider the proposition that, contrary to popular belief, performance almost always matters and pervasive attention to efficiency is essential to ensure good performance. We will examine the efficiency tools modern C++ has to offer and discuss techniques for writing efficient code in an elegant, expressive and natural way. Topics will include tuning vs. optimizing, value semantics vs. reference semantics, unions and variants, move semantics, forwarding, container choice, in-place construction, and container node handling.
—
Alan Talbot, LTK Engineering Services
Manager - Software Engineering

Alan Talbot started programming in 1972, in BASIC on a DEC PDP-8. He began his professional programming career in 1979 and started using C++ in 1989. For 20 years he was a pioneer in music typography software, then spent 8 years writing digital mapping software, and has spent the last 9 years writing railroad simulation software. He has been a member of the C++ Standards Committee since 2005, and most of his Committee work has focused on improvements in efficiency. His contributions include container emplace, extract and merge of associative container nodes, and the emancipation of unions.
—

*-----*
*-----*

[mmbrshp]

THANK YOU! I'm only three minutes into the talk and I love the real-world example you used to demonstrate the importance of programming efficiently, despite hardware improvements. I hope talks like these help improve software standards.

[maxmustermann]

In the words of mike akton: People thinking the Performance doesn't matter are the reason I need to wait 15 seconds for Word to load

[GeorgeTsiros]

"avoid cache misses" shouldn't this be as common as "avoid division by zero" at this point?

[gast]

I agree that the STL could offer more specialized containers like Boost's dynamic_bitset (with sbo), small_vector and flat_map. The use case is that most of the time one has to deal with a small set of elements but occasionally you go overboard. Using vectors with O(n) lookup can give you the same problems then.

[isodoubIet]

"Sadly we don't have an SSO vector"

Yeah we do, it's called basic_string.

[yangwei]

perfect speech, especially how to correctly use emplace_back().
I am trying to explain two questions from STL src code:
1: "can't use aggregate{} with emplace_back()", because at push_back({...}), the parameter type is determined from the container itself, container::value_type, emplace_back({...}) from independent.
2: "emplace_back("hello") faster than push_back("hello")", emmm a little subtle, i guess delay move entity.

[plasteredparrot]

slight issue with the advice to ever pass a std::shared_ptr by const ref.... if you're passing a pointer into something that _doesn't_ take ownership, isn't the correct semantics just to .get() on the shared_ptr and pass in the raw ptr?

[douggale]

I can beat 90 wpm. Glad to hear the correction during questions, 120+ would be an impressive number.

[mina]

emplace_back returns void though so in the example you'd have to emplace_back and then get reference to the object via back method.

[monty]

Was it Errichto who asked the comparison of unordered map and unordered set ?

[georganatoly]

Member order didn't occur to me. I assumed the compiler optimized for it. In some contexts it may, but not the few I've checked, ouch.

[MrAbrazildo]

- 11:00, the last issue is not an actual problem: you can code an array as a limited capacity vector, pushing and popping elements to/from it.
- 12:40, what is this member order? The order I declare the variables, inside a f()?
- 52:00, I saw std::vector faster than std::array too! The point was that, in my project, there was a main container, which should be a std::vector (and thus was never changed), and many copies were made from parts of it to other containers, which could be std::vector or std::array, the targets for measurement.

[GeorgeTsiros]

"What are we doing wrong?". too many programmers, too many programs, too much code.

[masheroz]

"avoid cache misses" with no guidance on how to do it.

[VivekYadav-dsoz]

Rust: _"Look what they need to do to emulate a fraction of my power!"_ XD

[NicolayGiraldo]

What are we doing wrong?
Quoting Knuth incorrectly.
The full quote ends with : "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Don't ignore that critical 3%!