[MPlayer-dev-eng] [PATCH] remove mp3lib

[Thomas Orgis]

Am Tue, 27 Sep 2011 04:39:12 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> It took me quite a lot of time, but I hope there will be useful
> information in the data I provide.
> If you need the raw perf.data files, I can send them to you.

Thanks! Now it's my turn to allocate a time slot to digest this and try
to fix the mpg123 binding. 

> - increasing alignment (of most big arrays) actually made mp3lib a
> percent or 2 slower... so I dropped this road.

Well, OK, this helped for more modern CPUs. Hm, was about to wonder if
this makes mpg123 generally slower as it might overalign stuff for your
case, but we're talking about the big hit compared to standalone mpg123.

> Cache misses are 2 times more for the mpg123 case and I think this is
> what affects the instructions per cycle ratio. 

I'll focus on that...

> -there is a memcpy in glibc that takes most of the cache misses. I
> wonder how I can make a nice percentage table of the functions that
> call this memcpy().

Well, memcpy() is involved in copying over data from MPlayer. That we
waste cycles in that is not new, but the impact is the question.
But internally in mpg123, there are also copies between input stream
buffer and frame handle.

It might be that just cutting down on the copying of memory could do
it. But it's non-trivial to eliminate it all.

> III_dequantize_sample() seems like the function that needs most love.
> And it seems to be the core function. It have a lot of cache misses
> and a lot of branch misses. All things that older cpu are quite bad at
> ;)

Well, this function does the huffman decoding from the frame buffer.
There's reading some bytes (bits, even), computing/looking at table, and
writing some to another location. But not memcpy() of buffer blocks.
So the memory blocks it correlates (reads/writes on intermittendly) are
further apart in the MPlayer case?

Important point is that this is not one of the assembly-optimized
functions.


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/20110928/0199596c/attachment.asc>