[x264-devel] [PATCH] build: Generate dependency information as a side-effect of compilation

[Steven Walters]

On Tue, May 6, 2014 at 8:21 AM, Diego Biurrun <diego at biurrun.de> wrote:
> On Sat, May 03, 2014 at 12:20:18PM -0400, Steven Walters wrote:
>> On Sat, May 3, 2014 at 10:30 AM, Diego Biurrun <diego at biurrun.de> wrote:
>> > This allows updating dependency information each time a file is changed,
>> > instead of creating dependency information once at the first build. In the
>> > latter case, dependency information is not updated each time a file is
>> > changed so that it can get out of date quickly.
>> > ---
>>
>> The frequency into which files include more additional headers
>> (dependencies expand), where this is actually beneficial is not that
>> prevalent on the project.
>> Also, this noticeably degrades the performance of building with ICL
>> (and similarly MSVS) where dependency generation is considerably
>> slower than gcc.
>>
>> As such, I'm not sure as to the worth of this.
>
> You value speed over correctness?  Seriously? :)
>
> How much of a performance hit are we talking about anyway?  And does
> anybody care?  x264 takes two minutes to build on my notebook from
> the days of yore, 15 seconds on my multicore build host.
>
> Do you care about building in 16 seconds and are willing to tolerate
> occasional incorrect builds in exchange?  In my experience build systems
> with incorrect dependency generation lead to people building from scratch
> all the time instead of trusting the correctness of rebuilds.  This of
> course takes much, much longer than the extra cycles spent on dependency
> generation.

My argument is that you're (over?) engineering the build system for
the possibility of something occurring that isn't really that likely
anymore.
If the project was in a younger state (more volatile) then I would be
more inclined to accept this change despite the performance
implications.
But since the frequency of dependencies actually getting out of date
these days is nearly non-existent at this point, I really don't see
the point of this.
(I say you're designing for an edge case)

>
> Most importantly, dependencies are already getting generated right now.
> So currently everybody is paying the cost of dependency generation every
> time x264 gets built.  And lo and behold, generating dependencies as a
> side-effect of compilation is quicker.  On my slow notebook build times
> decrease from 1m15s to 1.13s with --disable-asm --disable-opencl (used
> in order to mask out time spent assembling and running Perl scripts).

This is under the assumption that dependency generation CAN be
generated as part of the actual compilation,
which it can not be for all compilers (such as MSVS).
MSVS is already slow to build with, making it even slower is rather undesirable.

>
> I tested with gcc 4.8 and I remain sceptical that build times actually
> increase with ICL.  In the current system ICL also has to generate deps
> in the beginning.  You claim that processing files two times is faster.
> Benchmarks or it does not exist ;-p

I'll try and get these sometime, probably not this week though.

>
> Anyway, I'll update this patch again.  Generating dependencies for .asm
> files is probably overkill and does slow down the build slightly since
> it's done separately and not as a side-effect of assembling.
>
> Diego
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel