<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Le 07/07/2022 à 09:34, Martijn van Beurden a écrit :<br>
</p>
<blockquote type="cite"
cite="mid:CADQbU68cE9sfXjndqBXc5O64sXPjJeKzTQo7q1icm_ob=UT5dw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><span style="font-family:monospace">Op do 7 jul.
2022 om 09:07 schreef olivier tristan <<a
href="mailto:o.tristan@uvi.net" moz-do-not-send="true"
class="moz-txt-link-freetext">o.tristan@uvi.net</a>>:<br>
> Hence even small optimization are very welcomed :)<br>
<br>
I presume you use libFLAC directly then. Sadly there is little
left to optimize in the decoder. Below is an excerpt of the
output of gprof on flac decoding a track<br>
<br>
> % cumulative self self total<br>
> time seconds seconds calls s/call s/call name<br>
> 34.87 0.68 0.68 680925 0.00 0.00
FLAC__bitreader_read_rice_signed_block<br>
> 25.64 1.18 0.50 6004826 0.00 0.00
FLAC__MD5Transform<br>
> 14.36 1.46 0.28 46030 0.00 0.00
FLAC__lpc_restore_signal<br>
> 8.72 1.63 0.17 23457 0.00 0.00
read_frame_<br>
> 5.13 1.73 0.10 23457 0.00 0.00
write_callback<br>
> 3.08 1.79 0.06 23457 0.00 0.00
FLAC__MD5Accumulate<br>
> 3.08 1.85 0.06 read<br>
> 2.56 1.90 0.05 50901 0.00 0.00
FLAC__crc16_update_words32<br>
> 1.03 1.92 0.02 23457 0.00 0.00
write_audio_frame_to_client_<br>
> 0.51 1.93 0.01 2016520 0.00 0.00
bitreader_read_from_client_<br>
> 0.51 1.94 0.01
_IO_file_seekoff<br>
> 0.51 1.95 0.01
write<br>
<br>
As you can see, the bitreader takes up most time. This is
however not something that can be optimized with SIMD/vector
instructions like SSE, AVX, NEON etc. It is also strictly a
sequential process. In the past there have been several
attempts at improving speed of this call. You could try for
yourself configuring using ./configure --enable-64-bit-words
or cmake -DENABLE_64_BIT_WORDS=ON whether that brings any
(small) improvement.<br>
<br>
Next the MD5 transformation takes up a lot of time too, but I
suppose you do not use that anyway. It is disabled by default
when decoding using libFLAC directly.<br>
<br>
</span>
<div><span style="font-family:monospace">Finally the lpc restore
takes up some time and can be improved with SSE, AVX, NEON
etc., but it represents only a small part of the decoding
CPU load.</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:monospace"><br>
</span></div>
</div>
</blockquote>
<p>We use libflac directly indeed so MD5 is not enabled in my case.</p>
<p>We indeed see in the perf analyzer
FLAC__bitreader_read_rice_signed_block and
FLAC__lpc_restore_signal<br>
</p>
<p>
<blockquote type="cite"><span style="font-family:monospace">Perhaps
it is possible to add a switch to the encoder to create FLAC
files that are optimized for decoding speed instead of size.
Would that be something you would use? For example trading in
5% less compression against 30% more decoding speed, assuming
that MD5 checking is already off?</span></blockquote>
This would indeed be interesting.</p>
<p>The material we use are very well compressed by FLAC as this is
just a single note of an instrument as opposed to a song.</p>
<p>For example in a piano library, we can divide the sample size by
4.<br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Olivier Tristan
Research & Development
<a class="moz-txt-link-abbreviated" href="http://www.uvi.net">www.uvi.net</a></pre>
</body>
</html>