4 ms·

C++ projects tend to support massively parallel builds, despite what people tend to complain about with header files. The issue here in this article was partly

by saurik 5y ago

C++ projects tend to support massively parallel builds, despite what people tend to complain about with header files. The issue here in this article was partly that Rust only compiles crates in parallel, but while people tend to have lots and lots of C++ translation units, they don't have lots and lots of Rust crates. Languages seem to be moving in the wrong direction here :/.

codeflo 5y ago
That matches my experience as well. It takes a nontrivial amount of discipline, but it’s possible to structure a C++ project for fast builds. In theory, having a module system that isn’t based on text substitution should give Rust an advantage, but on the minus side, the crate structure gives you fewer knobs to optimize.
- nmfisher 5y ago
  Care to elaborate further on how to best structure a C++ project for fast builds?
  - codeflo 5y ago
    It’s a large topic, but the most important goal is to minimize the amount of code that’s transitively included in headers. That can mean avoiding templates, or (if you’re willing to do the work) using explicit instantiations in one source file only. Use the PImpl pattern so that users of a class don’t need to know the declarations of its private members. And whenever reasonable, design your method signatures so that objects are passed by pointer/reference — this means you can work with forward declarations instead of always having to include the full class declaration. Do all of that only where reasonable. Small headers usually don’t matter much, and avoiding dependencies on headers that users are likely to include anyway (like <string>) doesn’t win anything either.
  - dataflow 5y ago
    Avoid over-templating, don't inline expensive functions, put expensive #includes inside .cpp files instead of headers, use internal linkage whenever possible, etc. Doable in theory, painful to get there in practice if you've already dug yourself into a hole, and you can't get out of said hole without convincing the rest of your team/organization to change their coding practices accordingly.
  - jcelerier 5y ago
    Here's my edit-compile-run cycle in dev configuration: https://streamable.com/az397y https://streamable.com/az397y I use Qt, boost, lots of templates. - clang as a compiler - mold as a linker - PCH (easy with cmake) - plugin architecture for the software ; plugins are dynamic libraries when developing (everything is linked statically for releases which take of course much longer to build with lto, etc.) - building on Linux (it's seriously slower on Windows, when using the exact same compiler on the exact same SSD)
    - mastax 5y ago
      Disabling Windows Defender in your build directories can be a serious boost. NTFS is still slow, though.
      - dgellow 5y ago
        You can also disable Windows Defender for the build process, for example disabling it for devenv.exe makes Visual Studio builds waaaaaay faster!
    - nmfisher 5y ago
      Which editor is this?
      - dgellow 5y ago
        Qt Creator I believe? Not 100% sure.
spockz 5y ago
I rarely touch C(++) but every time I have to compile something a bit more complicated than the simplest of projects it is noticeably slow. Other languages I use, scala and go and rust, have higher initial cost but seem to suffer less when the sources grow. A recent example, linkerd proxy compiled in a few minutes, while it took me hours to compile envoy proxy. Then there are the stories in how ridiculously long it takes to build Chrome or the V8 engine. I’m really not sold that real world c(++) projects are fast to build.
- ithkuil 5y ago
  I have a vague memory that at a previous job I was building envoy proxy in a build automation pipeline and it regularly OOMed. While troubleshooting I noticed that most of the time and memory was spent compiling one or two generated C++ files; they contained many many many type parameters. When you have to generate templates something is wrong.
mtzet 5y ago
That's a bit misleading though. The problem with header files is that they tend to get (textually) included in lots of compilation units, and hence rebuilt a lot of times. I did an experiment on a codebase at work where turning on unity builds -- so effectively everything is a single c++ file -- resulted in a 2x speedup in real time, and a 12x reduction in 'user' time. Of course, such approaches lead to slower hot rebuilds. There's trade-offs worthy of a book. But the point is that C++ is only massively parallel by adding a lot of extra work. This problem could be overcome by reducing the complexity of header files, but that's generally difficult if template-types are used. In general, the solution is to write code that's closer to C than C++ in the header files. In particular using opaque pointers to hide data. We're actually seeing a very similiar problem in the linked article. The chief problem is monomorphization (~templates) and the solution is to use boxing (~data hiding via opaque pointers).
- deleted 5y ago
  [deleted]

