mpg123 linux MP3播放器源码

This is historic... one should make a new investigation. What I can say that a quick test of pre0.59s versus 1.7.3 with generic decoder on my x86-64 GNU/Linux box is not able to call a winner (or looser, for that matter). Though, 1.8.0 will make the new libmpg123 a winner, because there is new optimization code going on! The move to libmpg123 means some more code separation / interfacing and especially the move of any local static variables into the mpg123_handle to make multiple stream handling possible. That may very well have an impact on performance of the mpg123 decoder. I made some tests, even using gcc's -pg option and gprof, with mixed result: SSE and MMX on my Thinkpad X31 are slower, especially the asm synth funtion, while the generic code is fine. On the other hand, on a K6-3+ using the same gcc version 4.1.2, the library based mpg123 is _faster_ for MMX and 3DNowExt. Epecially the mmx synth is faster... while the 3DNowExt synth is slower, too (it's the same code as SSE synth, just calling different dct64) - but speedups in other regions still make 3DNowExt of the library mpg123 more efficient. What I can clearly say is that dropping the multi-cpu support via ./configure --with-cpu does help in for both monolithic and library mpg123, but that is no wonder as it removes indirection. The main point stays, though: On my Thinkpad the library is slow, on the K6-3+ it's fast. What's the point to get here? I am not sure. We're depending on the compiler optimization (btw: Intel Compiler doesn't change the relation for the Thinkpad; not tested on the K6). I guess that for my Thinkpad another gcc version could invert the picture again... Also, I am not sure how far I should trust the gprof analysis... but it can be right; even when there is no apparent cause for the speed difference in the code itself, it could be some effect of cache and memory access. Some reordering of instructions and data... for sure that happened. I'll need further numbers to conclude anything about the (positive/negative) impact my code changes have. OK, ran the test of trunk against branches/mpg123lib on my media box with AMD Geode (AthlonXP, actually): thomas@kiste:~$ for i in mpg123-lib mpg123-trunk; do for cpu in mmx 3dnowext sse; do echo $i $cpu; time $i/src/mpg123 --cpu $cpu -q -t /thorma/var/music/metallica/ride_the_lightning/*.mp3; done; done mpg123-lib mmx real 0m25.949s user 0m25.395s sys 0m0.534s mpg123-lib 3dnowext real 0m25.442s user 0m24.863s sys 0m0.558s mpg123-lib sse real 0m25.794s user 0m25.214s sys 0m0.562s mpg123-trunk mmx real 0m26.650s user 0m26.004s sys 0m0.626s mpg123-trunk 3dnowext real 0m25.886s user 0m25.262s sys 0m0.600s mpg123-trunk sse real 0m25.695s user 0m25.136s sys 0m0.539s thomas@kiste:~$ for i in mpg123-lib mpg123-trunk; do for cpu in 3dnow; do echo $i $cpu; time $i/src/mpg123 --cpu $cpu -q -t /thorma/var/music/metallica/ride_the_lightning/*.mp3; done; done mpg123-lib 3dnow real 0m33.011s user 0m32.365s sys 0m0.621s mpg123-trunk 3dnow real 0m32.830s user 0m32.192s sys 0m0.619s You can't really make a decision there. It's tight. What worries me a bit is the total loose of 3DNow against MMX - should it be that drastic? Well, it's higher quality, at least. -- Thomas.