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