Zapcc: A faster C++ compiler

is it really that unusual in our industry to work for money :) ?

And, instances like this is why some of us use licenses like BSD, CC-BY, and so on. It's not an abuse to do this, it is allowed by the license, and we choose licenses based on how we want our work to be used.

To put some context on this, I work for companies that don't release source. One of those 'companies' was the U.S. Government, and sorry, but you can't release classified work (plenty of other Government code is open, and I mailed plenty of CDs in the day). I'd rather they use my work and remain closed source, than not use my work, or use it without my knowledge. As it is, they can legally and ethically use my work, then can file problem reports, push fixes if they want, and otherwise participate.

It's not a bad thing; it's a choice.

The original authors spent exactly zero hours on designing and implementing the improvements. Why should they get anything? They work for satisfaction and money provided by apple and other companies sponsoring the project.

By your reasoning, when somebody makes money on anything, everybody in the whole production chain should get a cut. Obviously, that's not how economy in general works.

I don't think this is snake oil. The reasons that are typically given for not automatically pre-compiling headers (we're not talking about manually specified pre-compiled headers here) can all be worked around.

For example, some might say that you can't automatically cache headers because of code like this:

// file1.cpp

#include "foo.h"

// file2.cpp

#define float double

#include "foo.h"

But if you're a bit clever about it you should be able to cache opportunistically and then detect if your cache is invalidated.

ccache caches the entire translation unit to prevent the recompilation of a new .o file. It doesn't prevent the inclusion of all the header files; it still has to process all that material to determine the hash. Then if the translation unit has changed, it is compiled, conventionally.

Header file preprocessing is about having some faster representation of included material which can be loaded instead of scanning header files. This can be used even when dependent files change.

We've used a distributed compiler product (incredibuild) with great success.

> 1) linking (I don't know of any parallel linker)

How about ld.gold?

What do you mean by "toy"? In this example GCC takes 3+ minutes:

https://drive.google.com/file/d/0B1WlUivCnXhyRVk0LUl6akxVU2s...

We (zapcc) do nothing for link acceleration or debug info. The standard system linker is used.

zapcc works well for C++ templates found in all modern C++ libraries.

The reason C++ builds so slowly is mainly headers and templates iirc, they seem to just be dealing with caching header processing.

The optimizer is not disabled, few global optimizations are. The speedup is mostly the result of not having to reparse the headers, reinstantiate and codegen the generated templated code rather than skip minor opts. This is really slow process that frequently needlessly repeated on multiple compile units. We are looking into this tradeoff, maybe making the decision user-configurable or based on opt. level.

If they have the manpower to stay in sync with clang's upstream that is great for them. If they don't, they're going to have to open source it to stay in sync with upstream.

When it comes to large, fast moving projects the BSD license allows you to close the source but you're only going to obsolete yourself.

This is what is happening with several vendors who took FreeBSD closed source: Isilon, Citrix, etc. Their FreeBSD forks are so far behind they are struggling and can't backport changes anymore. So they're forward-porting their proprietary enhancements or rewriting them again (eg NFS performance fixes, Xen Dom0) by pushing them back upstream to FreeBSD so they can move their product to a modern OS release.

The fantasy you people have with "BSD lets them steal code and never give back again!" doesn't really work in practice. It saves them tons of time and money to cooperate with the community.

> I guess you'll get things like this when you use a BSD license.

That is by design. As the other commenter said, they will either have to release fixes upstream, or be forced to re-apply them over and over just stay up to date.

Looking forward to this. By "very far along" do you mean in terms of specification, implementation, or both?

I don't know anything specific about zapcc but based on the numbers here:

http://www.zapcc.com/case-studies/compiling-boost/

even their first compilation (the one you still need to perform when using ccache) is twice as fast as GCC.

In any case, I think the primary audience for this is people using clang, not GCC.

ccache doesn't speed up your compile time; it avoids compiling when that is possible. Avoiding compiling is not possible when you've changed files and need them recompiled. In that case, a ccache build proceeds using the usual compiler command line.

Also, ccache generates the preprocessor output, even in those cases when it deduces that compiling is unnecessary (and just pulls out a previously made object file). It makes that deduction based on the hash over the preprocessor output.

When warp was released, Clang's built-in preprocessor was already faster. I haven't seen any updated benchmarks.

https://news.ycombinator.com/item?id=7489532