3 ms·

Recommending counting new/delete operations in 2023? What about smart pointers? I would imagine that nowadays you should use new/delete only if you have to acc

Recommending counting new/delete operations in 2023? What about smart pointers? I would imagine that nowadays you should use new/delete only if you have to account for every CPU cycle to literally get every drop of performance...

tcbawo 3y ago
His larger point was having a focus on memory management. He mentioned new and delete in reference to ensuring they match up to avoid memory leaks. He also mentioned smart pointers. If you wanted every drop of CPU performance, you probably wouldn’t be doing lots of memory allocation. You would probably look at every operation in your critical path/loop and ask 1) do I have to do this at all? 2) do I have to do this right here/now? Cut out, defer, pre-allocate until you get as fast as you can.
cdevries 3y ago
I was surprised to see no talk of RAII when it came to memory management
flohofwoe 3y ago
He says "use smart pointers, if you have to" at around 1:33. But anyway, if performance matters at all you shouldn't heap-allocate in any hot code path in the first place. E.g. if memory management overhead is showing up in profiling, don't start looking for a faster general-purpose allocator, but instead rethink your memory management strategy ... and "I'll just put every C++ object behind a smart pointer" isn't really a memory management strategy ;)
- mr_00ff00 3y ago
  Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?
  - okamiueru 3y ago
    Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
    - shrimp_emoji 3y ago
      > if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"
  - flohofwoe 3y ago
    As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.

tcbawo 3y ago

His larger point was having a focus on memory management. He mentioned new and delete in reference to ensuring they match up to avoid memory leaks. He also mentioned smart pointers. If you wanted every drop of CPU performance, you probably wouldn’t be doing lots of memory allocation. You would probably look at every operation in your critical path/loop and ask 1) do I have to do this at all? 2) do I have to do this right here/now? Cut out, defer, pre-allocate until you get as fast as you can.

cdevries 3y ago

I was surprised to see no talk of RAII when it came to memory management

flohofwoe 3y ago

He says "use smart pointers, if you have to" at around 1:33. But anyway, if performance matters at all you shouldn't heap-allocate in any hot code path in the first place. E.g. if memory management overhead is showing up in profiling, don't start looking for a faster general-purpose allocator, but instead rethink your memory management strategy ... and "I'll just put every C++ object behind a smart pointer" isn't really a memory management strategy ;)

mr_00ff00 3y ago
Junior C++ dev here, but I feel like "use smart pointers, if you have to" is not the sentiment I usually hear. Isn’t it usually “use raw pointers, if you have to”?
- okamiueru 3y ago
  Yes. The main problem with the talk is that it's just too general. It gives good advice, but it's only really good advice if you understand what it's trying to say, at which point you don't need the advice. Kinda impossible to cover "what every programmer needs to know" in 5 minutes. So, "use smart points, if you have to", should have been: "if you need to allocate memory dynamically, use smart pointers".
  - shrimp_emoji 3y ago
    > if you need to allocate memory dynamically, use smart pointers Oooh. Okay. :p I was like, "As opposed to what, raw pointers?!"
- flohofwoe 3y ago
  As always the answer is "it depends". Smart pointers kind of 'encourage' that each C++ object lives in its own heap allocation, but this quickly becomes a problem if you deal with tens- or hundreds-of-thousands of small C++ objects that way, each in its own heap allocation, and on top a high number of those objects being frequently created and destroyed (for instance with std::make_unique or std::make_shared). I call this a "Java-style C++ code base". Technically this works and it's reasonably safe, because RAII takes care of memory management, just like GC takes care of memory management in Java. But the problem there is deeper: it's not smart pointers vs raw pointers, but that each small object lives in its own heap allocation. That's the typical scenario where you will see memory management becoming a performance problem (for at least two reasons: (1) heap allocation and especially deallocation isn't free, and (2) lots of cache misses when accessing objects that are spread more or less randomly over the address space). Ideally you'd group many similar objects into long-lived and compact arrays, process the data in those arrays in tight loops, minimize pointer indirections, and minimize allocations (ideally you'd only allocate those arrays once at program start, or when those arrays need to grow). Once you did all those things, memory managament suddenly becomes a non-problem (because you only have a handful of long-lived allocations to care about), and RAII becomes a lot less useful (because the 'objects' in those arrays will most likely just be C-style plain-old-data structs). This is basically the 'antithesis' to OOP. And before you know it you're back to writing C code, like it happened to me ;P TL;DR: there is no silver bullet for automatic memory management if performance matters.