core/conv: further Viterbi decoder optimizations

[Vadim Yanitskiy]

Hi Harald,

> When I look at the current API, the decode_init()/decode_deinit()
> functions are great candidates to perform such allocation/release of
> memory.   If applications use the osmo_conv_decode() convenience
> wrapper, it simply means they don't care about efficiency, but if they
> use the real init/scan/flush/deinit API, they would benefit from it.

You are talking about Sylvain's implementation of Viterbi,
which is currently used as fail-safe back-end for a new
algorithmically and SIMD optimized implementation, written
by Tom Tsou.

In the Sylvain's implementation (conv.c), init/scan/flush/deinit
are exposed for external usage, meanwhile Tom's implementation
is transparently integrated into the first one, and doesn't
expose anything outside.

> The viterbi.c code (which by the way chould be renamed to conv_acc.c or
> the like) would then have to be restructured to plug into init/fini for
> allocation+release.

Do you suggest to expose alloc_vdec, free_vdec and
osmo_conv_decode_acc like it is done in the conv.c?

Anyway, using init/fini is profitably only if you are doing
serial (en/de)coding of the same convolutional code. As soon
as you need to (en/de)code another convolutional code, you
will have to reallocate and reconfigure the vdec object.

> (which by the way chould be renamed to conv_acc.c or the like)

I like this idea, already in my TODO list :)

> I doubt this will improve your speed.  Feel free to try, but this is
> more of a clean-up to ensure all the memory allocated within osmocom
> projects is tracked/accounted for, and you can get talloc usage
> reports, debug memory leaks, etc.

Agree with you. But what do you think about talloc memory pools?

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