<div dir="ltr">Dear all,<br><br>I would like to know your opinions about some optimizations<br>of Viterbi decoder, which were already discussed previously.<br><br>First of all, I would like to share some benchmarking results.<br>I used the test cases ("osmo-conv-test"), written by Tom Tsou,<br>to ensure that SIMD optimization is integrated correctly. And,<br>shortly speaking, the results are almost equal. Older version<br>of decoder is a little bit faster, but I think it's because<br>one is being compiled with "-march=native".<br><br>Returning back to the subject, as we allocate and free some<br>memory on every osmo_conv_decode_acc() call, what may happen<br>very frequently and tear down performance on some hardware,<br>there was the following suggestions:<br><br>1) Use static memory allocation where it's possible.<br>2) Use talloc for dynamic allocation.<br>3) Internal caching:<br><br>Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote:<br>> Internal caching was in the original implementation, but<br>> stripped from the submitted version mainly for simplicity<br>> and avoiding the need for global variables, though we seem<br>> to be having that discussion anyway ;-) The trellis values<br>> can be cached based on pointer or hashed code. That works well<br>> until threading is involved and cache access needs to be locked.<br>> Those are features I need, but can probably be ignored in this<br>> case.<br>><br>> Again, I think the API should be kept intact. Internal caching,<br>> can be a topic for later discussion.<br><br>So, I am open for your ideas, opinions and remarks.<br><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>With best regards,<br></div><div>Vadim Yanitskiy.<br></div></div></div></div></div></div>
</div>