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

81–90 of 156 posts

Re: Clang Format Tanks Performance

#81

Post by lilyball »

dleslie wrote: post #51
BeeOnRope wrote: post #36

Earlier quoted context omitted.

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.

Headers really shouldn’t be affecting each other. Header order shouldn’t matter. The fact that it does is arguably a bad design flaw in C/C++, although the C modules system pushed by Apple fixed this.

Re: Clang Format Tanks Performance

#82

Post by matt_d »

john-radio wrote: post #61

Yeesh, I can't read assembly. Is there somewhere I learn what all movsxd, lea, cmp, ja, and friends do in plain english?

Focusing on x86-64 (don't waste your time starting with the 32-bit variant when learning, let alone x87 FPU instructions, there's plenty of up-to-date materials for contemporary architectures nowadays):

- Chapter 10, Assembly Language (https://www3.nd.edu/~dthain/compilerbook/compilerbook.pdf#ch...) of http://compilerbook.org/

- intro_x86-64: Introduction to x86_64 assembly - https://gitlab.com/mcmfb/intro_x86-64

- Introduction to 64 Bit Assembly Language Programming for Linux and OS X - Ray Seyfarth - http://rayseyfarth.com/asm/

- Introduction to Computer Organization with x86-64 Assembly Language & GNU/Linux - Robert G. Plantz - http://bob.cs.sonoma.edu/IntroCompOrg-x64/book.html

- Modern X86 Assembly Language Programming - 2018; Daniel Kusswurm - Covers x86 64-bit, AVX, AVX2, and AVX-512 - https://github.com/Apress/modern-x86-assembly-language-progr...

- Understanding Assembly Language - a.k.a. Reverse Engineering for Beginners; https://yurichev.com/blog/UAL/ - https://beginners.re/

- x86-64 Assembly Language Programming with Ubuntu - Ed Jorgensen - http://www.egr.unlv.edu/~ed/x86.html

- Assembly Programming and Computer Architecture for Software Engineers (APCASE) - https://github.com/brianrhall/Assembly - Videos: https://www.youtube.com/channel/UCr0svQEez3UQvlj6-5EYS6w

Or, if you prefer talks:

- Just enough Assembly for Compiler Explorer - Anders Schau Knatten - NDC TechTown 2019 - https://www.youtube.com/watch?v=soeFwz0cOqU

- Modern x64 Assembly - https://www.youtube.com/playlist?list=PLKK11Ligqitg9MOX3-0tF...

- Bluff your way in x64 assembler - ACCU 2017; Roger Orr - https://www.youtube.com/watch?v=RI7VL-g6J7g

- Enough x86 Assembly to Be Dangerous - CppCon 2017; Charles Bailey - https://www.youtube.com/watch?v=IfUPkUAEwrk

More:

- Arm / AArch64: https://github.com/MattPD/cpplinks/blob/master/assembly.arm....

- RISC-V: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...

- x86: https://github.com/MattPD/cpplinks/blob/master/assembly.x86....

Re: Clang Format Tanks Performance

#83

Post by OskarS »

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

That reordering is simply a feature of clang-format. Some coding standards require sorting includes alphabetically, possibly to avoid dupes and to make all include usage identical between source files.

> Some coding standards require sorting includes alphabetically

Those are some pretty dumb coding standards if that's true.

(I mean, yeah, the original fault is with the C preprocessor and the fact that header order matters, but since we're stuck with that, having those kinds of coding standards is pretty darn silly!)

Re: Clang Format Tanks Performance

#84

Post by jlarcombe »

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

That reordering is simply a feature of clang-format. Some coding standards require sorting includes alphabetically, possibly to avoid dupes and to make all include usage identical between source files.

Indeed, and one reason I dislike sorting header includes alphanumerically is that it makes it easy for include-order-dependencies between them to creep in, as they're always used in the same relative order.

Re: Clang Format Tanks Performance

#85

Post by lorenzhs »

dleslie wrote: post #70
defap wrote: post #68

Earlier quoted context omitted.

Not really too bizarre. Header files should include or declare everything they need; they should not introduce include-order dependencies. Listing your includes in lexicographic order is a good way to enforce header completeness.

It is by convention that C/C++ headers rely on preprocessor state to determine what blocks to reveal, macros to use, et al. It is quite common to have an auto-generated configuration header, for instance; or a precompiled header; or optional headers that, when present, mutate the behaviour of other headers. Every time you run a configure script for a C project there's a good chance you're interacting with code in thi…

Yeah, and if you want to use clang-format include reordering in such a project, you should read the docs for clang-format's "IncludeCategories". It allows you to separate your includes into blocks by providing regexes and associated priorities. Alphabetic sorting is done only within a block.

It's not like clang-format was written by idiots who never used the language before. Maybe read up on what the tool actually does before you get all mad at them?

Re: Clang Format Tanks Performance

#86

Post by pdpi »

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

Headers really shouldn’t be affecting each other. Header order shouldn’t matter. The fact that it does is arguably a bad design flaw in C/C++, although the C modules system pushed by Apple fixed this.

Tooling developers don’t get to say “it shouldn’t matter”. It does matter, so the tools should account for this.

Re: Clang Format Tanks Performance

#87

Post by abainbridge »

Isn't the correct way to write this loop actually:

  void toupper_cmov(char* buf, size_t size) {
      for (size_t i = 0; i = 'a' && c
Because that persuades gcc and clang to transform the conditional branch into a conditional move which avoids the branch mispredict penalty and removes the need for a lookup table.

See https://godbolt.org/z/xHYKft

Disclaimer: I haven't actually run this function. That would be too much like work.

Re: Clang Format Tanks Performance

#88

Post by nocturnial »

abainbridge wrote: post #87

Isn't the correct way to write this loop actually: void toupper_cmov(char* buf, size_t size) { for (size_t i = 0; i = 'a' && c Because that persuades gcc and clang to transform the conditional branch into a conditional move which avoids the branch mispredict penalty and removes the need for a lookup table. See https://godbolt.org/z/xHYKft Disclaimer: I haven't actually run this function. That would be too much like w…

Why not use -march=native? When I look at it, I hope the compiler knows what it's doing wrt cache and whatnot.

https://godbolt.org/z/zRQRkr

Re: Clang Format Tanks Performance

#89

Post by abainbridge »

nocturnial wrote: post #88
abainbridge wrote: post #87

Isn't the correct way to write this loop actually: void toupper_cmov(char* buf, size_t size) { for (size_t i = 0; i = 'a' && c Because that persuades gcc and clang to transform the conditional branch into a conditional move which avoids the branch mispredict penalty and removes the need for a lookup table. See https://godbolt.org/z/xHYKft Disclaimer: I haven't actually run this function. That would be too much like w…

Why not use -march=native? When I look at it, I hope the compiler knows what it's doing wrt cache and whatnot. https://godbolt.org/z/zRQRkr

> Why not use -march=native?

The conditional jump remains even with -march=native.

https://godbolt.org/z/2p7uAB

Re: Clang Format Tanks Performance

#90

Post by nocturnial »

abainbridge wrote: post #89
nocturnial wrote: post #88

Earlier quoted context omitted.

Why not use -march=native? When I look at it, I hope the compiler knows what it's doing wrt cache and whatnot. https://godbolt.org/z/zRQRkr

> Why not use -march=native? The conditional jump remains even with -march=native. https://godbolt.org/z/2p7uAB

Yep just noticed it.. wanted to delete the comment but was to slow apparently
Post reply on HN