Hi Thomas, Sylvain,
Recent activity around convolutional coding has reminded me about this lost diamond. Just wondering if there is a chance to resolve the critical issues and get this merged?
On Sat, Aug 1, 2015 at 12:16 AM, Sylvain Munaut 246tnt@gmail.com wrote:
Ok, so I finally took some time to re-read this.
First a quick comment on each patch.
Patch 1/4: See below Patch 2/4: Didn't really look deeply yet, but at first glance looks OK, I'd say let's focus on getting the infra of patch 1 merged first. Patch 3/4: I'm pretty sure -march=native will wreck cross-compiling Patch 4/4: Looks good
For patch 1:
- About the state persistence, let's just ignore it for now. It does
cost some performance but there is no easy fix, the perf improvement even with this over head is still massive and we can deal with it internally later.
- The symbol visibility and naming comments raised in the thread need
to be dealt with. To sum up there is 3 kinds of symbols/names :
- Global functions / structures: Those that either appear in theheader or that are visible when doing an objdump on the resulting .so . Those all need the osmo_ prefix
- Internal to the lib: Those that are accessed between severalfiles in the lib. Those don't need an osmo_ prefix for brevity, but they need something less conflicted than 'gen_' ... include 'viterbi' or 'conv' or something to that effect in the name. They need to be hidden from the outside (so they shouldn't show up in the resulting .so), not sure about the current fvisibility situation in libosmocore (don't know if we explicitely mark exported function or if we explicitely mark non-exported one).
- Internal to the file: Make sure they're static, naming is fairlyirrelevant
So I'd say re-submit patch 1 and 4 first, forward ported to apply cleanly and pass a make distcheck on current master. We'll get that merged first, then look at integrating the SSE stuff.
Cheers,
Sylvain