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
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?
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?
Someone else in this thread already pasted benchmarks. The observation was, and I quote:
> Zapcc focuses on super fast compile times albeit the speed of the generated code tends to be comparable with Clang itself, at least based upon last figures.
Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks
> 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.
Do you talk down to people like this IRL as well?
> I've been using ccache for years and I never had any problem getting ccache to support template code.
What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.
> if you understand how compiler caches work. Think about it.
There's no need to use "condescending asshole" as your primary mode of communication, especially when you are wrong, such as in this case.
If you look at the benchmarks you just quoted, you see cache-based compilations outperforming zapcc in quite a few tests. I wonder why you missed that.
The ones that ccache fares as well as builds that don't employ caching at all are telling. Either ccache was somehow not used, or there was a critical configuration issue that prevented ccache from caching anything. This typically happens when projects employ other optimization strategies that mess with ccache, such as pipelining builds being enabled or extensive use of precompiled headers.
The good news is that in both cases these issues are fixed by either by actually configuring ccache or disabling these other conflicting optimization strategies. To be able to tell, it would be necessary to troubleshooting the build and take a look at ccache logs.
> Do you talk down to people like this IRL as well?
Your need to resort to personal attacks is not cool. What do you hope to achieve, other than not sounding like an adult?
And do you believe that pointing out critical design flaws is "talking down to people"?
My point is very clear: your baseline compiler cache system, something that exists for two decades, already supports caching template code. How? Because it was never an issue to begin with. I explained why: because a compiler cache fundamentally caches the resulting binary given a cache key, which is comprised of data such as the source file provided as input (basically the state of the translation unit) and the set of compiler flags used to compile it. What features in the translation unit is immaterial. It doesn't matter.
Do you understand why caching template code is a problem that effectively never existed?
> What I said is that zapcc has a different approach that offers even more performance benefits, answering the question of what zapcc offers that ccache doesn't offer.
It's perfectly fine if you personally have a desire to explore whatever idea springs to mind. There is no harm in that.
If you are presenting said pet project as any kind of solution, the very least that is required of you is to review the problem space, and also perform a honest review of the solution space. You might very well discover that your problem effectively does not exist, because some of your key assumptions do not hold.
I repeat: with pretty basic compiler caches, such as ccache which exists for over two decades, the only thing you need to do to be able to cache template code is to install ccache and set a flag in your build system. Tools such as cmake already support it out of the box, so onboarding work is negligible. Benchmarks already show builds with ccache outperforming builds with the likes of zapcc. What does this tell you?
You used many words just so say "ccache is a build cache".
> it still needs to rebuild the whole translation unit from scratch if a single line in some header changes.
You are using many words to say "ccache rebuilds a translation unit when it changes".
What point were you trying to make?
Frankly your attitude in this whole thread has been very condescending. Being condescending and also not understanding what you're talking about is a really bad combination. Reconsider whether your commenting style is consistent with the HN guidelines, please.
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
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.
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.
> It's not even possible to link to unsafe code.
This makes it rather theoretical.
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).
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
Again—do you expect the standards committee to enforce usage of this compiler or what? The standards commitee doesn't "standardize" compilers...
Of course, these tools are of interest to the broader C++ community. Thanks for sharing.
That's great to hear. It sounds like you have everything set to put together a proposal. Do you have any timeline in mind to present something?
> I'm saying that the committees should acknowledge their existence, (...)
Oh does this mean any of the tools you're praising was already proposed to be included in the standard? Do you mind linking to the draft proposal? It's a mailing list, and all it takes is a single email, so it should be easy to link.
Where's the link?
>Both zapcc and Fil-C could benefit from the involvement of the standards committee.
What exactly does the standards committee do for these software projects without being involved in their development? I think there is nothing to do here that is within the scope of the language itself. Of course, if the creators of those projects come up with a cool new idea, they can submit to the standards committee for comment. They can also comment on new standards that make the tools not work anymore. But that is help going from the project to the committee, not the other way around.
I think there is a hefty deal of ignorance in your comment. A standardization process is not pull-based, it's push-based.
If you feel you have a nice idea that has technical legs to stand, you write your idea down and put together a proposal and then get in touch with committee members to present it.
The process is pretty open.
> Certainly more useful than anything else the standards committees have done in the past 10 years.
Do you understand the "standards committee" is comprised of people like you and me, except they got off their rear-end and actually contribute to it? You make it sound like they are a robe-wearing secret society that is secluded from the world.
Seriously, spend a few minutes getting acquainted with the process, what it takes to become a member, and what you need to do to propose something.
There are also quite a few compiler cache systems around.
For example, anyone can onboard tools like ccache by installing it and setting an environment variable.
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.
ccache doesn't add anything over make for a single project build.
C++ build times are actually dominated by redundant parsing of headers included in multiple .cpp files. And also redundant template instantiations in different files. This redundancy still exists when using ccache.
By caching the individual language constructs, you eliminate the redundancy entirely.