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

Clang Format Tanks Performance

travisdowns.github.io

Post reply on HN
Print view View original

141–150 of 156 posts

Re: Clang Format Tanks Performance

#141

Post by BeeOnRope »

TwoBit wrote: post #67
BeeOnRope wrote: post #29

Earlier quoted context omitted.

The title was basically clickbait. It reflects how I encountered the issue, but the investigation doesn't have much of that, because I was starting from a point where I suddenly had a slow and fast algorithm (the actual scenario was more complicated than shown). The investigation doesn't have much to do with clang-format because I'm just trying to see why a raw loop is faster, and ultimately has nothing to do with "r…

A disagree with your conclusion that the slowness doesn't matter. If it doesn't matter to anybody then why does the optimized version even exist? IMO this is a library bug. shouldn't be limping toupper or anything else.

The conclusion near the end of the blog post?

That's not really because performance doesn't matter, but because toupper() shouldn't really matter in most modern C and C++ programs: it just can't support Unicode. So either you are using a different way of supporting strings entirely (if you need any kind of Unicode or multibyte support), or this is some internal ASCII-only text processing in which case you are better off using your own methods (e.g., the lookup table I mention at the end) since they'll provide an easy speedup and you aren't accidentally introducing locale-dependent code where you don't want it.

Re: Clang Format Tanks Performance

#142

Post by BeeOnRope »

_fbpt wrote: post #65
BeeOnRope wrote: post #2

Author here, happy for any feedback. I'll own up to misleading-and-possibly-clickbait title, I just gave up trying to think of anything better without revealing the conclusion.

I read the title and thought the article was about (clang-format's performance) on a (program simulating military tanks)... Apparently you meant "tanks" as a verb...

Yes, although a quick search reveals that Oxford considers this a US usage so it was probably not the ideal choice for a title.

Re: Clang Format Tanks Performance

#143

Post by BeeOnRope »

account42 wrote: post #117
BeeOnRope wrote: post #16

Earlier quoted context omitted.

Yes, it can! In fact I had that at some point and clobbered it with a git reset (the perils of developing on two machines and once and using git a sync mechanism). Fixed [1] and credited. --- [1] https://github.com/travisdowns/travisdowns.github.io/commit/...

This could actually change performance though as the lambda version gives you a unique templace instantiation of std::transform while the non-lambda version requires std::transform to be inlined into the caller (or cloned to an argument-specific version) before the compiler can make any optimizations based on its knowledge of toupper.

Good point. I would usually expect std::transform to be inlined, since it is quite simple - but it may not be and it's a very good point in general regarding the optimization probability for function pointers versus lambdas.

Ultimately, I ended up reverting the change, so using a lambda based on the advice the taking the address of a standard-library function is verboten, since they may introduce overloads at any time [1].

---

[1] https://twitter.com/foonathan/status/1197051249822195712

Re: Clang Format Tanks Performance

#144

Post by tzhenghao »

pdimitar wrote: post #91

I may eat downvotes but here's an honest opinion nonetheless: this article shows almost exactly why I wouldn't touch C++ with a ten-foot pole still, after running away screaming from it 11-12 years ago. Not saying it's an unique problem with C++'s tooling. I'm just saying that it has been my experience that one is much more likely to stumble upon such horrors while working with C++ as opposed to at least 7 other lang…

I’d agree with you, given the chance to do so in a codebase that has vanilla dependencies. If you work in robotics or do a lot of parallel computing for example, the libraries you use are almost always based on C++, so there’s not an easy way to code against them. Even if there is such a solution, a gap between the languages can lead to non-trivial behaviors and that in itself is more costly to fix than to write in the first class language C++ anyway.

Re: Clang Format Tanks Performance

#145

Post by School-Cotton »

BeeOnRope wrote: post #138
dleslie wrote: post #51

Earlier quoted context omitted.

Of course clang format is at fault; reordering includes, even standard or system includes, will almost certainly effect how a complex C/C++ program compiles. That's just how it is, with the preprocessor and such. This is a _bad_ clang-format bug.

Yes, but reordering the headers is usually safe. Having order-dependent behavior is a serious bug and should generally be fixed by the header authors. When you add a header do you usually carefully consider the interaction between the new header and all the exist ones? No, you just add it to the end of the existing list or at its sorted position? Yeah, me too. I agree that a formatting tool changing the behavior or p…

No, I don’t normally think about header order, but if I’m unlucky enough to be getting some weird behavior based on header order, I think I’d be able to debug it before landing my change.

I’d be pissed if the issue were introduced by a formatting pass.

Re: Clang Format Tanks Performance

#146

Post by The_rationalist »

Ygg2 wrote: post #104
The_rationalist wrote: post #97

Earlier quoted context omitted.

Yes, at best 20% slower but can be far more slower if you hit worst case scenario.

Where did you pull those numbers? Looking at https://benchmarksgame-team.pages.debian.net/benchmarksgame/... While the worst case is 40% slower (where even C perfored abysmally), most of the time the Rust is within a 10% margin of error, and in quite a few cases it's faster.

As nozzz said, this is using clang. So I should correct my statement, c++ is in average 30% faster as gcc is in average 20% faster than llvm.

Re: Clang Format Tanks Performance

#147

Post by The_rationalist »

gameswithgo wrote: post #110
The_rationalist wrote: post #97

Earlier quoted context omitted.

Yes, at best 20% slower but can be far more slower if you hit worst case scenario.

"at best 20%" slower is a clearly non factual statement. Probably the one scenario where it would be far more slower than that would be a heavily AVX-512 intrinsics program because Rust doesn't have those yet (I think), but then that isn't really either language anymore. its intrinsics.

Re-read as 30% slower in average and then it's a factual statement.

Re: Clang Format Tanks Performance

#148

Post by The_rationalist »

johnzabroski wrote: post #101
The_rationalist wrote: post #97

Earlier quoted context omitted.

Yes, at best 20% slower but can be far more slower if you hit worst case scenario.

Why is Mozilla Firefox written in Rust, then? The last time I looked at browser benchmarks was in 2016 when Google released benchmarks to brag about its performance over Firefox and Edge. It appears Webkit has released JetStream2 to benchmark JavaScript, WebAssembly and web workers, among other things. But I can't find data showing Mozilla Firefox is ~20% slower than Chrome/Edge today.

Firefox is far more than 20% slower than Chrome today but is not strictly a direct cause of using rust. https://www.phoronix.com/scan.php?page=article&item=firefox-...

Re: Clang Format Tanks Performance

#149

Post by The_rationalist »

dthul wrote: post #102
johnzabroski wrote: post #101

Earlier quoted context omitted.

Why is Mozilla Firefox written in Rust, then? The last time I looked at browser benchmarks was in 2016 when Google released benchmarks to brag about its performance over Firefox and Edge. It appears Webkit has released JetStream2 to benchmark JavaScript, WebAssembly and web workers, among other things. But I can't find data showing Mozilla Firefox is ~20% slower than Chrome/Edge today.

Using Firefox to evaluate Rust performance is probably not a good idea since only parts of it are written in Rust today. But it's the first time I hear someone say that Rust is supposedly fundamentally slower than C++. I don't believe this to be a statement that can be substantiated, seeing that some of the fastest programs out there (ripgrep and hyper to name just two) are written in Rust.

Facts: On average rust is 10% slower on the banchmarkgame: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

But they use llvm instead of gcc for c++, and gcc is in average 20% faster than clang. Therefore, rust is 30% slower, at least on heavily optimised programs.

And hyper is not the fastest http server, but the actix one is one of the fastest yes.

Re: Clang Format Tanks Performance

#150

Post by twic »

BeeOnRope wrote: post #139
twic wrote: post #119

Earlier quoted context omitted.

It would actually be interesting to see if this phenomenon happens with clang, which has its own implementation of the standard library. And perhaps with musl libc or some such.

Clang has its own libc++ implementation, but I think clang still uses the system libc and associated headers?

Yes, i think so too. So a different , but the same .

The crucial __NO_CTYPE define is in , which is part of the GCC paraphernalia. I don't know if clang's stdlib would also have to end up defining it.

Post reply on HN