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

41–50 of 156 posts

Re: Clang Format Tanks Performance

#41

Post by TehCorwiz »

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…

At least you’re forthcoming.

Re: Clang Format Tanks Performance

#42

Post by quotemstr »

BeeOnRope wrote: post #38
goalieca wrote: post #37

Link time inlining would solve this.

In a sense, yes - specifically if libc could be link-time inlined. I don't think many people are proposing that for libc though because it would shut down the possibility to patch libc for anything that has been link-timed inline, and more generally expose the internal implementation of libc in a way that will make evolving it very difficult. That is, link-time inlining will see a lot more use within an application b…

Applying LTO to libc would be no worse than statistically linking it. I don't like static linking, but on Linux, we're stuck with supporting it.

Re: Clang Format Tanks Performance

#43

Post by goalieca »

BeeOnRope wrote: post #38
goalieca wrote: post #37

Link time inlining would solve this.

In a sense, yes - specifically if libc could be link-time inlined. I don't think many people are proposing that for libc though because it would shut down the possibility to patch libc for anything that has been link-timed inline, and more generally expose the internal implementation of libc in a way that will make evolving it very difficult. That is, link-time inlining will see a lot more use within an application b…

True, static linking would be troublesome but what about at load time? Dynamic link time optimization could be very useful.

Re: Clang Format Tanks Performance

#44

Post by gpm »

quotemstr wrote: post #42
BeeOnRope wrote: post #38

Earlier quoted context omitted.

In a sense, yes - specifically if libc could be link-time inlined. I don't think many people are proposing that for libc though because it would shut down the possibility to patch libc for anything that has been link-timed inline, and more generally expose the internal implementation of libc in a way that will make evolving it very difficult. That is, link-time inlining will see a lot more use within an application b…

Applying LTO to libc would be no worse than statistically linking it. I don't like static linking, but on Linux, we're stuck with supporting it.

Isn't glibc almost always dynamically linked on linux? I thought half the point of musl was that it supported static linking.

Re: Clang Format Tanks Performance

#45

Post by emmelaich »

BeeOnRope wrote: post #11
Someone wrote: post #5

Earlier quoted context omitted.

clang format can tank performance” would, IMO, not decrease the number of people who click the link, yet remove the clickbait.

Could be, but I feel it would equally dishonest? This really has nothing to do with clang-format: I only mention that once (twice with an update: where clang format actually helps because it reorders stdlib.h after ctype.h) - it's all about header include order.

I think clang-format is definitely relevant; the take-away here is that no formatter should change the order of includes.

I was wondering about this only yesterday - tidying up some C++ and C code. I don't remember any standard that says it's OK to re-order headers, and clearly it can matter a lot.

Re: Clang Format Tanks Performance

#46

Post by BeeOnRope »

emmelaich wrote: post #45
BeeOnRope wrote: post #11

Earlier quoted context omitted.

Could be, but I feel it would equally dishonest? This really has nothing to do with clang-format: I only mention that once (twice with an update: where clang format actually helps because it reorders stdlib.h after ctype.h) - it's all about header include order.

I think clang-format is definitely relevant; the take-away here is that no formatter should change the order of includes. I was wondering about this only yesterday - tidying up some C++ and C code. I don't remember any standard that says it's OK to re-order headers, and clearly it can matter a lot.

That wouldn't be my take away.

My takeway would be anything that changes in semantics or performance due to header includes should be considered a bug by the (possibly joint) writers of the involved headers.

clang-format is an innocent victim here. Maybe I should make that clearer.

Re: Clang Format Tanks Performance

#47

Post by quotemstr »

gpm wrote: post #44
quotemstr wrote: post #42

Earlier quoted context omitted.

Applying LTO to libc would be no worse than statistically linking it. I don't like static linking, but on Linux, we're stuck with supporting it.

Isn't glibc almost always dynamically linked on linux? I thought half the point of musl was that it supported static linking.

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 difficult later, since it complicates use of NSS and PAM and precludes nice, clean shims between user and kernel mode. Seriously. It was a mistake for Linux to make the kernel-user transition the stable system ABI instead of putting that stability boundary at the libc layer like most other operating systems.

As for static linking being a competitive advantage of musl: I don't know where you got that idea. Musl is less featureful than glibc, not more. In particular, I'm not going to use it until it supports dlclose like every other full-featured computing platform.

Re: Clang Format Tanks Performance

#49

Post by gpm »

quotemstr wrote: post #47
gpm wrote: post #44

Earlier quoted context omitted.

Isn't glibc almost always dynamically linked on linux? I thought half the point of musl was that it supported static linking.

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.

Re: Clang Format Tanks Performance

#50

Post by flukus »

BeeOnRope wrote: post #46
emmelaich wrote: post #45

Earlier quoted context omitted.

I think clang-format is definitely relevant; the take-away here is that no formatter should change the order of includes. I was wondering about this only yesterday - tidying up some C++ and C code. I don't remember any standard that says it's OK to re-order headers, and clearly it can matter a lot.

That wouldn't be my take away. My takeway would be anything that changes in semantics or performance due to header includes should be considered a bug by the (possibly joint) writers of the involved headers. clang-format is an innocent victim here. Maybe I should make that clearer.

Clang isn't the root cause, but as a (relatively) new tool in an existing ecosystem it needs to work with the existing ecosystem and not some imaginary idealistic world.
Post reply on HN