[MPlayer-dev-eng] [PATCH] disable mp3lib code by default

[Thomas Orgis]

Am Fri, 16 Mar 2012 18:35:31 +0000 (UTC)
schrieb Carl Eugen Hoyos <cehoyos at ag.or.at>: 

> Yes, did I miss the SSE-only benchmarks? If yes, sorry, 
> the article is long...

Sorry, what do you want? SSE-only or non-SSE? I'm confused.

The article does focus on AMD machines with 3DNowExt, but in the big
table at the end (just scroll down, you don't have to read it all),
there are also values for my Core2Duo machine, 64 bit mode, SSE. The
needed runtime is around 16 seconds with libmpg123, 18 seconds with
mp3lib. I didn't include ffmp3float there, because it started to
confuse the heck out of my in this section of my article:

Self-quote begin:

On the K6-III+ 

 I finally an claim victory for framewise decoding with a static
libmpg123. It's indeed a bit faster than mp3lib. Not so on the Duron
(also with -march=athlon), there, libmpg123 can only come close, but
never overtake. But this is with this certain setup / tool chain. Who
knows what gcc 4.6 would do? 

Native binaries on Duron and K6-III+ ... and my Laptop Core2Duo at 800
MHz, 64 bit mode (on the K6 it's user time measured by the time
command, the others via perf).

build	Duron	K6-III+ Core 2
variant1-dynamic (1.12.1)	27.74 s	57.46 s
variant1-dynamic (1.13.4)	 	 	16.72 s
variant1-dynamic (trunk)	27.81 s	57.05 s	16.87 s
variant2-dynamic	27.10 s	55.92 s	16.54 s
variant2-static	27.01 s	53.92 s	16.51 s
mp3lib	26.45 s	56.47 s	18.56 s
ffmp3	73.52 s	115.08 s	22.00 s
ffmp3float	30.74 s     118.19 s	12.26 s
variant2-float	 	 	18.76 s

End of self-quote.

The table is rather mangled here, but the main point is the strange
comparison to ffmp3float. On the Core2, ffmp3 needs 22 seconds,
ffmp3float a bit more than half of that at 12.26 s! That beats anything
mpg123 has to offer... but, there is something very strange about
ffmp3float, that I really didn't have the time and will to debug:

Self-quote begin:

What is the deal with ffmp3float on my Core2Duo? 

 I'm comparing with libmpg123 in floating point mode (also assembly optimized).
This does not seem right. The waves look good. How can this be suddenly
that fast? What kind of 64 bit assembly magic is part of that? 

 It is suspicious that ffmp3float is not consistent. Repeated runs show differing
 numbers. Most interestingly such a run: 
      10817,626571 task-clock                #    0,049 CPUs utilized          
            16.540 context-switches          #    0,002 M/sec                  
                19 CPU-migrations            #    0,000 M/sec                  
             3.377 page-faults               #    0,000 M/sec                  
     8.544.770.425 cycles                    #    0,790 GHz                    
   <not supported> stalled-cycles-frontend 
   <not supported> stalled-cycles-backend  
     8.038.105.826 instructions              #    0,94  insns per cycle        
     1.302.988.705 branches                  #  120,451 M/sec                  
        41.415.237 branch-misses             #    3,18% of all branches        

     222,249003389 seconds time elapsed
Well, how do you come from 12 seconds to 222? Easy, you actually play in realtime. 
MPlayer SVN-r34365-4.6.1 (C) 2000-2011 MPlayer Team

Playing pcm:file=/dev/null.
File not found: 'pcm:file=/dev/null'
Failed to open pcm:file=/dev/null.


Playing /dev/shm/convergence_-_points_of_view/03 - Listen.mp3.
This looks rather corrupt from the beginning. The command line
 is always the same, the interpretation differs.

 Valgrind is no help with my MPlayer build: 
valgrind: m_debuginfo/readdwarf.c:2162 (copy_convert_CfiExpr_tree):
  Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
Well, I'm not here for debugging ffmp3float. Perhaps that's a bug fixed since
I did my checkout of MPlayer / ffmpeg.

End of self-quote.

Now, revisiting the performance and reliability of ffmp3float now might
be a sensible thing to do. Actually, I'm deleting the rest of this
already length post to land on that point.

I see that ffmp3float has partially more assembly code in the works than
mpg123... seems like ffmpeg folks have been busy during the past year.
I remember being consistently faster before. Well, if there is still
room for sensible optimizations, mpg123 will use it.


Alrighty then,

Thomas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120316/330046a2/attachment.asc>