by saurik 5y ago

codeflo 5y ago

That matches my experience as well. It takes a nontrivial amount of discipline, but it’s possible to structure a C++ project for fast builds. In theory, having a module system that isn’t based on text substitution should give Rust an advantage, but on the minus side, the crate structure gives you fewer knobs to optimize.

nmfisher 5y ago
Care to elaborate further on how to best structure a C++ project for fast builds?
- codeflo 5y ago
  It’s a large topic, but the most important goal is to minimize the amount of code that’s transitively included in headers. That can mean avoiding templates, or (if you’re willing to do the work) using explicit instantiations in one source file only. Use the PImpl pattern so that users of a class don’t need to know the declarations of its private members. And whenever reasonable, design your method signatures so that objects are passed by pointer/reference — this means you can work with forward declarations instead of always having to include the full class declaration. Do all of that only where reasonable. Small headers usually don’t matter much, and avoiding dependencies on headers that users are likely to include anyway (like <string>) doesn’t win anything either.
- dataflow 5y ago
  Avoid over-templating, don't inline expensive functions, put expensive #includes inside .cpp files instead of headers, use internal linkage whenever possible, etc. Doable in theory, painful to get there in practice if you've already dug yourself into a hole, and you can't get out of said hole without convincing the rest of your team/organization to change their coding practices accordingly.
- jcelerier 5y ago
  Here's my edit-compile-run cycle in dev configuration: https://streamable.com/az397y https://streamable.com/az397y I use Qt, boost, lots of templates. - clang as a compiler - mold as a linker - PCH (easy with cmake) - plugin architecture for the software ; plugins are dynamic libraries when developing (everything is linked statically for releases which take of course much longer to build with lto, etc.) - building on Linux (it's seriously slower on Windows, when using the exact same compiler on the exact same SSD)
  - mastax 5y ago
    Disabling Windows Defender in your build directories can be a serious boost. NTFS is still slow, though.
    - dgellow 5y ago
      You can also disable Windows Defender for the build process, for example disabling it for devenv.exe makes Visual Studio builds waaaaaay faster!
  - nmfisher 5y ago
    Which editor is this?
    - dgellow 5y ago
      Qt Creator I believe? Not 100% sure.

spockz 5y ago

I rarely touch C(++) but every time I have to compile something a bit more complicated than the simplest of projects it is noticeably slow. Other languages I use, scala and go and rust, have higher initial cost but seem to suffer less when the sources grow. A recent example, linkerd proxy compiled in a few minutes, while it took me hours to compile envoy proxy. Then there are the stories in how ridiculously long it takes to build Chrome or the V8 engine. I’m really not sold that real world c(++) projects are fast to build.

ithkuil 5y ago
I have a vague memory that at a previous job I was building envoy proxy in a build automation pipeline and it regularly OOMed. While troubleshooting I noticed that most of the time and memory was spent compiling one or two generated C++ files; they contained many many many type parameters. When you have to generate templates something is wrong.

mtzet 5y ago

That's a bit misleading though. The problem with header files is that they tend to get (textually) included in lots of compilation units, and hence rebuilt a lot of times. I did an experiment on a codebase at work where turning on unity builds -- so effectively everything is a single c++ file -- resulted in a 2x speedup in real time, and a 12x reduction in 'user' time. Of course, such approaches lead to slower hot rebuilds. There's trade-offs worthy of a book. But the point is that C++ is only massively parallel by adding a lot of extra work. This problem could be overcome by reducing the complexity of header files, but that's generally difficult if template-types are used. In general, the solution is to write code that's closer to C than C++ in the header files. In particular using opaque pointers to hide data. We're actually seeing a very similiar problem in the linked article. The chief problem is monomorphization (~templates) and the solution is to use boxing (~data hiding via opaque pointers).

deleted 5y ago
[deleted]