18 Jun
2017
18 Jun
'17
9:54 p.m.
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.