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

141–150 of 385 posts

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

#141

Post by dosshell »

jcranmer wrote: post #131
dosshell wrote: post #55

Earlier quoted context omitted.

> I can get away with a smaller sized float When talking about not assuming optimizations... 32bit float is slower than 64bit float on reasonable modern x86-64. The reason is that 32bit float is emulated by using 64bit. Of course if you have several floats you need to optimize against cache.

Um... no. This is 100% completely and totally wrong. x86-64 requires the hardware to support SSE2, which has native single-precision and double-precision instructions for floating-point (e.g., scalar multiply is MULSS and MULSD, respectively). Both the single precision and the double precision instructions will take the same time, except for DIVSS/DIVSD, where the 32-bit float version is slightly faster (about 2 cycl…

I agree with you. It should take the same time when thinking more about it. I remember learning this in ~2016 and I did performance test on Skylake which confirmed (Windows VS2015). I think I remember that i only tested with addsd/addss. Definitely not x87. But as always, if the result can not be reproduced... I stand corrected until then.

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

#143

Post by oivey »

tombert wrote: post #65
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…

But even that sort of depends right? Hardware is often pretty cheap in comparison to dev-time. I really depends on the project, what kind of servers you're using, the nature of the application etc, but I think a lot of the time it might be cheaper to just pay for 20x the servers than it would be to pay a human to go find a critical path. I'm not saying you completely throw caution to the wind, I'm just saying that th…

It almost certainly would require more than 20x servers because setting up horizontal scaling will have some sort of overhead. Not only that, there is the significant engineering effort to develop and maintain the code to scale.

If your problem can fit on one server, it can massively reduce engineering and infrastructure costs.

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

#145

Post by klyrs »

TylerE wrote: post #127
klyrs wrote: post #125

Earlier quoted context omitted.

> 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.

I don't use most modern langs! And especially if I'm doing work where performance is critical, I won't kneecap myself by using a language that I can't reasonably profile.

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

#150

Post by fransje26 »

I'm actually more worried about Clang being close to 100% slower than GCC on Linux. That doesn't seem right.

I am prepared to believe that there is some performance difference between the two, varying per case, but I would expect a few percent difference, not twice the run time..

Post reply on HN