<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>