4 ms·

The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from

The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c

dgan 1y ago
what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests
- modeless 1y ago
  The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. And I'm also sure that for new C/C++ code that's aware of the performance characteristics of Fil-C that we could come up with ways to mitigate performance issues.
  - munificent 1y ago
    I mean, if I could accept a 2x-4x performance hit, then I wouldn't be using C++ in the first place. At that point, there are any of a number of other languages that are miles more pleasant to program in.
    - modeless 1y ago
      There are a whole lot of C/C++ libraries and utilities that would be great to use in a memory safe context without rewriting them. And it's not exactly easy to reach 2x C's runtime in most other languages. But again, I think that performance penalty could be significantly reduced with more effort on the implementation.
    - wrs 1y ago
      For new code, sure. But there is plenty of existing C code that isn’t going to be rewritten and isn’t that performance sensitive.
  - jandrewrogers 1y ago
    The design choices that make it slower can’t be mitigated either in theory or practice. C++ competes against other languages that make virtually identical tradeoffs that are far more mature and which have never closed that performance gap in a meaningful way. For the high-end performance-engineered cases that C++ is famously used for, the performance loss may be understated since it actively interferes with standard performance-engineer techniques. It may have a role in boring utilities and such but those are legacy roles for C++. That might be a good use case! Most new C++ code is used in applications where something like Fil-C would be an unacceptable tradeoff.
    - modeless 1y ago
      It won't ever be 1x the runtime, but if you think better than 2x is an insurmountable challenge then we will have to agree to disagree on that one. And for high-end performance engineering, I expect code that is aware of Fil-C could do better than naive code simply compiled with Fil-C.
- fuhsnn 1y ago
  Latest version of Fil-C with -O1 is just around 50-100% slower than ASAN, very acceptable in my book. I'm actually more "bothered" by its compilation time (took roughly 8x time of clang with ASAN).
  - foldr 1y ago
    I’ve found Fil-C 0.670 to be around 30x slower than a regular build, with -O1 vs. -O2 not making much difference. Perhaps it is very dependent on the kind of code. IIRC the author of Fil-C (which I think is an incredible project, to be clear) wants it to be possible to run Fil-C builds in production, so I think the comparison to a regular non-ASAN build is relevant.
  - saagarjha 1y ago
    For debugging, sure. Address sanitizer is itself pretty slow.
throwawaty76543 1y ago
> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job. > The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c Again—do you expect the standards committee to enforce usage of this compiler or what? The standards commitee doesn't "standardize" compilers...
- modeless 1y ago
  Both zapcc and Fil-C could benefit from the involvement of the standards committee. While both are very compatible, there are certain things that they can't fully support and it would be useful to standardize small language changes for their benefit (and for the benefit of other implementations of the same ideas). Certainly more useful than anything else the standards committees have done in the past 10 years. They would also benefit from the increased exposure that standardization would bring, and the languages would benefit from actual solutions to the problems of security and compile time that C/C++ developers face every day.
  - wakawaka28 1y ago
    The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products. Of course, these tools are of interest to the broader C++ community. Thanks for sharing.
    - modeless 1y ago
      I'm not asking the standards committees to develop them for free. They were already developed! I'm saying that the committees should acknowledge their existence, and the fact that they solve some of C/C++'s biggest problems, in some ways better than the committee-blessed solutions. They deserve attention from the committees to direct language evolution in ways that support them better and encourage alternative implementations.
wakawaka28 1y ago
Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does. I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.
- modeless 1y ago
  Zapcc can, and frequently does, speed up the compilation of single files by 20x or more in the incremental case. CCache can't do that. And it's by far the common case when compiling iteratively during development. A speedup that large is transformational to your development workflow.
  - wakawaka28 1y ago
    ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually good enough. Also, ccache works with many compilers, whereas zapcc is its own compiler. That is a huge advantage.
    - jhasse 1y ago
      I have a cpp file that takes 10 seconds to compile. I change one line. How does ccache help me in this case?
      - wakawaka28 1y ago
        When you do a clean build, it will pull that output from the cache if it has been compiled before and has not changed since. It does not technically speed up compilation of files. It bypasses compilation when it can.
    - 1y ago
motorest 1y ago
> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc Tools like ccache have been around for over two decades, and all you need to do to onboard them is to install the executable and set an environment flag. What value do you think something like zapcc brings that tools like ccache haven't been providing already? https://en.wikipedia.org/wiki/Ccache https://en.wikipedia.org/wiki/Ccache
- agent327 1y ago
  > What value do you think something like zapcc brings that tools like ccache haven't been providing already? It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.
  - motorest 1y ago
    > It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file. I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why. I've been using ccache for years and I never had any problem getting ccache to support template code. Why? Because the concept of templates is ortogonal to compiler caches. It matters nothing, if you understand how compiler caches work. Think about it. You have the source file you are compiling, you have the set of build flags passed to the compiler, and you have the resulting binary. That's the whole input, and output. It's irrelevant if the code features templates or not. Have you checked if the likes of zapcc is fixing a problem that actually doesn't exist?
    - 1y ago
FooBarWidget 1y ago
zapcc looks really promising! Unfortunately it seems to be unmaintained: haven't seen any commits in 5 years.
account42 1y ago
> The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c > It's not even possible to link to unsafe code. This makes it rather theoretical.
- StilesCrisis 1y ago
  You’d be surprised! “Lots of software packages work in Fil-C with zero or minimal changes, including big ones like openssl, CPython, SQLite, and many others.” It wraps all of the typical API surface used by Linux code. I’m told it has found real bugs in well-known packages as well, as it will trap on unsafe but otherwise benign accesses (like reading past one the end of a stack buffer).

dgan 1y ago

what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests

modeless 1y ago
The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. And I'm also sure that for new C/C++ code that's aware of the performance characteristics of Fil-C that we could come up with ways to mitigate performance issues.
- munificent 1y ago
  I mean, if I could accept a 2x-4x performance hit, then I wouldn't be using C++ in the first place. At that point, there are any of a number of other languages that are miles more pleasant to program in.
  - modeless 1y ago
    There are a whole lot of C/C++ libraries and utilities that would be great to use in a memory safe context without rewriting them. And it's not exactly easy to reach 2x C's runtime in most other languages. But again, I think that performance penalty could be significantly reduced with more effort on the implementation.
  - wrs 1y ago
    For new code, sure. But there is plenty of existing C code that isn’t going to be rewritten and isn’t that performance sensitive.
- jandrewrogers 1y ago
  The design choices that make it slower can’t be mitigated either in theory or practice. C++ competes against other languages that make virtually identical tradeoffs that are far more mature and which have never closed that performance gap in a meaningful way. For the high-end performance-engineered cases that C++ is famously used for, the performance loss may be understated since it actively interferes with standard performance-engineer techniques. It may have a role in boring utilities and such but those are legacy roles for C++. That might be a good use case! Most new C++ code is used in applications where something like Fil-C would be an unacceptable tradeoff.
  - modeless 1y ago
    It won't ever be 1x the runtime, but if you think better than 2x is an insurmountable challenge then we will have to agree to disagree on that one. And for high-end performance engineering, I expect code that is aware of Fil-C could do better than naive code simply compiled with Fil-C.
fuhsnn 1y ago
Latest version of Fil-C with -O1 is just around 50-100% slower than ASAN, very acceptable in my book. I'm actually more "bothered" by its compilation time (took roughly 8x time of clang with ASAN).
- foldr 1y ago
  I’ve found Fil-C 0.670 to be around 30x slower than a regular build, with -O1 vs. -O2 not making much difference. Perhaps it is very dependent on the kind of code. IIRC the author of Fil-C (which I think is an incredible project, to be clear) wants it to be possible to run Fil-C builds in production, so I think the comparison to a regular non-ASAN build is relevant.
- saagarjha 1y ago
  For debugging, sure. Address sanitizer is itself pretty slow.

throwawaty76543 1y ago

> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job. > The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c Again—do you expect the standards committee to enforce usage of this compiler or what? The standards commitee doesn't "standardize" compilers...

modeless 1y ago
Both zapcc and Fil-C could benefit from the involvement of the standards committee. While both are very compatible, there are certain things that they can't fully support and it would be useful to standardize small language changes for their benefit (and for the benefit of other implementations of the same ideas). Certainly more useful than anything else the standards committees have done in the past 10 years. They would also benefit from the increased exposure that standardization would bring, and the languages would benefit from actual solutions to the problems of security and compile time that C/C++ developers face every day.
- wakawaka28 1y ago
  The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products. Of course, these tools are of interest to the broader C++ community. Thanks for sharing.
  - modeless 1y ago
    I'm not asking the standards committees to develop them for free. They were already developed! I'm saying that the committees should acknowledge their existence, and the fact that they solve some of C/C++'s biggest problems, in some ways better than the committee-blessed solutions. They deserve attention from the committees to direct language evolution in ways that support them better and encourage alternative implementations.

wakawaka28 1y ago

Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does. I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.

modeless 1y ago
Zapcc can, and frequently does, speed up the compilation of single files by 20x or more in the incremental case. CCache can't do that. And it's by far the common case when compiling iteratively during development. A speedup that large is transformational to your development workflow.
- wakawaka28 1y ago
  ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually good enough. Also, ccache works with many compilers, whereas zapcc is its own compiler. That is a huge advantage.
  - jhasse 1y ago
    I have a cpp file that takes 10 seconds to compile. I change one line. How does ccache help me in this case?
    - wakawaka28 1y ago
      When you do a clean build, it will pull that output from the cache if it has been compiled before and has not changed since. It does not technically speed up compilation of files. It bypasses compilation when it can.
  - 1y ago

motorest 1y ago

> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc https://github.com/yrnkrn/zapcc Tools like ccache have been around for over two decades, and all you need to do to onboard them is to install the executable and set an environment flag. What value do you think something like zapcc brings that tools like ccache haven't been providing already? https://en.wikipedia.org/wiki/Ccache https://en.wikipedia.org/wiki/Ccache

agent327 1y ago
> What value do you think something like zapcc brings that tools like ccache haven't been providing already? It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.
- motorest 1y ago
  > It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file. I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why. I've been using ccache for years and I never had any problem getting ccache to support template code. Why? Because the concept of templates is ortogonal to compiler caches. It matters nothing, if you understand how compiler caches work. Think about it. You have the source file you are compiling, you have the set of build flags passed to the compiler, and you have the resulting binary. That's the whole input, and output. It's irrelevant if the code features templates or not. Have you checked if the likes of zapcc is fixing a problem that actually doesn't exist?
  - 1y ago

FooBarWidget 1y ago

zapcc looks really promising! Unfortunately it seems to be unmaintained: haven't seen any commits in 5 years.

account42 1y ago

> The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well: https://github.com/pizlonator/fil-c https://github.com/pizlonator/fil-c > It's not even possible to link to unsafe code. This makes it rather theoretical.

StilesCrisis 1y ago
You’d be surprised! “Lots of software packages work in Fil-C with zero or minimal changes, including big ones like openssl, CPython, SQLite, and many others.” It wraps all of the typical API surface used by Linux code. I’m told it has found real bugs in well-known packages as well, as it will trap on unsafe but otherwise benign accesses (like reading past one the end of a stack buffer).