[Bug 773073] audioconvert: endian conversion optimization

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=773073

--- Comment #35 from Petr Kulhavy <brain at jikos.cz> ---
Created attachment 338401
  --> https://bugzilla.gnome.org/attachment.cgi?id=338401&action=edit
Performance measurement results

Here are the results of my performance measurement of various algorithms.
The measurement is based on an artificial test, which runs the endian-swap
function in a loop on a buffer of a given size (in samples). The execution time
was measured on Cortex A7, 528MHz. The test program was compiled in several
variants: O2, O3, with naive algorithm, with unrolled loop for the 24-bit
conversion and with NEON.

Unfortunately I wasn't able to include ORC since the test uses static C code. 
The NEON version worked only with -O0, otherwise it clashed with the
optimization and segmentation fault happened. This probably due to my ARM
assembly ignorance.

In the table you can see the average duration of one cycle for different
algorithms/optimizations. The naive algorithm with -O3 scores the best, then
comes the unrolled -O3 (24-bit only), NEON -O0, unrolled -O2 and as last the
naive -O2. 

In any case we are talking about 4-17 nanoseconds. 
That means with 1% CPU usage (1s being 100%, i.e. 1% being 10ms) the worst
algorithm can process over 500'000 samples, i.e. 192kHz / 3 channels. The naive
-O3 algorithm can process 192kHz/ 8 channels with 1% CPU usage. That is pretty
good.

As previously explained the major CPU % loss is due to buffer allocation and
not-in-place conversion, which I have eliminated. So I'm going to close the
work here, sticking with the naive algorithm. Any further optimization is not
worth more effort at the moment.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.