[MPlayer-dev-eng] [RFC] Makefile copyrights

[Michael Niedermayer]

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:
> > > > On Wed, Jun 18, 2008 at 01:27:37AM +0200, Diego Biurrun wrote:
> > > > > On Tue, Jun 17, 2008 at 07:39:31PM +0200, Michael Niedermayer wrote:
> > > > > > On Tue, Jun 17, 2008 at 02:57:16PM +0200, Diego Biurrun wrote:
> > > > > > > On Sat, Jun 07, 2008 at 04:11:34PM +0200, Michael Niedermayer wrote:
> > > > > > > > 
> > > > > > > > * Its faster to build a .a per directory and then combine them than collect
> > > > > > > >   all .o files if one changed. (simple matter of less collecting
> > > > > >                    ^^^^^^^^^^^^^^
> > > > > > > >   recompile one c file collect all .o of one dir collect all .a vs.
> > > > > > > >   recompile one c file collect all .o of the whole project)
> > > > > > > >   seeks are slow reading lots of files is slower than reading one
> > > > > > > >   big one ...
> > > > > > > 
> > > > > > > This is not true.
> > > > > > > 
> > > > > > > I just did a quick benchmark comparing r26339 with HEAD.  I configured
> > > > > > > both trees with the same options and then ran make in them.  After that
> > > > > > > I ran 'rm mplayer mencoder' and then 'time make' in both trees in order
> > > > > > > to benchmark just the last linking step.  Results vary by 0.1 seconds,
> > > > > > > but both are always around 9.8s.
> > > > > > 
> > > > > > Not sure about you, but i do change some c files between running make.
> > > > > > Also not everything might be in the disk cache like it is in your 
> > > > > > make; rm mplayer; make
> > > > > > Id be more interrested in the results with a changed c file and a flushed
> > > >                                                                 ^^^^^^^^^^^^^
> > > > > > cache. (and changed means not a change that has been compiled in the past
> > > >     ^^^^^
> > > > > > and is in ccache)
> > > > > 
> > > > > Once more, this time with ccache disabled.  I do
> > > > > 
> > > > > touch libmpdemux/demuxer.c libmpcodecs/vd.c && time make
> > > > > 
> > > > > and the results are that HEAD with dependency generation disabled takes
> > > > > 14s, r26339 takes 15.4s.  Accept it, link times have decreased.
> > > > 
> > > > A normal development cycle is to edit a c file run make
> > > > perform some tests & benchmarks (maybe the regression tests in ffmpeg)
> > > > these will flush the cache if it hasnt been flushed by the time due to
> > > > other things running, then goto 1.
> > > > 
> > > > 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 ...


> "Collecting" big files may well be faster in theory, but in practice it
> is faster to link all the small files directly.  The latter is also
> simpler.
> 
> What you may be overlooking is that you get extra linking stages in
> between.  First you have to link the .a files, then you have to link the
> final binaries.

only 1 c file changes thus only one .a file needs relinking ...


[...]
> > > > * How to use the new shiny build system?
> > > > -  comment out the last line in the MPlayer Makefile or the last line
> > > >    of common.mak in FFmpeg
> > > > 
> > > > Glad, its not as hackish anymore as it was in the past.
> > > 
> > > It is working correctly now, which it did most definitely *not* do in
> > > the past.  Also, it now automatically generates dependency information.
> > > You know, some people do find this useful and this was a requested
> > > feature.  auto* does it as well.  If you dislike automatic dependency
> > > information generation, disable it.
> > > 
> > > What's your problem?  I don't think commenting out one line is asking
> > > too much of you, is it?
> > 
> > My problem is that having to comment out lines in a file for normal everyday
> > work is a very hackish solution.
> > 
> > make mplayer_nodep or any other command line based solution would be alot
> > cleaner
> 
> Now we are talking.  Why not start out constructively in the first
> place?  I shall look into it.

thanks.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20080618/6ed2158a/attachment.pgp>