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

51–60 of 156 posts

Re: Clang Format Tanks Performance

#51

Post by dleslie »

BeeOnRope wrote: post #36
gpm wrote: post #31

Earlier quoted context omitted.

I'm going to take the contrarian view here, and say it's not clickbait. I admit that I'm not a C++ expert, but naively I would never have expected clang-format to have any effect on my code. If you stopped and suggested header re-ordering to me my first thought would have been "I guess it must not do that. Maybe in practice header re-ordering doesn't actually matter with reasonable code?". The title here doesn't desc…

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same effect could have happened by adding a new header, reordering the headers manually, switching to a system with a different libc version or a different transitive header include tree, etc. 2) The title doesn't tell you wtf is up. You have to get at least half w…

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.

Re: Clang Format Tanks Performance

#52

Post by dleslie »

BeeOnRope wrote: post #26
JonathonW wrote: post #17

Earlier quoted context omitted.

Just to make sure I'm understanding this correctly: the performance issue you found actually amounts to include-order dependent behavior in GCC and glibc; clang doesn't really have anything to do with anything here except that you used its code formatter to sort your include statements. If that's the case, the clickbait-y headline's bordering on useless, since the performance differences here have nothing to do with…

I'm talking about clang-format, a formatting tool for C and C++ code, which has nothing to do with compiling your code with clang. You can use it with any compiler. That said, the title is still a lie in that clang-format is not really at a fault here at all: clang-format triggered the issue on my codebase, by sorting header files, and this in turn triggered a libc performance issue. So as I initially say it, a commi…

clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.

Re: Clang Format Tanks Performance

#53

Post by hombre_fatal »

BubRoss wrote: post #7
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.

Why does every title have to be a mystery? Why not tell people what it contains?

So that you can't just respond to the title.

Re: Clang Format Tanks Performance

#55

Post by BeeOnRope »

pvg wrote: post #35
BeeOnRope wrote: post #30

Earlier quoted context omitted.

Got it, I didn't understand you were talking about HN titles, rather than the blog post title. I didn't submit it to HN so I can't comment on the title choice, other than say it at least reflects the literal title of the page which I guess would be the default when submitting. I tend to outsource my comments to HN, since my blog is a github pages static site and introducing comments without tracking and ads is a pain…

Right, technically, fixing the title in this case would have been on the poster. Then there'd probably be a long subthread about why the title was changed so drastically. Title-lawyering is a professional metasport around here, as has been amply demonstrated.

Grabs popcorn :).

Re: Clang Format Tanks Performance

#56

Post by glandium »

dleslie wrote: post #52
BeeOnRope wrote: post #26

Earlier quoted context omitted.

I'm talking about clang-format, a formatting tool for C and C++ code, which has nothing to do with compiling your code with clang. You can use it with any compiler. That said, the title is still a lie in that clang-format is not really at a fault here at all: clang-format triggered the issue on my codebase, by sorting header files, and this in turn triggered a libc performance issue. So as I initially say it, a commi…

clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.

It's optional, although it's enabled by default in the LLVM and Chromium styles.

Re: Clang Format Tanks Performance

#57

Post by glandium »

gpm wrote: post #49
quotemstr wrote: post #47

Earlier quoted context omitted.

Almost everyone does dynamically link Glibc. You should dynamically link glibc too. But if you really want, you can statically link glibc. $ dpkg -S '*/libc.a' libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a But please don't . Static linking doesn't give you a compatibility advantage: dynamically linked glibc is specifically designed to be forward and backward compatible. Static linking only makes life more difficu…

> As for static linking being a competitive advantage of musl: I don't know where you got that idea. That's how I've been told to build fully statically linked rust binaries, I can't say I've dug into why glibc isn't used for those.

The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc because chances are you're going to be using symbols that aren't available in older versions of the glibc, making your binary incompatible with many (older) distros. musl is an easy way out of that. Another is to build against an old glibc.

Re: Clang Format Tanks Performance

#58

Post by quotemstr »

glandium wrote: post #57
gpm wrote: post #49

Earlier quoted context omitted.

> As for static linking being a competitive advantage of musl: I don't know where you got that idea. That's how I've been told to build fully statically linked rust binaries, I can't say I've dug into why glibc isn't used for those.

The usual reason is that if you want a binary that can be used "everywhere", you can't just build on your machine without more thought if you use the glibc because chances are you're going to be using symbols that aren't available in older versions of the glibc, making your binary incompatible with many (older) distros. musl is an easy way out of that. Another is to build against an old glibc.

The right way to solve this problem would be to teach the linker to link against the set of glibc symbols that existed as of a particular version number or date. Then you'd just pass a flag (along with a preprocessor macro, so the headers would know to define the right version of the linker symbols) specifying this version target when you built your program. For want of this relatively simple toolchain feature, we have people statically linking entire C libraries. It's a shame.

You can do a moral version of the same thing using linker scripts, but nobody bothers with linker scripts.

Re: Clang Format Tanks Performance

#59

Post by JoshTriplett »

gpm wrote: post #49
quotemstr wrote: post #47

Earlier quoted context omitted.

Almost everyone does dynamically link Glibc. You should dynamically link glibc too. But if you really want, you can statically link glibc. $ dpkg -S '*/libc.a' libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.a But please don't . Static linking doesn't give you a compatibility advantage: dynamically linked glibc is specifically designed to be forward and backward compatible. Static linking only makes life more difficu…

> As for static linking being a competitive advantage of musl: I don't know where you got that idea. That's how I've been told to build fully statically linked rust binaries, I can't say I've dug into why glibc isn't used for those.

The primary reason is that a statically linked glibc can't use NSS (Name Service Switch) modules from a different glibc version, so if you statically link glibc you can't reliably resolve names with getaddrinfo. You can do DNS with other libraries, and many applications do anyway because they want asynchronous DNS and NSS uses static DNS, but you can't really do anything other than DNS or static hosts files.

musl, on the other hand, never supports NSS, whether static or dynamic, and exclusively supports DNS. You can't resolve things like mDNS names, or even resolve localhost if on a system that doesn't hardcode it in /etc/hosts.

So either way, static linking and name resolution don't mix well, and musl and non-DNS name resolution don't mix well.

Re: Clang Format Tanks Performance

#60

Post by dleslie »

glandium wrote: post #56
dleslie wrote: post #52

Earlier quoted context omitted.

clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.

It's optional, although it's enabled by default in the LLVM and Chromium styles.

That's a bizarre optional feature to have; it's tantamount to having a "blindly reorder logic" function that sorts your source alphanumerically.
Post reply on HN