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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@xxxxxxxxxxxx https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng