Throwing Tools at Ranges - Tina Ulbrich - Meeting C++ 2023
Ғылым және технология
Throwing Tools at Ranges - Tina Ulbrich - Meeting C++ 2023
Slides: slides.meetingcpp.com
Survey: survey.meetingcpp.com
When talking about ranges I always get the same questions "but how about compile time? how about runtime?" because usually abstractions give us the impression that they might slow down either compile time or run time or both. The advantages of ranges lie in the ease of use, composability, and readability but many people cannot sacrifice run time performance for it. So that sparked the idea of using different tools to do a deep dive into the ranges code and answer these questions as objectively as possible. In this talk I will talk about the tools I used on both Windows and Linux and the insights they give into ranges code compared to non-ranges code. I will concentrate on runtime performance and memory usage. The analysis features one example written in: C-style C++, C++17 and C++23/ranges. The comparison of these styles will give you an impression which effects modernization of your code has on performance.
Пікірлер: 4
10:20, it'd probably be faster with pointers, instead of indexes. 10:28, and if that 'out' was wrapped in a class for automatic destruction, would it had a cost?
@Yulivee01
4 ай бұрын
What would make it faster using pointers? The data is continuous in memory and I am iterating from start to end. I don't see why pointers would be faster. The whole reason to use C-style C++ in this example is to avoid any classes, templates, and so on. Also in this case I also wouldn't expect a speedup. The dtor of a vector also just calls delete. There are different reasons to use classes. Speed is typically not one of them.
The comparison is nice but... why not use more suited data-types, containers and algorithms? A simple switch to valarray might already give a nice speedup. The benefit of ranges (well more so for the original library than the standard-library implementation) is easy of use and readability. The extreme performance-traps, hard to read errors and long compiletimes are what you have to accept to have it easier to write code. And "C-style" C++ is just bad C++. It uses neither the utilities of C++ nor C. The high miss-rate should have shown that there is a big problem.
@Yulivee01
3 ай бұрын
As I said, I only did one round of optimization. If there is more speed needed, the code can be optimised more. But this wasn't the goal of the talk. There are a lot of optimisation talks out there. I just wanted to compare the different "styles". How would you have changed the C-style example? My goal was to not use any standard library. I could have wrapped the dynamic arrays in a class, but I don't think it would have changed the output.