Zapcc 1.0 Compiler Announced

[phoronix]

Phoronix: Zapcc 1.0 Compiler Announced

Several times in the past we have covered Zapcc as an LLVM Clang based compiler focused on very fast compilation speeds. Zapcc 1.0 has been released today...

http://www.phoronix.com/scan.php?page=news_item&px=Zapcc-1.0-Announced

[pal666]

so they took llvm code and made it closed source?

[discordian]

Sounds way less sophisticated than I imagined. Some benchmarks vs clang & ccache would be interesting.
I was able to speedup our builds by a factor 3 with ccache, just be ensuring that no absolute paths are used.

[wizard69]

No mention of the RAM in the system! Makes me wonder how much improvement one would see adding a RAM drive to a CLang box.

[wizard69]

so they took llvm code and made it closed source?

Sorta looks that way! This especialy considering that the execution bemchmarks are for all purposes identical!

[linuxgeex]

No mention of the RAM in the system! Makes me wonder how much improvement one would see adding a RAM drive to a CLang box.

If you have enough ram and enable FS write-through caching, turn off fences/partitioning/journaling, and use an SSD for swap, then you are for all intents running your build system in a ramdisk, and that's a perfectly sane system configuration if you are only using that machine for building or other volatile work and could care less if data is lost due to a powerfail. But I'm pretty sure they have more going on than just filesystem caching.

During compilation a lot of work goes into building various symbol/syntax trees. Those trees are generally thrown away every time the compiler exits. With large C projects that isn't such a big deal because a well designed project will have broken itself down into files averaging no more than 200 lines per file, so for a 1M line project if you modify one function and recompile then you're only really dealing with 0.2% of the project's code and you realize a 50,000% speedup rebuilding it. Linking it can be another story.

For C++ those trees represent a lot more work. There's been various projects to try to hang onto some of that work to accelerate compilation. I'm pretty sure zapcc is doing an exceptional job of hanging onto that work... again it's not about caching the files, it's about caching parts of the work which has been done on those files, above and beyond hanging onto object files and symbols for linking.

Anything that reduces the test-edit-compile round-trip-time is brilliant, proprietary or not. Sometimes OSS leads, sometimes proprietary leads, I don't care, lol so long as the end result is we spend less time waiting. :-)

[tssva]

so they took llvm code and made it closed source?

They did not. They used the LLVM code as allowed under the 3 clause BSD style license the LLVM project purposely selected. The open source status of any LLVM project code did not change.

[caligula]

Sounds way less sophisticated than I imagined. Some benchmarks vs clang & ccache would be interesting.
I was able to speedup our builds by a factor 3 with ccache, just be ensuring that no absolute paths are used.

The biggest advantage is incremental compilation. C/C++ have a crappy grammar for fast parsing and no real module system, which results in extra work dealing with headers. If you fix the grammar and introduce proper modules that can be merged to the whole program AST in an idempotent way, you get optimal results. But this needs a language change. Take a look at this

http://users.monash.edu/~damian/papers/PDF/ModestProposal.pdf

[caligula]

During compilation a lot of work goes into building various symbol/syntax trees. Those trees are generally thrown away every time the compiler exits. With large C projects that isn't such a big deal because a well designed project will have broken itself down into files averaging no more than 200 lines per file, so for a 1M line project if you modify one function and recompile then you're only really dealing with 0.2% of the project's code and you realize a 50,000% speedup rebuilding it. Linking it can be another story.

It all boils down to what kind of macros you are using. The preprocessor system is really problematic wrt calculating dependencies. There's previous work on this, some guys tried optimizing the GCC years ago. Look at the previous GCC summit papers.

[caligula]

No mention of the RAM in the system! Makes me wonder how much improvement one would see adding a RAM drive to a CLang box.

Having such an in-memory compiler state doesn't necessarily use more memory at all. The problem is, if you recompile, what to do with the obsolete AST and object code generated with outdated files not available anymore on disk. It needs some sort of garbage collection for that.