Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Performance Impact of C++'s `final` Keyword

16bpp.net

Post reply on HN
Print view View original

121–130 of 385 posts

Re: The Performance Impact of C++'s `final` Keyword

#121

Post by [deleted] »

tombert wrote: post #113
apantel wrote: post #109

Earlier quoted context omitted.

I think it depends on what you’re building and who’s building it. We’re all benefitting from the fact that the designers of NGINX made performance a priority. We like using things that were designed to be performant. We like high-FPS games. We like fast internet. I personally don’t like the idea of throwing compute at a slow solution. I like when the extra effort has been put into something. The good feeling I get fr…

Sure, though I've mentioned a few times in this thread now that the thing that bothers me more than CPU optimizations is not taking into account latency, particularly when hitting the network, and I think focusing on that will generally pay higher dividends than trying to optimize for processing. CPUs are ridiculously fast now, and compilers are really really good now too. I'm not going to say that processing speed i…

[deleted]

Re: The Performance Impact of C++'s `final` Keyword

#122

Post by apantel »

tombert wrote: post #113
apantel wrote: post #109

Earlier quoted context omitted.

I think it depends on what you’re building and who’s building it. We’re all benefitting from the fact that the designers of NGINX made performance a priority. We like using things that were designed to be performant. We like high-FPS games. We like fast internet. I personally don’t like the idea of throwing compute at a slow solution. I like when the extra effort has been put into something. The good feeling I get fr…

Sure, though I've mentioned a few times in this thread now that the thing that bothers me more than CPU optimizations is not taking into account latency, particularly when hitting the network, and I think focusing on that will generally pay higher dividends than trying to optimize for processing. CPUs are ridiculously fast now, and compilers are really really good now too. I'm not going to say that processing speed i…

I absolutely agree that latency is the real thing to optimize for. In my case, I only leave the application to access the db, and my applications tend not to be write-heavy. So in my case latency-per-request == how much work the computer has to do, which is constrained to one core because the overhead of parallelizing any part of the pipeline is greater than the work required. See, in that sense, we’re already close to the performance ceiling for per-request processing because clock speeds aren’t going up. You can’t make the processing of a given request faster by throwing more hardware at it. You can only make it faster by creating less work for the hardware to do.

(Ironically, HN is buckling under load right now, or some other issue.)

Re: The Performance Impact of C++'s `final` Keyword

#123

Post by jandrewrogers »

pineapple_sauce wrote: post #10

What should be evaluated is removing indirection and tightly packing your data. I'm sure you'll gain a better performance improvement. virtual calls and shared_ptr are littered in the codebase. In this way: you can avoid the need for the `final` keyword and do the optimization the keyword enables (de-virtualize calls). >Yes, it is very hacky and I am disgusted by this myself. I would never do this in an actual produc…

In modern C++, macros are a viewed as a code smell because they are strictly worse than alternatives in almost all situations. It is a cultural norm; it is a bit like using "unsafe" in Rust if not strictly required for some trivial case. The C++ language has made a concerted effort to eliminate virtually all use cases for macros since C++11 and replace them with type-safe first-class features in the language. It is a bit of a legacy thing at this point, there are large modern C++ codebases with no macros at all, not even for things like logging. While macros aren't going away, especially in older code, the cultural norm in modern C++ has tended toward macros being a legacy foot-gun and best avoided if at all possible.

The main remaining use case for the old C macro facility I still see in new code is to support conditional compilation of architecture-specific code e.g. ARM vs x86 assembly routines or intrinsics.

Re: The Performance Impact of C++'s `final` Keyword

#124

Post by magnat »

> I created a "large test suite" to be more intensive. On my dev machine it needed to run for 8 hours.

During such long and compute-intensive tests, how are thermal considerations mitigated? Not saying that this was case here, but I can see how after saturating all cores for 8 hours, the whole PC might get hot to the point CPU starts throttling, so when you reboot to next OS or start another batch, overall performance could be a bit lower.

Re: The Performance Impact of C++'s `final` Keyword

#125

Post by klyrs »

tombert wrote: post #26

