[MPlayer-dev-eng] speed of link strategies (was: Re: [RFC] Makefile copyrights)
Michael Niedermayer
michaelni at gmx.at
Thu Jun 19 13:46:37 CEST 2008
On Thu, Jun 19, 2008 at 11:29:34AM +0200, Diego Biurrun wrote:
> On Wed, Jun 18, 2008 at 07:52:56PM +0200, Michael Niedermayer wrote:
> > On Wed, Jun 18, 2008 at 04:27:49PM +0200, Diego Biurrun wrote:
> > > On Wed, Jun 18, 2008 at 03:44:18PM +0200, Michael Niedermayer wrote:
> > > > On Wed, Jun 18, 2008 at 02:31:34PM +0200, Diego Biurrun wrote:
> > > > > On Wed, Jun 18, 2008 at 02:56:37AM +0200, Michael Niedermayer wrote:
> > > > > >
> > > > > > Besides, "HEAD with dependency generation disabled"? so you compare the
> > > > > > unchanged old build system against the new + some hacks to make it faster?
> > > > >
> > > > > I am comparing apples to apples. Your first claim was that link times
> > > > > would increase with the new system. This is false.
> > > >
> > > > I was speaking about the case with a changed file and not everything in the
> > > > cache. Collecting many small .o files takes longer than few big .a.
> > > > It may very well be that the old build system did other time consuming things.
> > > > I was only considering the current build system with per libmp* .a vs the
> > > > single big linking at the end.
> > >
> > > You are wrong. I ran benchmarks for the very case you are describing.
> >
> > You did not run benchmarks for the actual link commands, ccache disabled,
> > 1 file changed and a fluhed cache.
> > You run benchmarks on current (+hack) vs. old make. When the hack was removed
> > old was already faster ...
>
> Old was slightly faster because it did less things.
>
> Here are benchmarks for the final link commands and the subdirectory
> link commands. The first number is the "stabilized" number I get after
> rerunning the command multiple times, the second value was obtained
> after running some long grep command through my sources directory to
> flush the disk cache.
>
> HEAD:
> mplayer [...] 13.8s
> mencoder [...] 10.4s
>
> r26339:
> mplayer [...] 5.2s
> mencoder [...] 6.1s
Thank you for the benchmarks, these numbers are more belivable.
[...]
>
> Given that there are a total of 25 subdirectories to link, total link
> times should have diminished with the new system when running a complete
> build from a cold cache.
I dont really care if a full build takes 36m41s or 36m25s. I do care if
each rebuild after testing takes 13.8s instead of 5.2s
[...]
> The conclusion seems to be clear: Total link times have been reduced by
> the flat build system. Rebuild link times are within 1s of the old
> system on a very outdated machine.
very outdated machine with RAID array ...
besides you are forgetting the most important values in your benchmark above
> Adding complexity to the build
> system to make up for that 1s is not worth any trouble.
Maybe not, but making up for that 50% speedloss might be. But then goals
change, features and performance may not be amongth them anymore.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080619/b623f10b/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list