An update status on this.
I forgot to mention some needed ccache configuration :
- ccache -o sloppiness=time_macros
- ccache -o run_second_cpp=true
I'll will push a new PR to handle this.
The first builds passed with it set manually on a build node with excellent results !
A make check job is now passing in 14mn instead of 55mn !
----- Mail original -----
De: "Erwan Velu" <evelu@xxxxxxxxxx>
À: "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx>
Envoyé: Jeudi 28 Juin 2018 19:04:42
Objet: Re: Improving the build performance
After a review with Kefu, it appear the BUILD_DATE is perfectly useless here.
So only this part is necessary to get the ccache working better:
export SOURCE_DATE_EPOCH=$(date +%D |date -f- +%s);
----- Mail original -----
De: "John Spray" <jspray@xxxxxxxxxx>
À: "Erwan Velu" <evelu@xxxxxxxxxx>
Cc: "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx>
Envoyé: Jeudi 28 Juin 2018 16:12:44
Objet: Re: Improving the build performance
On Thu, Jun 28, 2018 at 3:03 PM Erwan Velu <evelu@xxxxxxxxxx> wrote:
>
> Hi Folks,
>
> I've been wondering why the ccache was that inefficient on the CI.
> It appear and that is confirmed by local builds that two consecutives builds of the exact same code leads to < 1% of cache hit.
> This is actually a very bad cache performance : As the cache hit is very low, the needed time to create the cache is not compensated, leading to a 10% loss of performance regarding a build without ccache.
>
> C and C++ are usually providing much better results.
> This kind of misses in the cache are usually tied to some little variations introduced at compilation times like a sha1 or a timestamp (__DATE__ or __TIME__ or similar).
> Thanks to the wonderful project from debian to get reproducible builds (https://wiki.debian.org/ReproducibleBuilds) it is possible to enforce a particular setup at build time (https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal).
>
> I've been trying that on my testing host with a very nice result:
> - before, make takes 33mn with -j 24 (the user time is reported to 630mn).
> - after , make takes 7mn with -j 24 (the user time is reported to 77mn)
Wow, that's huge! Nice work!
John
>
> This is a nearly a 5x speedup on the whole process which includes non cachable stuff like linking or npm stuff.
>
> To achieve that, I've been setting up SOURCE_DATE_EPOCH & BUILD_DATE like :
> export SOURCE_DATE_EPOCH=$(date +%D |date -f- +%s);
> export BUILD_DATE=$(date --utc --date=@${SOURCE_DATE_EPOCH} +%Y-%m-%d)
>
> In this example, the SOURCE_DATE_EPOCH is the current day. Unless this variable is redefined, the same source code will hit the cache.
> This example is taken from a PR for the CI (https://github.com/ceph/ceph-build/pull/1058) where I wanted to get a cache being valid only for a day.
>
> Note that if the Ceph code is changing too much, the cache have to be partially or totally repopulated. From the tests I run, it usually goes between 0 & 50% of speedup in such case.
> To increase the cache efficiency, some could want to call do_cmake with ARGS='-D ENABLE_GIT_VERSION=OFF' to avoid having the git hash in the ceph_ver header.
>
> These two little changes improves significantly the local build time and will do soonish also on the CI (https://github.com/ceph/ceph-build/pull/1058) where I expect a great speedup !
>
> Erwan,
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
