What is Zapcc?
Zapcc is a C++ compiler based on clang, designed to perform faster compilations.
What is the status of Zapcc?
Zapcc 1.0 is now available.
How are you testing Zapcc?
We use internally-written tests with the LLVM LIT testing tool and build bots with many open-source libraries and projects including Boost, Clang/LLVM, deal.II, Eigen, Folly, Mesos, MongoDB, OpenCV, Paraview, PCL, POCO, Quantlib, QT, Trilinos, VCSN, Webkit and more.
Will you make performance numbers available?
Yes, benchmarks here.
Do you sacrifice runtime performance?
No. From the various tests we run, run-time performance of Zapcc generated code is equivalent to the code generated by clang. Benchmarks here.
Is Zapcc Clang compatible?
Yes. We frequently merge zapcc with the latest clang svn.
Is Zapcc GCC compatible?
Yes, to the extent clang is gcc compatible.
Do you support the sanitizers?
My project does not compile with Zapcc!
Please make sure first your project compiles successfully with Clang. If your project does not compile with Clang, Zapcc, being based on Clang, will not be able to compile any more than clang.
Which operating systems do you support?
We have released Zapcc for Linux x64.
MacOS and Windows x64 / Visual C++ compatible versions are in progress.
What is the “trick”?
There is no “trick”. Zapcc uses in-memory compilation cache in client-server architecture, remembering all compilation information between runs. ‘zapcc’ is the client while ‘zapccs’ is the server. Each zapcc run will reuse an existing server, or if none available will start a new one.
How is it different from precompiled headers?
Precompiled headers requires building your project to the exact precompiled headers rules. Most projects do not bother with using precompiled headers. Zapcc works within your existing build.
Precompiled headers are currently ignored by Zapcc.
How much memory does Zapcc use?
To avoid killing the server by using endless memory, Zapcc has a memory limit and will automatically reset after reaching it, restarting with an empty cache and low memory usage. The memory limit is set under [MaxMemory] at bin/zapccs.config, and you can change it to optimize memory usage and the number of servers (“make -j”) you plan to use. Usually, you should not set the -j parameter to more than the number of physical cores + 1. This is especially important for Intel CPU with hyper-threading enabled, which report twice the number of physical cores. In such cases, Zapcc is likely to run faster with less servers, each using a higher memory limit.
Memory is quite cheap and we recommend allocating enough physical memory to all Zapcc servers you would like to run.
How do I free the memory Zapcc uses?
To kill all servers at once run
zapcc -cc1 -reset-server
Do you rely on ccache, distcc, warp or the like?
Is all compiled code cached? If so, how can I modify source files and recompile?
Files listed under the [Mutable] section of bin/zapccs.config are not cached. By default this includes *.c, *.cc, *.cpp, *.cxx and some macro-dependent header files from various libraries.
By how much do you expect Zapcc to accelerate compilation times?
This depends on the complexity of the header files vs. the complexity of the source files. It can range from no acceleration at all for plain C projects to x2-x5 for build-all of heavily templated projects, up to cases of x50 speedups in developer-build incremental change of one file.
As a reference number, Zapcc accelerates clang build-all about x2 faster compared to building clang using clang.
Will Zapcc accelerate C projects as well?
Optimization Tip: Build shared and static configurations separately
Some build system build each file both for shared and static configurations, in the following order:
- File 1 static
- File 1 shared
- File 2 static
- File 2 shared
The change from static to shared and vice verse invalidates the Zapcc cache on every compile, resulting in bad build performance. To solve this, build the different configurations separately, for example
>configure --disable-shared && make && configure --disable-static && make
Similarly, try not to change other flags between compilations as most flag changes will result in a cache invalidation and reset.
Optimization Tip: Headers dependent on macros
Headers that depend on changing macros which may change during compilations will result in cache resets and performance hits. Consider defining macros in command line to make sure consistent definition throughout the cache. For example, for Boost.Threads:
zapcc *.cpp -DBOOST_THREAD_PROVIDES_CONDITION -DBOOST_THREAD_USES_DATETIME
Why did you create Zapcc?
We love C++. It’s one of the best programming languages out there. However, C++ compilations are getting longer and longer, due to the complexity of the language and especially due to templated header files. We identified an opportunity to improve, and that is why we started developing Zapcc.
Who’s behind this project?
A team led by Yaron Keren and Ophir Herbst, seasoned high tech entrepreneurs. The company is Ceemple Software Ltd., based in Israel.
If there is anything else you wish to know, please don’t hesitate contacting us.