6 ms·

>Many ideas seem great on paper but fail in practice. Yes, including the one posted by the author, sounds great on paper but in practice provides next to no be

by Kranar 4y ago

>Many ideas seem great on paper but fail in practice. Yes, including the one posted by the author, sounds great on paper but in practice provides next to no benefit. Notice how the author has provided absolutely zero evidence to justify their claim. >You just included and parsed bar.h twice. No you didn't, because header files have header guards of the form #ifndef HEADER_GUARD/#define HEADER_GUARD or #pragma once which means that header files are only parsed the first time they are included. >This makes me either a madman or a genius. It makes you neither, you're just following something because someone with a big name who you respect said it, so you to do it without actually verifying for yourself whether it's true. >Name an economically successful communist country. China.

phkahler 4y ago
>> No you didn't, because header files have header guards of the form #ifndef HEADER_GUARD/#define HEADER_GUARD or #pragma once which means that header files are only parsed the first time they are included. The header file still as to be read from disk ignoring everything until #end and then continue. This is probably not much of an issue these days with SSDs and even HDDs with caches. I think the rule can still be a good thing by making you aware of what the dependencies actually are, which can be an indicator of excess complexity or poorly defined interfaces.
- Kranar 4y ago
  Loading the same file from disk twice (which will be cached in memory) and parsing a file are not the same things. Furthermore almost every C++ compiler I'm aware of, including icc, gcc, clang, msvc, has optimizations to special case header guards.
  - ncmncm 4y ago
    Every C++ compiler still in use will not even try to open a header-guarded or #pragma once file it has already seen. Anybody trying to optimize on top of that is engaged in foolish superstition. (If you are still using Sun's pre-Standard compiler, you are not reading this. I think even Bloomberg has abandoned that.)
- kevin_thibedeau 4y ago
  It doesn't have to be read twice if the preprocessor recognizes and keeps track of include guards. GCC does this.
db48x 4y ago
> Notice how the author has provided absolutely zero evidence to justify their claim. That is true and unfortunate, but it is easy to find evidence that cleaning up header files will decrease compilation times: https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/ https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/ >> Name an economically successful communist country. > China. Except that China’s success has mostly come by instituting a “Special Economic Zone” where a lot of the normal communist rules don’t apply, and then gradually relaxing the rules elsewhere as well. Just the fact that China allows individuals to start and run businesses is a huge break from communism.
- Kranar 4y ago
  The article isn't about cleaning up header files. I don't think anyone criticizing the article is claiming that reducing the amount of code in header files will speed up compile times. The burden that the author should substantiate with evidence instead of claiming that he's a genius or a madman is whether moving includes out of header files and into source files as a strategy to avoid including the same header file multiple times has an effect on compile times. Most people criticizing this article, including myself, argue that it does not (along with reasons why, such as header guards and the optimizations that compilers include to recognize them).
  - db48x 4y ago
    The rule to never include anything from a header is just the ultimate cleanup. I reiterate that I think it is unfortunate that the author of this article collected no numbers. It would be interesting to compare them to the Linux kernel’s numbers: | v5.16-rc7 | -fast-headers-v1 |--------------------------------|--------------------------------------- 'touch include/linux/sched.h' | 230.30 secs | 15.6 builds/hour | 108.35 secs | 33.2 builds/hour | +112% 'touch include/linux/mm.h' | 216.57 secs | 16.6 builds/hour | 79.42 secs | 45.3 builds/hour | +173% 'touch include/linux/fs.h' | 223.58 secs | 16.1 builds/hour | 85.52 secs | 42.1 builds/hour | +161% 'touch include/linux/device.h' | 224.35 secs | 16.0 builds/hour | 97.09 secs | 37.1 builds/hour | +132% 'touch include/net/sock.h' | 105.85 secs | 34.0 builds/hour | 40.88 secs | 88.1 builds/hour | +159% Doubling and nearly tripling the compile speed is a huge win! But the really eye–opening numbers are further down. Here are the first few rows from the table: ------------------------------------------------------------------------------------------ | Combined, preprocessed C code size of header, without line markers, | with comments stripped: ------------------------------.-----------------------------.----------------------------- | v5.16-rc7 | -fast-headers-v1 |-----------------------------|----------------------------- #include <linux/sched.h> | LOC: 13,292 | headers: 324 | LOC: 769 | headers: 64 #include <linux/wait.h> | LOC: 9,369 | headers: 235 | LOC: 483 | headers: 46 #include <linux/rcupdate.h> | LOC: 8,975 | headers: 224 | LOC: 1,385 | headers: 86 #include <linux/hrtimer.h> | LOC: 10,861 | headers: 265 | LOC: 229 | headers: 37 #include <linux/fs.h> | LOC: 22,497 | headers: 427 | LOC: 1,993 | headers: 120 Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here, because there are still 13k lines of code to parse and compile. The speedup comes from reducing this to 64 unique headers and just 769 lines of code to compile. You cannot rely solely on #pragma once or header guards. You should definitely use them for correctness, but if that’s all you do you will leave a lot of compile–time performance on the table.

