Zapcc Still Aiming For "Super Fast" Compiler Performance

[phoronix]

Phoronix: Zapcc Still Aiming For "Super Fast" Compiler Performance

It's been a while since last covering Zapcc as a new, super-fast C/C++ compiler yet it has evolved and now the latest beta is reporting to show even more impressive performance gains...

http://www.phoronix.com/scan.php?page=news_item&px=Zapcc-Compiler-Perf-2016

[andrebrait]

I believe those numbers... but how fast are the binaries? Compiling fast is cool, but not so much if the binaries end up being as slow...

[DMJC]

I believe the numbers, but is the compiler any good? LLVM/clang at least tell me where the bugs in the code are. I'd rather tools that help troubleshoot....

[cb88]

I believe the numbers, but is the compiler any good? LLVM/clang at least tell me where the bugs in the code are. I'd rather tools that help troubleshoot....

This is a modified version of LLVM/Clang as far as I know... I think it uses a more optimal in memory representation to implement in memory caching. Thats its main feature over stock llvm/clang anyway...

[andrebrait]

This is a modified version of LLVM/Clang as far as I know... I think it uses a more optimal in memory representation to implement in memory caching. Thats its main feature over stock llvm/clang anyway...

I totally missed this part of the article. I'll be interesting, then.

[Kemosabe]

What's the point of private beta? Is it closed source or sth?

[discordian]

From the description it sounds like it does a similar thing like ccache. the gains seem primary to come from the caching, given how big the fluctuations between runs are.

it makes sense to implement this within the compiler vs. guessing from the outside ala ccache. selling this as "compiler performance" is bogus though

[discordian]

Why is it bogus to sell it as compiler performance?

You know how ccache works?
It looks at compiler parameters and hashes sourcefile, then it looks this ups in a cache, if it finds an entry it doesnt compile the sources, but just copies over the result from a previous run. The compiler doesnt even get executed, hence its not compiling faster, but compiling gets skipped.

As far as I understand, Zapcc integrates this behaviour into clang. Which is fine and leads to faster builds.
But then I could use ccache with unmodfied clang and get a 3-10 times speedup aswell - without touching clang at all! I hope you agree that using ccache is not making clang more performant.

Btw, Zapcc vs ccache & clang would be a fitting test

[geearf]

You know how ccache works?
It looks at compiler parameters and hashes sourcefile, then it looks this ups in a cache, if it finds an entry it doesnt compile the sources, but just copies over the result from a previous run. The compiler doesnt even get executed, hence its not compiling faster, but compiling gets skipped.

As far as I understand, Zapcc integrates this behaviour into clang. Which is fine and leads to faster builds.
But then I could use ccache with unmodfied clang and get a 3-10 times speedup aswell - without touching clang at all! I hope you agree that using ccache is not making clang more performant.

Btw, Zapcc vs ccache & clang would be a fitting test

I thought so too at first but it's more complicated than that.
ccache would not improve performance in the first run, but this does, so it goes beyond what ccache does.

[discordian]

Depends on how you define "run". at work our project has a 3 times speedup Un the first build, thats primary because multiple components use the same source library.

and sure they can do mire than ccache, like figuring out which defines influence an output, or even break up files in smaller parts or cache parsed headers. it is still a cache between invocations, and they dont do "work" faster - they skip it