Live data from Hacker News

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

16bpp.net

381–385 of 385 posts

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

#381
post #376

Earlier quoted context omitted.

> The second is that I think the saying 'premature optimization is the root of all evil' is the root of all evil. The greater evil is putting a one-sentence quote out of context: """ There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have…

Indeed, but I think even that advice, with context, is pretty debatable. Obviously one should prioritize critical sections, but completely ignoring those "small efficiencies" is certainly a big part of how we got to where we are today in software performance. A 10% jump in performance is huge; whether that comes from a single 10% jump, or a hundred 0.1% jumps - it's exactly the same! So referencing something in parti…

That's not how compounding percentages works.

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

#382

As an LLVM developer, I really wish the author filed a bug report and waited for some analysis BEFORE publishing an article (that may never get amended) that recommends not using this keyword with clang for performance reasons. I suspect there's just a bug in clang.

Is there any logical reason why Clang is 50% slower than GCC on Ubuntu?

Hi, I had a look today because it was bugging me and no one had investigated it, so I created an issue[1] with an explanation.

But it basically boils down to uniform_real_distribution having a bunch of uninlined calls to 'logl' when compiled with Clang.

Otherwise, Clang beats GCC at least on the configuration I tested.

(I am the author of the issue)

[1] https://gitlab.com/define-private-public/PSRayTracing/-/issu...

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

#383
post #382

Earlier quoted context omitted.

Is there any logical reason why Clang is 50% slower than GCC on Ubuntu?

Hi, I had a look today because it was bugging me and no one had investigated it, so I created an issue[1] with an explanation. But it basically boils down to uniform_real_distribution having a bunch of uninlined calls to 'logl' when compiled with Clang. Otherwise, Clang beats GCC at least on the configuration I tested. (I am the author of the issue) [1] https://gitlab.com/define-private-public/PSRayTracing/-/issu...

Oh, very nice find!

Coincidentally, I happened to be playing around yesterday with a small performance test case using uniform_real_distribution, and for some strange reason Clang was 6x slower than GCC.

I put it down to some weird clang bug on my LTS version of Ubuntu. As my installed version was clang-14, I decided it possibly had been noticed and fixed a long time ago.

After reading your message I replaced uniform_real_distribution by uniform_int_distribution, and lo and behold, Clang was indeed faster than GCC, as expected.

Thank you for coming back to me with your findings.

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

#384

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

For posterity, this is due to a Clang bug.

See [1] for more information.

[1] https://news.ycombinator.com/item?id=40156196

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

#385

Earlier quoted context omitted.

In general purpose scenarios, particularly in codebases which have high amount of abstractions, use ASP.NET Core and EF Core, parse and de/serialize text with the use of JSON, Regex and other options, have network and file IO, and are deployed on many-core hosts/container images. There are a few articles on msft devblogs that cover from-netframework migration to older versions (Core 3.1, 5/6/7): - https://devblogs.mi…

Cheating. All of the 6x performance improvement cases seem to be related to using the .net based Kestrel web server instead of IIS web server, which requires marshalling and interprocess communication. Several of the 2x gains appear to be related to using a different database backend. Claims that regex performance has improved a thousand-fold.... seem more troubling than cause for celebration. Were you not precompili…

    > Were you not precompiling your regex's in the older code? That would be a bug.
I never heard of this before. Perl has legendary fast regexen and I never heard of this feature. Does Java do it? I don't think so, and the regexes are fast enough in my experience. Can you name a language when regexen are precompiled?
Post reply on HN