flac dev - Jul 2022 - About SSE intrinsincs in decoder

Op di 5 jul. 2022 om 09:41 schreef olivier tristan <o.tristan at uvi.net>:
> You do not talk about the SSE 4.1 version in your bench.
>
> Have you tried this use case ?
>
I compared 4 compiles: one without any changes (so with all variants of the
lpc functions, including the SSE4.1 ones) and three with variants of plain
C code. As both CPUs that were tested had SSE4.1 capability, these
functions were compared with. So yes, current GCC outperforms those SSE4.1
intrinsics functions on 16-bit inputs and comes close on 24-bit inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220705/30bea852/attachment.htm>

Olivier,

On a more general note, do you experience the decoding speed of libFLAC as
a bottleneck in your application? Decoding speed of FLAC is already
best-in-class among lossless audio codecs, so I actually wasn't expecting
anyone to object to a (small) decrease in decoding speed. There have been
more changes recently that could (slightly) affect decoding speed, but for
good reasons. I am aware that the following changes affect decoding speed
-
https://github.com/xiph/flac/commit/1bec35e33757fc38261b0acfa3c032e720d2baf0
-
https://github.com/xiph/flac/commit/63ac1c37bebbda5ca61ad5a05a1d8fba2883f629

Comparing current git to release 1.3.4 for my 64-bit x86 machine this adds
up to about 4% slowdown for both 16-bit and 24-bit audio. When using a
32-bit compile, for 16-bit audio this cancels out against the speed gain
from the removal of optimizations and for 24-bit audio this compounds to
about 10% speed loss. Numbers may vary depending on the CPU specifics. I
didn't think this would be a problem, but please speak up (and if possible
elaborate on the details) if it is.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20220706/d769e79a/attachment.htm>