core/conv: further Viterbi decoder optimizations

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Vadim Yanitskiy axilirator at gmail.com
Sun Jun 18 20:25:31 UTC 2017


Hi Max and Tom,

> why do we need to optimize current implementation further?
> Is it just for the sake of aesthetics and fun of it?

You are right, this is for the sake of aesthetics. I had a
task: to take some dead code from mailing lists, to make it
satisfy    the Osmocom coding requirements and merge it part by
part. There was some warnings about object visibility (fixed),
about naming convention (fixed) and about memory allocation.

In the past, the discussion about memory allocation was set
aside, until code is merged. So, till now, this task remained
in my mind as some kind of unfinished work...

> Do we have some profiling result showing that in scenario
> A Viterbi decoder occupies XX% of the time?

I am not sure that we can profile different parts of code
without actual modifications (probably perf can do that,
correct me otherwise). But we can profile a whole
implementation using the benchmark code from Tom, which
I mentioned before.

> Don't get me wrong - I'm not against optimizations,
> just would like to know more about the general context.

It's ok, I am always happy to know your and other opinions :)

> Persistent allocation is the best solution. Talloc will minimally
> affect performance if at all. Internal caching is somewhat of a hack
> to hide static allocation behind an API that does not allow it.

I'll try to use persistent allocation where it's possible, e.g.
the struct vdecoder in osmo_conv_decode_acc() could be allocated
in the stack instead of heap.

> Three years ago, which feels like much longer, I was performing brute
> force RNTI searches on LTE control channels. Convolutional decoding
> was the limiting factor and maxed out multiple threads; every
> optimization helped. That was a much different set of requirements.

Ok, that is exactly what I need to know.
Now I can let internal caching go, as it isn't critical for GSM.


With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170619/30c82af1/attachment.htm>


More information about the OpenBSC mailing list