hi Summary: to cache data, the code stream/cache2.c forks a subprocess (on all archs but win32); while trying to debug some Debian bugs, I have come to the conclusion that this does create some of the problems I was seeing. So I attach a patch that uses pthreads instead. Please test it (I did not test the code for Windows against regressions). ---- Lets see in particular http://bugs.debian.org/396962 The problem here is that $ gmplayer http://robots.stanford.edu/movies/sca80a0.avi hangs. My impression is this: after the fork, there are two signal handler around; then there is a bug in the codec (or in the gmplayer GUI) that triggers a signal from the Xlibs; but it gets caught in the wrong signal handler; from there on , mayhem. After applying my patch, gmplayer can play that AVI w/o problems. ---- a similar bug is triggered by http://sam.zoy.org/zzuf/lol-mplayer.avi and again this patch somehow works around it ---- Another good effect of this patch is that it is easier to debug the cache code. When I tried to debug the above bugs, I had to have two gdb sessions; and I had quite a few problems (there is some bug in GDB that crashes it when I try to attach to another process). With my patch, you just need to open one gdb session, and set breakpoints in it, and that is all. bye a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous, http://www.securityfocus.com/columnists/420
On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
a similar bug is triggered by http://sam.zoy.org/zzuf/lol-mplayer.avi
and again this patch somehow works around it
You see a bug with that? When I try to play it MPlayer simply fails to open it. I tried with cache enabled now, no difference. Have you tested with current svn or only the older Debian package?
hi Uoti Uoti Urpala ha scritto:
On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
a similar bug is triggered by http://sam.zoy.org/zzuf/lol-mplayer.avi
and again this patch somehow works around it
You see a bug with that? When I try to play it MPlayer simply fails to open it. I tried with cache enabled now, no difference. Have you tested with current svn or only the older Debian package?
to see this bug, I have to run $ gmplayer http://sam.zoy.org/zzuf/lol-mplayer.avi $ gmplayer http://robots.stanford.edu/movies/sca80a0.avi on a i386 , streaming from the server, and with gmplayer (not mplayer); and try them a few times when it fails, I see that one of the two processes has died, and the other is still around, and the windows are unresponsive moreover, when you kill gmplayer, you see many lines such as Xlib: sequence lost (0x1017d > 0x17d) in reply type 0x0! Xlib: unexpected async reply (sequence 0x32a)! Xlib: unexpected async reply (sequence 0x3d2)! Xlib: unexpected async reply (sequence 0x3d4)! Xlib: unexpected async reply (sequence 0x43b)! a.
On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
My impression is this: after the fork, there are two signal handler around; then there is a bug in the codec (or in the gmplayer GUI) that triggers a signal from the Xlibs; but it gets caught in the wrong signal handler; from there on , mayhem.
The forked process should be separate and there should be no way for a signal to be delivered "to either process" arbitrarily. The cache process shouldn't be running any Xlib code (if it is that's already broken). So I think this explanation for the problem is flawed or at least incomplete.
On Sat, Jan 27, 2007 at 02:04:16AM +0200, Uoti Urpala wrote:
On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
My impression is this: after the fork, there are two signal handler around; then there is a bug in the codec (or in the gmplayer GUI) that triggers a signal from the Xlibs; but it gets caught in the wrong signal handler; from there on , mayhem.
The forked process should be separate and there should be no way for a signal to be delivered "to either process" arbitrarily. The cache process shouldn't be running any Xlib code (if it is that's already broken). So I think this explanation for the problem is flawed or at least incomplete.
I agree. The beauty of MPlayer's cache code is that it works (or it's supposed to work; off_t larger than system wordsize puts a nasty kink in it..) without heavy thread-synchronization mechanisms, just simple processes with shared memory. I suspect linking to and initializing theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss. In any case I insist on any thread use being optional because I cannot use a version that requires threads, and the requirement of threads precludes porting to certain systems. Rich
hi Rich Rich Felker ha scritto:
I agree. The beauty of MPlayer's cache code is that it works (or it's supposed to work; off_t larger than system wordsize puts a nasty kink in it..) without heavy thread-synchronization mechanisms, just simple processes with shared memory. I suspect linking to and initializing theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss. In any case I insist on any thread use being optional because I cannot use a version that requires threads, and the requirement of threads precludes porting to certain systems.
wait wait wait. There is no "requirement of threads" ; if ./configure does not set HAVE_PTHREADS then the forking code will be used So you can still compile mplayer in any architecture that is not offering pthreads, as you did before. (I cheched this fact by manually unsetting HAVE_PTHREADS in config.h and recompiling). note that you cannot port the 'forking code' to some architectures as well: it uses code in osdep/shmem.c that needs HAVE_SHM so with my patch you can use caching code in mplayer in system that either HAVE_PTHREADS or HAVE_SHM ; w/o my patch, you can only do that if HAVE_SHM If some people do not like using pthreads at all, I can rewrite the patch to have yet another conditional CACHE_USE_PTHREADS so that my code can be disabled even when pthreads are available. a.
hi Rich Rich Felker ha scritto:
On Sat, Jan 27, 2007 at 02:04:16AM +0200, Uoti Urpala wrote: I agree. The beauty of MPlayer's cache code is that it works (or it's supposed to work; off_t larger than system wordsize puts a nasty kink in it..) without heavy thread-synchronization mechanisms, just simple processes with shared memory. I suspect linking to and initializing theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss.
you are inexact in some important points in your reasoning here. Here are some detailed clarifications: ----- point 1
I suspect linking to and initializing theads when they're not needed
when you run ./configure , there is already a snippet of code that tests for pthreads : vvvvvvvv if test "$_pthreads" = yes ; then _res_comment="using $_ld_pthread" _def_pthreads='#define HAVE_PTHREADS 1' _def_threads='#define HAVE_THREADS 1' else _res_comment="v4l, vo_gl, ao_alsa, ao_nas, ao_macosx, win32 loader disabled" _def_pthreads='#undef HAVE_PTHREADS' _nas=no ; _tv_v4l1=no ; _macosx=no if not mingw32 ; then _win32=no fi fi echores "$_pthreads" ^^^^^^^^ so, in any running mplayer around, pthreads (when available) are already linked in my caching code is not adding a linking to pthreads to mplayer ; it is just using it ---- point 2 look into http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html there is no command pthread_initialize() to use threads, you just link the library in, and pthread_create() as needed I tested with a simple two line program : if gcc -g -lpthread test.c -o test then 'info thread' in gdb reports one thread; if otherwise I do not put -lpthread, 'gdb info thread' does not report anything; so the mere fact of linking to -lpthread is already initializing the NPTL system if you gdb mplayer in linux, and 'info thread', you will see that 'mplayer' has one thread : so the pthreads are already initialized
I suspect linking to and initializing
theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss.
this said, I do not know if pthread_create() adds a nasty locking mechanism in malloc ----- point 3
heavy thread-synchronization mechanisms
there is no explicit thread-sync mechanism in my code the caching code was designed to work w/o interprocess (or interthread) synchronization mechanisms so my patch does it that way --------- regarding performance ... I will do a test later today; but I would be really surprised if I see a performance penalty: I didn't ever hear that NTPL threading has a performance loss versus having two processes ... I Googled around a bit and found that NPTL is indeed quite fast: e.g. http://lwn.net/Articles/10710/ "(NGPT) implementation beat standard Linux threads by at least a factor of two in these tests. The NPTL library, however, beat NGPT by about a factor of four." (no mention of forks , but at least you can see that NPTL was designed to be quite fast) Other stuff I found Googling says that NPTL beats the speed out of other ways of doing concurrent computations. a.
Just a general remark, not a comment on the issue at hand. On Sat, Jan 27, 2007 at 10:20:39AM +0100, A Mennucc wrote:
I Googled around a bit and found that NPTL is indeed quite fast: e.g. http://lwn.net/Articles/10710/ "(NGPT) implementation beat standard Linux threads by at least a factor of two in these tests. The NPTL library, however, beat NGPT by about a factor of four."
IMO these kinds of numbers just shed a light on the inefficiency of the old implementation rather than on the efficiency of the new one. Diego
On Sat, Jan 27, 2007 at 10:32:54AM +0100, Diego Biurrun wrote:
Just a general remark, not a comment on the issue at hand.
On Sat, Jan 27, 2007 at 10:20:39AM +0100, A Mennucc wrote:
I Googled around a bit and found that NPTL is indeed quite fast: e.g. http://lwn.net/Articles/10710/ "(NGPT) implementation beat standard Linux threads by at least a factor of two in these tests. The NPTL library, however, beat NGPT by about a factor of four."
IMO these kinds of numbers just shed a light on the inefficiency of the old implementation rather than on the efficiency of the new one.
Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks. Rich
On Sat, 2007-01-27 at 10:09 -0500, Rich Felker wrote:
Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks.
Where did you get those numbers? On a 1837 MHz machine with up to date software this loop for (int i=0; i < 100000000; i++) { pthread_mutex_lock(&mut); pthread_mutex_unlock(&mut); } takes about 3.9 seconds. That means 72 cycles per loop, and less than 36 cycles per call - and that's with function call overhead included.
On Sat, Jan 27, 2007 at 05:45:20PM +0200, Uoti Urpala wrote:
On Sat, 2007-01-27 at 10:09 -0500, Rich Felker wrote:
Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks.
Where did you get those numbers?
Timing my spinlock implementation with an without the lock prefix on the xchg opcode, in a setting with no contention (no threads).
On a 1837 MHz machine with up to date software this loop
for (int i=0; i < 100000000; i++) { pthread_mutex_lock(&mut); pthread_mutex_unlock(&mut); }
takes about 3.9 seconds. That means 72 cycles per loop, and less than 36 cycles per call - and that's with function call overhead included.
Have threads actually been initialized yet? If not, the lock is probably a no-op. Rich
On Sat, 2007-01-27 at 15:41 -0500, Rich Felker wrote:
On Sat, Jan 27, 2007 at 05:45:20PM +0200, Uoti Urpala wrote:
On Sat, 2007-01-27 at 10:09 -0500, Rich Felker wrote:
Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks.
takes about 3.9 seconds. That means 72 cycles per loop, and less than 36 cycles per call - and that's with function call overhead included.
Have threads actually been initialized yet? If not, the lock is probably a no-op.
Yes, I had another thread which took the lock a couple of times just to make sure it was actually working. This was on uniprocessor Athlon (but the pthread_mutex_lock assembler still has the lock prefix so no tricks such as special-casing the library itself for uniprocessor). Some Google searches showed that on P4 the cost is likely higher but still below 100 cycles as opposed to "worse than a couple hundred cycles".
On Sat, 27 Jan 2007 15:41:08 -0500, Rich Felker said: On Sat, Jan 27, 2007 at 05:45:20PM +0200, Uoti Urpala wrote: On Sat, 2007-01-27 at 10:09 -0500, Rich Felker wrote: Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks.
Where did you get those numbers?
Timing my spinlock implementation with an without the lock prefix on the xchg opcode, in a setting with no contention (no threads).
Which CPU is this BTW? I've not found one yet where the lock prefix makes any timing difference for single threaded operations (I've checked various ages of Intel and AMD chips, including Pentium III, Athlon (5yrs old), Pentium IV, Core Duo, Athlon 64 X2). __Martin
On Sat, Jan 27, 2007 at 09:55:41PM +0000, Martin Simmons wrote:
On Sat, 27 Jan 2007 15:41:08 -0500, Rich Felker said: On Sat, Jan 27, 2007 at 05:45:20PM +0200, Uoti Urpala wrote: On Sat, 2007-01-27 at 10:09 -0500, Rich Felker wrote: Yes. It's not a matter of the implementation being fast or slow. It's fundamentally impossible to make synchronization fast. Each "lock" prefix requires a couple hundred cycles on my machine, and I'm told it's even worse on machines with higher clocks.
Where did you get those numbers?
Timing my spinlock implementation with an without the lock prefix on the xchg opcode, in a setting with no contention (no threads).
Which CPU is this BTW? I've not found one yet where the lock prefix makes any timing difference for single threaded operations (I've checked various ages of Intel and AMD chips, including Pentium III, Athlon (5yrs old), Pentium IV, Core Duo, Athlon 64 X2).
K6-III+. Chipset is some VIA thing IIRC. Rich
On Sat, Jan 27, 2007 at 10:20:39AM +0100, A Mennucc wrote:
there is no command pthread_initialize() to use threads, you just link the library in, and pthread_create() as needed
And pthread_create and similar calls in turn call an internal "pthread_initialize" type function if it hasn't already been called. If they don't, it means that the libc implementation is so bad that it penalizes performance in _all_ programs (even ones that don't use threads), which considering the badness of glibc is always a possibility...
I suspect linking to and initializing
theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss.
this said, I do not know if pthread_create() adds a nasty locking mechanism in malloc
Either it adds it, or it was already there to begin with.. Rich
hi Uoti Uoti Urpala ha scritto:
On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
My impression is this: after the fork, there are two signal handler around; then there is a bug in the codec (or in the gmplayer GUI) that triggers a signal from the Xlibs; but it gets caught in the wrong signal handler; from there on , mayhem.
The forked process should be separate and there should be no way for a signal to be delivered "to either process" arbitrarily. The cache process shouldn't be running any Xlib code (if it is that's already broken). So I think this explanation for the problem is flawed or at least incomplete.
yes, I had quite a hard time debugging bug http://bugs.debian.org/396962 and indeed I agree that my first explanation was probably flawed... it was just "my impression" here is another possible explanation ------------ I am debugging $ gdb gmplayer http://robots.stanford.edu/movies/sca80a0.avi put a break in line 120, in stream/tcp.c , at the command if(verb) mp_msg(MSGT_NETWORK,MSGL_STATUS,MSGTR_MPDEMUX_NW_ResolvingHostForAF, host, af2String(af)); that outputs the line Couldn't resolve name for AF_INET6: robots.stanford.edu and opens a window dialog to display the same line but then this is called again inside the caching code (and I do not understand why... this is indeed a flaw), and again tries to display Resolving robots.stanford.edu for AF_INET6... and open a dialog.... but! this time, the caching code is running in a separate process. Huge problem! you can Google around and find that in GTK and Xlib it is very dangerous to draw windows from two different forked processes. So the whole windowing code goes haywire. ---- So the reason that my patch for threaded caching works is that it is possible to open dialog windows from different threads. possible solutions: 1) make sure you do not ever ever display a dialog from the caching code 2) use pthreads I would suggest the 2nd :-) (as I explained in my other email, mplayer is already compiled to use pthreads in linux) a.
Hello, On Sat, Jan 27, 2007 at 10:30:30AM +0100, A Mennucc wrote:
So the reason that my patch for threaded caching works is that it is possible to open dialog windows from different threads.
possible solutions:
1) make sure you do not ever ever display a dialog from the caching code 2) use pthreads
I would suggest the 2nd :-) (as I explained in my other email, mplayer is already compiled to use pthreads in linux)
2) is not a solution to this problem it is a hack-around (or in German: a Würgaround). I think your suggestion has merits, but this problem is not one of them! Actually, I consider hiding a bug a point against a patch. Greetings, Reimar Döffinger
Hello, On Sat, Jan 27, 2007 at 11:15:30AM +0100, Reimar D?ffinger wrote:
On Sat, Jan 27, 2007 at 10:30:30AM +0100, A Mennucc wrote:
So the reason that my patch for threaded caching works is that it is possible to open dialog windows from different threads.
possible solutions:
1) make sure you do not ever ever display a dialog from the caching code 2) use pthreads
I would suggest the 2nd :-) (as I explained in my other email, mplayer is already compiled to use pthreads in linux)
2) is not a solution to this problem it is a hack-around (or in German: a Würgaround). I think your suggestion has merits, but this problem is not one of them! Actually, I consider hiding a bug a point against a patch.
Except that it breaks mencoder linking, attached patch is closer to a proper fix for that problem. Greetings, Reimar Döffinger
hi there was a discussion long ago regarding bug http://bugs.debian.org/396962 at that time, Reimar proposed a simple and effective patch (see message below) but that unfortunately would break mencode compilation I have revised his idea, see attached patch a. Reimar Döffinger ha scritto:
Hello, On Sat, Jan 27, 2007 at 11:15:30AM +0100, Reimar D?ffinger wrote:
So the reason that my patch for threaded caching works is that it is possible to open dialog windows from different threads.
possible solutions:
1) make sure you do not ever ever display a dialog from the caching code 2) use pthreads
I would suggest the 2nd :-) (as I explained in my other email, mplayer is already compiled to use pthreads in linux)
On Sat, Jan 27, 2007 at 10:30:30AM +0100, A Mennucc wrote: 2) is not a solution to this problem it is a hack-around (or in German: a Würgaround). I think your suggestion has merits, but this problem is not one of them! Actually, I consider hiding a bug a point against a patch.
Except that it breaks mencoder linking, attached patch is closer to a proper fix for that problem.
Greetings, Reimar Döffinger
(I deleted the attached patch of Reimar to avoid confusion - what follows is mine) a.
Hello, On Sat, Oct 06, 2007 at 06:28:38PM +0200, A Mennucc wrote:
there was a discussion long ago regarding bug http://bugs.debian.org/396962
at that time, Reimar proposed a simple and effective patch (see message below) but that unfortunately would break mencode compilation
I have revised his idea, see attached patch
Hmm... I actually had my own version still in my tree, a tiny bit simpler, and IMO putting the dummy use_gui into mp_msg slightly better solves the problem of confining hacks (since that FOR_MENCODER thing there is already a hack). Greetings, Reimar Döffinger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Reimar may you please add that to SVN ? a. Reimar Döffinger ha scritto:
Hello, On Sat, Oct 06, 2007 at 06:28:38PM +0200, A Mennucc wrote:
there was a discussion long ago regarding bug http://bugs.debian.org/396962
at that time, Reimar proposed a simple and effective patch (see message below) but that unfortunately would break mencode compilation
I have revised his idea, see attached patch
Hmm... I actually had my own version still in my tree, a tiny bit simpler, and IMO putting the dummy use_gui into mp_msg slightly better solves the problem of confining hacks (since that FOR_MENCODER thing there is already a hack). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHCJVk9B/tjjP8QKQRAmJSAKCh/rRmWwHpl8B2Mrs3YMiVNvz8ZwCfTzmA Y5cLmMd3YLmVVa1gsxH3MWk= =0Su9 -----END PGP SIGNATURE-----
Reimar Döffinger ha scritto:
Hello, On Sat, Jan 27, 2007 at 10:30:30AM +0100, A Mennucc wrote:
So the reason that my patch for threaded caching works is that it is possible to open dialog windows from different threads.
possible solutions:
1) make sure you do not ever ever display a dialog from the caching code 2) use pthreads
I would suggest the 2nd :-) (as I explained in my other email, mplayer is already compiled to use pthreads in linux)
2) is not a solution to this problem it is a hack-around (or in German: a Würgaround).
I think your suggestion has merits, but this problem is not one of them!
you are absolutely right. basically, we must add some code somewhere that will not open any dialog from the forked code. I will look into it. Whereas opening dialogs will be OK when the cache is threaded instead of forked: this is useful, so the caching code can report errors on the stream (closure of remote, underflow, blah blah) to the GUI a.
Hello, On Fri, Jan 26, 2007 at 11:42:14PM +0100, A Mennucc wrote:
Summary: to cache data, the code stream/cache2.c forks a subprocess (on all archs but win32); while trying to debug some Debian bugs, I have come to the conclusion that this does create some of the problems I was seeing. So I attach a patch that uses pthreads instead. Please test it (I did not test the code for Windows against regressions).
Please split the patch in separate parts. IMO e.g. the
-#ifndef WIN32 +#ifdef CACHE_FORKS
change is a good candidate to be applied first since I think it makes the code easier to understand anyway. I also think you can further reduce the size of the patch if you first change all #ifndef WIN32 to that, you a bit of the patch is just reordering code.
My impression is this: after the fork, there are two signal handler around; then there is a bug in the codec (or in the gmplayer GUI) that triggers a signal from the Xlibs; but it gets caught in the wrong signal handler; from there on , mayhem.
Certainly not, though it can happen that only one of the mplayer instances gets killed.
@@ -296,18 +341,24 @@ if(s->eof) break; // file is smaller than prefill size if(mp_input_check_interrupt(PREFILL_SLEEP_TIME)) return 0; + usec_sleep(100); // no use cycling like crazy while waiting
Unrelated and actually wrong. If mp_input_check_interrupt does not sleep at least PREFILL_SLEEP_TIME there is a bug somewhere else.
- if(!s->cache_pid) return stream_fill_buffer(s); + if(!CACHE_HAS_SUBPROCESS(s)) return stream_fill_buffer(s);
IMO just leave that as it is, with cache_pid always == 0 if forking isn't used. Greetings, Reimar Döffinger
hi Reimar Reimar Döffinger ha scritto:
Hello,
@@ -296,18 +341,24 @@ if(s->eof) break; // file is smaller than prefill size if(mp_input_check_interrupt(PREFILL_SLEEP_TIME)) return 0; + usec_sleep(100); // no use cycling like crazy while waiting
Unrelated and actually wrong. If mp_input_check_interrupt does not sleep at least PREFILL_SLEEP_TIME there is a bug somewhere else.
yes, my fault, I realized it just a few minutes ago a.
hi here are my benchmarks; I copied two files from samples.mphq.hu to my localhost for those the samples seem to show that the pthread version is faster --------------------------------- time $C -benchmark -vo null -ao null -nosound -quiet -endpos 20 http://localhost/MPlayer-samples/bench/cathedral-beta2-400extra-crop-avc.mp4 ----- C=./mplayer with pthread cache BENCHMARKs: VC: 4.679s VO: 0.008s A: 0.000s Sys: 0.179s = 4.866s BENCHMARK%: VC: 96.1519% VO: 0.1676% A: 0.0000% Sys: 3.6805% = 100.0000% real 0m5.750s user 0m4.828s sys 0m0.084s BENCHMARKs: VC: 4.687s VO: 0.008s A: 0.000s Sys: 0.164s = 4.858s BENCHMARK%: VC: 96.4716% VO: 0.1600% A: 0.0000% Sys: 3.3685% = 100.0000% real 0m5.746s user 0m4.864s sys 0m0.044s BENCHMARKs: VC: 4.657s VO: 0.009s A: 0.000s Sys: 0.177s = 4.842s BENCHMARK%: VC: 96.1671% VO: 0.1824% A: 0.0000% Sys: 3.6506% = 100.0000% real 0m5.715s user 0m4.824s sys 0m0.084s ----- C = mplayer with forking cache BENCHMARKs: VC: 4.738s VO: 0.007s A: 0.000s Sys: 0.167s = 4.913s BENCHMARK%: VC: 96.4465% VO: 0.1521% A: 0.0000% Sys: 3.4013% = 100.0000% real 0m5.456s user 0m4.888s sys 0m0.084s BENCHMARKs: VC: 4.765s VO: 0.006s A: 0.000s Sys: 0.155s = 4.926s BENCHMARK%: VC: 96.7271% VO: 0.1318% A: 0.0000% Sys: 3.1411% = 100.0000% real 0m5.428s user 0m4.932s sys 0m0.056s BENCHMARKs: VC: 4.747s VO: 0.007s A: 0.000s Sys: 0.165s = 4.919s BENCHMARK%: VC: 96.5031% VO: 0.1475% A: 0.0000% Sys: 3.3494% = 100.0000% real 0m5.430s user 0m4.884s sys 0m0.056s --------------------- time $C -quiet -benchmark -vo null -nosound http://localhost/MPlayer-samples/bench/test.b-frames.divx5.avi ----- C=./mplayer with pthread cache BENCHMARKs: VC: 2.653s VO: 0.009s A: 0.000s Sys: 0.093s = 2.755s BENCHMARK%: VC: 96.3166% VO: 0.3092% A: 0.0000% Sys: 3.3742% = 100.0000% real 0m3.672s user 0m2.848s sys 0m0.048s BENCHMARKs: VC: 2.778s VO: 0.010s A: 0.000s Sys: 0.128s = 2.915s BENCHMARK%: VC: 95.2842% VO: 0.3260% A: 0.0000% Sys: 4.3898% = 100.0000% real 0m3.930s user 0m2.880s sys 0m0.060s ----- C=./mplayer with forking cache BENCHMARKs: VC: 3.057s VO: 0.010s A: 0.000s Sys: 0.123s = 3.190s BENCHMARK%: VC: 95.8304% VO: 0.3084% A: 0.0000% Sys: 3.8612% = 100.0000% real 0m3.628s user 0m2.764s sys 0m0.060s BENCHMARKs: VC: 2.918s VO: 0.008s A: 0.000s Sys: 0.095s = 3.021s BENCHMARK%: VC: 96.5721% VO: 0.2728% A: 0.0000% Sys: 3.1551% = 100.0000% real 0m3.846s user 0m2.952s sys 0m0.068s ------------------------------ a.
Hello, On Sat, Jan 27, 2007 at 12:56:57PM +0100, A Mennucc wrote:
here are my benchmarks; I copied two files from samples.mphq.hu to my localhost for those
the samples seem to show that the pthread version is faster
Huh? The "time" values show nothing conclusive (and certainly nothing significant), though I do not know if they include the time of the forked process. Using something with a higher bitrate like lossless video might provide more useful data. The benchmark values are not worth anything for this, I don't think they properly include the time in the cache functions. Greetings, Reimar Döffinger
Reimar Döffinger ha scritto:
Hello, On Sat, Jan 27, 2007 at 12:56:57PM +0100, A Mennucc wrote:
here are my benchmarks; I copied two files from samples.mphq.hu to my localhost for those
the samples seem to show that the pthread version is faster
Using something with a higher bitrate like lossless video might provide more useful data.
can you suggest me a sample file?
The benchmark values are not worth anything for this, I don't think they properly include the time in the cache functions.
that was not the goal of my benchmark Rick was suggesting that
I suspect linking to and initializing theads when they're not needed could active nasty locking mechanisms in the C library (malloc, etc.) possibly causing performance loss.
my purpose in doing the benchmark is to test if some glibc calls may be slower [BTW: my opinion is that the cache code is not really relevant w.r.t. performance... it usually just wait in the usec_sleep , or in read()ing from the stream (if it is slow); moreover no one of my changes does really add or remove code in the caching code] so the only worry is: does threading slow down the rest of mplayer code ? (and I mean: in codecs, where it really hurts) by looking at the VC values, the answer IMHO is no
Huh? The "time" values show nothing conclusive (and certainly nothing significant) though I do not know if they include the time of the forked process.
the "real time" of the cathedral sample are usually 0.57s in the threaded version , and 0.54s in the forked version; whereas the VC time are 4.65 vs 4.75 ; so I guess that 'time' includes the time spent in the threaded process a.
On Sat, 2007-01-27 at 13:42 +0100, A Mennucc wrote:
[BTW: my opinion is that the cache code is not really relevant w.r.t. performance... it usually just wait in the usec_sleep , or in read()ing from the stream (if it is slow); moreover no one of my changes does really add or remove code in the caching code]
so the only worry is: does threading slow down the rest of mplayer code ? (and I mean: in codecs, where it really hurts)
IMO there is no need to benchmark; MPlayer does not use so many libc calls that extra locking would affect performance (or if it does then the code in question should be optimized regardless of thread use). The current cache code isn't very good (the constant sleep times break at high transfer rates with default cache size, it's not really safe without locking) and a threaded version would probably be better. However I don't see how just changing it to use a thread instead of a process with no other changes would give any major improvements. Is there still a reason why you want your previous patch applied (or why are you talking about benchmarks)?
participants (7)
-
A Mennucc -
debdev＠tonelli.sns.it -
Diego Biurrun -
Martin Simmons -
Reimar Döffinger -
Rich Felker -
Uoti Urpala