Yeesh, I can't read assembly. Is there somewhere I learn what all movsxd, lea, cmp, ja, and friends do in plain english?
Clang Format Tanks Performance
61–70 of 156 posts
Re: Clang Format Tanks Performance
#62Yeesh, I can't read assembly. Is there somewhere I learn what all movsxd, lea, cmp, ja, and friends do in plain english?
This online reference is helpful: https://www.felixcloutier.com/x86/index.html
For something more formal, the official Intel programming manuals describe what each instruction does in painstaking detail.
Re: Clang Format Tanks Performance
#63Yeesh, I can't read assembly. Is there somewhere I learn what all movsxd, lea, cmp, ja, and friends do in plain english?
Not sure plain, but still:
http://kipirvine.com/asm/gettingstartedvs2010/
Re: Clang Format Tanks Performance
#64Yeesh, I can't read assembly. Is there somewhere I learn what all movsxd, lea, cmp, ja, and friends do in plain english?
Follow the links in the article to the godbolt compiler explorer. The disassembly there has a short description of each instruction when you hover over it, and links to the full reference.
Re: Clang Format Tanks Performance
#65Author 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...
Re: Clang Format Tanks Performance
#66Earlier 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.
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.
Re: Clang Format Tanks Performance
#67Earlier quoted context omitted.
> Are my standard algorithms letting me down? Does std::transform have some fatal flaw? Not really. Well, not at all. This part lost me because I can't see how you can use std::transform (which is in ) without hitting this flaw. Unless you edit the headers? I guess you mean the algorithm isn't flawed. I also didn't understand the title because I don't use clang-format and I skimmed past the single mention of it (my f…
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.
Re: Clang Format Tanks Performance
#68Earlier quoted context omitted.
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.
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.
Re: Clang Format Tanks Performance
#69Earlier quoted context omitted.
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 ha…
The macOS SDK does this better. It is indeed a shame that the glibc doesn't care.
Re: Clang Format Tanks Performance
#70Earlier quoted context omitted.
That's a bizarre optional feature to have; it's tantamount to having a "blindly reorder logic" function that sorts your source alphanumerically.
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 this way.