
Zapcc: A faster C++ compiler - turrini
http://www.zapcc.com/
======
anonbanker
How history repeats. A company takes a BSD-licenced work, closes the source,
and makes money selling "improvements" while the original authors get nothing.

Instances like this is why the GPL has the teeth people complain about.
Without them, GNU would've been cannibalized decades ago.

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

~~~
mitchi
How is it different than someone selling barely modified WordPress websites?
I'm not into that line of work but obviously, many small businesses in America
rely on selling custom open source software.

------
CJefferson
The really big (obvious) missing comparison here is with clang's pre-compiled
headers code, and also using ccache.

I'm tempted (as they are providing no evidence otherwise) that this is snake-
oil -- they are just calling stuff which already exists in clang, maybe with a
bit of ccache on top. I'll be happy to be proved wrong.

~~~
IshKebab
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.

~~~
yrnkrn
I am the prinicipal developer of zapcc. We have added a FAQ

[http://www.zapcc.com/faq/](http://www.zapcc.com/faq/)

and more tech details in the cfe-dev mailing list

[http://lists.cs.uiuc.edu/pipermail/cfe-
dev/2015-May/043174.h...](http://lists.cs.uiuc.edu/pipermail/cfe-
dev/2015-May/043174.html)

To the point, zapcc will not reprocess foo.h. This is a limitation. However,
zapcc does deal with templates instantiations and such correctly and fast,
such as boost various libraries, Eigen and LLVM source code.

------
zvrba
It seems they're benchmarking on toy programs to create media hype. In my
previous job I found out two non-removable bottlenecks in C++ builds: 1)
linking (I don't know of any parallel linker), 2) IO (writing of debug
information). None of this is relevant in their benchmarks.

In my case, the build result, in _release_ mode, was a DLL file of about 40MB,
and corresponding debug info of about 100MB. In _debug_ mode, multiply debug
info by a factor of ca 5-10. (Individual PDBs on disk collected together were
~GB, but final PDB was smaller.) Release parallel builds on a 4-core machine,
with optimizations and all, (with HT) were noticeably faster because they
generated less IO.

Link time of _another_ DLL consisting of many (thousands) separate object
files took more time than compilation itself.

There's also another product (I won't name it because it created more problems
for me than it solved) which integrates in VS and seamlessly distributes the
compilation over machines in the local network. I stopped using it because it
often generated corrupt PDB files and messed up IntelliSense in VS.

To summarize, I have two issues with their system (apart from "good enough"
solutions for distributed compilation already existing): 1) they say nothing
about speeding up the linking stage, and related to that 2) if they mess with
linking, I'm not confident that they are reliably handling debug info. Sure,
everything works in "toy projects", but.

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

How about ld.gold?

~~~
zvrba
Oh, I wasn't aware that it was multithreaded. I just found out about it now.

Did you benchmark gold to find out how much MT speeds up linking?

~~~
krasin
I didn't make precise benchmarking, but when used on a real-world codebases,
it speeds up linking about 2x.

One trick to know: never make ld.gold the default system linker, because there
would always be awkward kernel modules which will be corrupted at some point,
because they would rely on ld.bfd.

Instead, it's recommended to specify -fuse-ld=gold in the command line for
your code, see [https://gcc.gnu.org/onlinedocs/gcc/Link-
Options.html](https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)

------
userbinator
I didn't find any mention about the speed of the _output_... so I wonder if
they just disabled the optimiser completely.

TCC is an extremely fast C compiler because it doesn't do _any_ optimising at
all.

~~~
yrnkrn
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.

------
ginko
So they forked Clang into their own closed source version?

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

~~~
geon
> 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.

~~~
yrnkrn
We frequently merge with llvm svn, last time three days ago. It is a pain but
that's the price to keep up with such a dynamic project. We do upstream
enhancements and bug fixes for clang and LLVM code, see the {cfe,llvm}-commits
mailing lists.

------
Coding_Cat
From their test cases, Qt 5 to be specific:

>Initial compilation took 28.53 seconds in Zapcc, and 41 seconds in Qt
Creator.

>Thereafter, re-compilations took 1.15 seconds in Zapcc, and 12 seconds in Qt
Creator.

This doesn't fill me with much fate in their other statements. Qt Creator is
not a compiler, it is an IDE and can be set up to use a variety of compilers.

------
mmozeiko
Here's some info on clang mailing-list from zapcc author:
[http://lists.cs.uiuc.edu/pipermail/cfe-
dev/2015-May/043174.h...](http://lists.cs.uiuc.edu/pipermail/cfe-
dev/2015-May/043174.html)

------
hendzen
see the zapcc developer's post on clang.devel:

[http://article.gmane.org/gmane.comp.compilers.clang.devel/42...](http://article.gmane.org/gmane.comp.compilers.clang.devel/42950)

------
DannyBee
This is mostly a waste of time. C++ modules will do the same thing when they
are completely finished (folks i work with are the ones doing it, and it is
very far along), and will be standardized, etc.

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

~~~
DannyBee
Both :)

------
EliRivers
I typically use ccache on Linux, which does the headline feature of this. If
there's a Zapcc rep here, how does Zapcc compare? Is the precompiled header
feature a big improvement?

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

[http://www.zapcc.com/case-studies/compiling-
boost/](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.

~~~
yrnkrn
You are correct, zapcc should be compared only to clang from the same svn.
clang to gcc is another matter altogether.

Even in first compilation, zapcc will cache between the first and second files
compiled. The only case where there is no caching is when zapccs starts or re-
startes, for example when compilation flags are changed.

------
throwawayaway
anyone know if it uses warp?

[https://code.facebook.com/posts/476987592402291/under-the-
ho...](https://code.facebook.com/posts/476987592402291/under-the-hood-warp-a-
fast-c-and-c-preprocessor/)

~~~
vinkelhake
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](https://news.ycombinator.com/item?id=7489532)

~~~
throwawayaway
how interesting, thank you very much.

~~~
yrnkrn
Note warp commits, the project is not too active. Maybe it's mature enough and
requires few updates, I don't know as zapcc uses the clang Preprocessor and
not warp.

[https://github.com/facebook/warp/commits/master](https://github.com/facebook/warp/commits/master)