by Kranar 4y ago

phkahler 4y ago

>> No you didn't, because header files have header guards of the form #ifndef HEADER_GUARD/#define HEADER_GUARD or #pragma once which means that header files are only parsed the first time they are included. The header file still as to be read from disk ignoring everything until #end and then continue. This is probably not much of an issue these days with SSDs and even HDDs with caches. I think the rule can still be a good thing by making you aware of what the dependencies actually are, which can be an indicator of excess complexity or poorly defined interfaces.

Kranar 4y ago
Loading the same file from disk twice (which will be cached in memory) and parsing a file are not the same things. Furthermore almost every C++ compiler I'm aware of, including icc, gcc, clang, msvc, has optimizations to special case header guards.
- ncmncm 4y ago
  Every C++ compiler still in use will not even try to open a header-guarded or #pragma once file it has already seen. Anybody trying to optimize on top of that is engaged in foolish superstition. (If you are still using Sun's pre-Standard compiler, you are not reading this. I think even Bloomberg has abandoned that.)
kevin_thibedeau 4y ago
It doesn't have to be read twice if the preprocessor recognizes and keeps track of include guards. GCC does this.

db48x 4y ago

> Notice how the author has provided absolutely zero evidence to justify their claim. That is true and unfortunate, but it is easy to find evidence that cleaning up header files will decrease compilation times: https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/ https://lore.kernel.org/lkml/YdIfz+LMewetSaEB@gmail.com/T/ >> Name an economically successful communist country. > China. Except that China’s success has mostly come by instituting a “Special Economic Zone” where a lot of the normal communist rules don’t apply, and then gradually relaxing the rules elsewhere as well. Just the fact that China allows individuals to start and run businesses is a huge break from communism.

Kranar 4y ago
The article isn't about cleaning up header files. I don't think anyone criticizing the article is claiming that reducing the amount of code in header files will speed up compile times. The burden that the author should substantiate with evidence instead of claiming that he's a genius or a madman is whether moving includes out of header files and into source files as a strategy to avoid including the same header file multiple times has an effect on compile times. Most people criticizing this article, including myself, argue that it does not (along with reasons why, such as header guards and the optimizations that compilers include to recognize them).
- db48x 4y ago
  The rule to never include anything from a header is just the ultimate cleanup. I reiterate that I think it is unfortunate that the author of this article collected no numbers. It would be interesting to compare them to the Linux kernel’s numbers: | v5.16-rc7 | -fast-headers-v1 |--------------------------------|--------------------------------------- 'touch include/linux/sched.h' | 230.30 secs | 15.6 builds/hour | 108.35 secs | 33.2 builds/hour | +112% 'touch include/linux/mm.h' | 216.57 secs | 16.6 builds/hour | 79.42 secs | 45.3 builds/hour | +173% 'touch include/linux/fs.h' | 223.58 secs | 16.1 builds/hour | 85.52 secs | 42.1 builds/hour | +161% 'touch include/linux/device.h' | 224.35 secs | 16.0 builds/hour | 97.09 secs | 37.1 builds/hour | +132% 'touch include/net/sock.h' | 105.85 secs | 34.0 builds/hour | 40.88 secs | 88.1 builds/hour | +159% Doubling and nearly tripling the compile speed is a huge win! But the really eye–opening numbers are further down. Here are the first few rows from the table: ------------------------------------------------------------------------------------------ | Combined, preprocessed C code size of header, without line markers, | with comments stripped: ------------------------------.-----------------------------.----------------------------- | v5.16-rc7 | -fast-headers-v1 |-----------------------------|----------------------------- #include <linux/sched.h> | LOC: 13,292 | headers: 324 | LOC: 769 | headers: 64 #include <linux/wait.h> | LOC: 9,369 | headers: 235 | LOC: 483 | headers: 46 #include <linux/rcupdate.h> | LOC: 8,975 | headers: 224 | LOC: 1,385 | headers: 86 #include <linux/hrtimer.h> | LOC: 10,861 | headers: 265 | LOC: 229 | headers: 37 #include <linux/fs.h> | LOC: 22,497 | headers: 427 | LOC: 1,993 | headers: 120 Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here, because there are still 13k lines of code to parse and compile. The speedup comes from reducing this to 64 unique headers and just 769 lines of code to compile. You cannot rely solely on #pragma once or header guards. You should definitely use them for correctness, but if that’s all you do you will leave a lot of compile–time performance on the table.