[FFmpeg-devel] [PATCH 4/6] truehd: tune VLC decoding for ARM.
Michael Niedermayer
michaelni at gmx.at
Thu Mar 20 12:33:24 CET 2014
On Thu, Mar 20, 2014 at 07:45:13AM +0100, Reimar Döffinger wrote:
> On 19.03.2014, at 22:39, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Mar 19, 2014 at 05:26:19PM +0000, Ben Avison wrote:
> >> Profiling on a Raspberry Pi revealed the best performance to correspond
> >> with VLC_BITS = 5. Results for overall audio decode and the get_vlc2 function
> >> in particular are as follows:
> >>
> >> Before After
> >> Mean StdDev Mean StdDev Confidence Change
> >> 6:2 total 348.8 20.1 339.6 15.1 88.8% +2.7% (insignificant)
> >> 6:2 function 38.1 8.1 26.4 4.1 100.0% +44.5%
> >> 8:2 total 339.1 15.4 324.5 15.5 99.4% +4.5%
> >> 8:2 function 33.8 7.0 27.3 5.6 99.7% +23.6%
> >> 6:6 total 604.6 20.8 572.8 20.6 100.0% +5.6%
> >> 6:6 function 95.8 8.4 68.9 8.2 100.0% +39.1%
> >> 8:8 total 766.4 17.6 741.5 21.2 100.0% +3.4%
> >> 8:8 function 106.0 11.4 86.1 9.9 100.0% +23.1%
> >> ---
> >> libavcodec/mlpdec.c | 13 ++++++++++---
> >> 1 files changed, 10 insertions(+), 3 deletions(-)
> >
> > applied
>
> This sounds to me like cache-tuning.
> The Raspberry Pi CPU is really tiny, calling it "optimize for ARM" seems like a misleading title.
> There is a good chance that with larger implementations the original values _might_ be faster, just like the smaller ones might be better with e.g. x86 Atoms.
> Note: not tested and thus I do not suggest any changes, but pointing out that basing this on CPU architecture is likely far from optimal in many cases.
maybe some kind of target cache size define could be added in/by
configure ?
also i had tested it on a i7 and the original was faster there
dont remember numbers but it wasnt a huge difference
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140320/5106a9ed/attachment.asc>
More information about the ffmpeg-devel
mailing list