I don't do much C++, but I have definitely found that engineers will just assert that something is "faster" without any evidence to back that up. Quick example, I got in an argument with someone a few years ago that claimed in C# that a `switch` was better than an `if(x==1) elseif(x==2)...` because switch was "faster" and rejected my PR. I mentioned that that doesn't appear to be true, we went back and forth until I…

> A large part of becoming a decent engineer [2] for me was learning to stop trusting what professors taught me in college

When I was taught about performance, it was all about benchmarking and profiling. I never needed to trust what my professors taught, because they taught me to dig in and find the truth for myself. This was taught alongside the big-O stuff, with several examples where "fast" algorithms are slower on small inputs.

Re: The Performance Impact of C++'s `final` Keyword

#126

Post by cogman10 »

tombert wrote: post #119
cogman10 wrote: post #101

Earlier quoted context omitted.

A complier will definitely try this, but it's important to note that if/else blocks tell the compiler that "you will run these evaluations in order". Now, if the compiler can detect that the evaluations have no side effects (which, in this simple example with just integer checks, is fairly likely) then yeah I can see a jump table getting shoved in as an optimization. However, the moment you add a side effect or somet…

I agree with what you said but in this particular case, it actually was a direct integer equality check, there was zero risk of hitting side effects and that was plainly obvious to me, the checker, and compiler.

And to your original comment, I think the reviewer was wrong to reject the PR over that. Performance has to be measured before you can use it to reject (or create...) a PR. If someone hasn't done that then unless it's something obvious like "You are making a ton of tiny heap allocations in a tight loop" then I think nitpicking these sorts of things is just wrong.

Re: The Performance Impact of C++'s `final` Keyword

#127

Post by TylerE »

klyrs wrote: post #125
tombert wrote: post #26

I don't do much C++, but I have definitely found that engineers will just assert that something is "faster" without any evidence to back that up. Quick example, I got in an argument with someone a few years ago that claimed in C# that a `switch` was better than an `if(x==1) elseif(x==2)...` because switch was "faster" and rejected my PR. I mentioned that that doesn't appear to be true, we went back and forth until I…

> A large part of becoming a decent engineer [2] for me was learning to stop trusting what professors taught me in college When I was taught about performance, it was all about benchmarking and profiling. I never needed to trust what my professors taught, because they taught me to dig in and find the truth for myself. This was taught alongside the big-O stuff, with several examples where "fast" algorithms are slower…

How do you even get meaningful profiling out of most modern langs? It seems the vast majority of time and calls gets spent inside tiny anonymous functions, GC allocations, and stuff like that.

Re: The Performance Impact of C++'s `final` Keyword

#128

Post by lastgeniusua »

magnat wrote: post #124

> I created a "large test suite" to be more intensive. On my dev machine it needed to run for 8 hours. During such long and compute-intensive tests, how are thermal considerations mitigated? Not saying that this was case here, but I can see how after saturating all cores for 8 hours, the whole PC might get hot to the point CPU starts throttling, so when you reboot to next OS or start another batch, overall performanc…

having recently done similar day-and-night long suites of benchmarks (on a laptop in heat dissipation conditions worse than on any decent desktop), I've found that there is no correlation between the order the benchmarks are run in and their performance (or energy consumption!). i would therefore assume that a non-overclocked processor would not exhibit the patterns you are thinking of here

Re: The Performance Impact of C++'s `final` Keyword

#130

Post by apantel »

neonsunset wrote: post #88
apantel wrote: post #51

Earlier quoted context omitted.

The counter-argument to this is if you are building something that is in the critical path of an application (for example, parsing HTTP in a web server), you need to be performance-minded from the beginning because design decisions lead to design decisions. If you are building something in the critical path of the application, the best thing to do is build it from the ground up measuring the performance of what you h…

Please accept a high five from a fellow "it does so little work it must have sub-millisecond request latency" aficionado (though I must admit I'm guilty of abusing memory caches to achieve this).

Caches, precomputed values, lookup tables — it’s all good as long as it’s well-organized and maintainable.
Post reply on HN