Hi Max,
Unfortunately I could not find any tests for the code in question so the only way to test it is by:
I uploaded tests recently. You can find them here: https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
I think the puncturing code should be part of the library (otherwise every user will have to reimplement the same thing again and again).
I am agree with you. We recently discussed this question with Tom Tsou. He said, that there was some performance related reasons to perform puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
With best regards, Vadim Yanitskiy.
Is there some microbenchmark available? Perhaps we can use it to improve generated code?
On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
Hi Max,
Unfortunately I could not find any tests for the code in question so the only way to test it is by:
I uploaded tests recently. You can find them here: https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
I think the puncturing code should be part of the library (otherwise every user will have to reimplement the same thing again and again).
I am agree with you. We recently discussed this question with Tom Tsou. He said, that there was some performance related reasons to perform puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
With best regards, Vadim Yanitskiy.
I don't know. Maybe Tom has one? Otherwise I can try to write myself.
Tom Tsou wrote:
There was a discussion many years ago about puncturing inside or outside of the convolutional coder loops. I preferred separating puncturing and convolutional coding because of efficiency. Using discrete implementations allows faster implementations.
With best regards, Vadim Yanitskiy.
2016-10-13 0:58 GMT+07:00 Max msuraev@sysmocom.de:
Is there some microbenchmark available? Perhaps we can use it to improve generated code?
On 10/12/2016 07:51 PM, Vadim Yanitskiy wrote:
Hi Max,
Unfortunately I could not find any tests for the code in question so the only way to test it is by:
I uploaded tests recently. You can find them here: https://gerrit.osmocom.org/#/c/933/4/tests/coding/coding_test.c
I think the puncturing code should be part of the library (otherwise every user will have to reimplement the same thing again and again).
I am agree with you. We recently discussed this question with Tom Tsou. He said, that there was some performance related reasons to perform puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
With best regards, Vadim Yanitskiy.
-- Max Suraev msuraev@sysmocom.de http://www.sysmocom.de/ =======================================================================
- sysmocom - systems for mobile communications GmbH
- Alt-Moabit 93
- 10559 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Director: Harald Welte
On Wed, Oct 12, 2016 at 10:58 AM, Max msuraev@sysmocom.de wrote:
Is there some microbenchmark available? Perhaps we can use it to improve generated code?
Potential Viterbi optimization using SIMD methods is substantial as I demonstrated many years ago. The implementation does require separation of puncturing and Viterbi. Unfortunately, the has code experienced code rot since then. Admittedly, I accept much of that blame.
================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718
http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
-TT
Hi Tom,
Thank you for explainations!
Potential Viterbi optimization using SIMD methods is substantial as I demonstrated many years ago. The implementation does require separation of puncturing and Viterbi. Unfortunately, the has code experienced code rot since then. Admittedly, I accept much of that blame.
I think it would be really good to have/use your Viterbi implementation inside the libosmocoding. Regarding to some remarks to your code, I am ready to fix them (such as malloc -> talloc).
Moreover, recently I had a conversation with Alexander Chemeris. He also mentioned your implementation, which would be better to use in embedded platforms (such as UmSITE) due to performance reasons.
In summary, my concern is about the implementation and not the API. Perhaps we could pull the puncturing into the library as Max suggests. Then, separately, consider performance changes to the internal puncturing and Viterbi implementations.
So, my suggestion is to:
1) Extend your code with encoding capabilities. 2) Merge Viterbi transcoder with the libosmocoding. 3) Merge libosmocoding into libosmocore as a sub-library or spawn a separate repository.
Any opinions?
With best regards, Vadim Yanitskiy.
2016-10-13 1:54 GMT+07:00 Tom Tsou tom@tsou.cc:
On Wed, Oct 12, 2016 at 10:58 AM, Max msuraev@sysmocom.de wrote:
Is there some microbenchmark available? Perhaps we can use it to improve generated code?
Potential Viterbi optimization using SIMD methods is substantial as I demonstrated many years ago. The implementation does require separation of puncturing and Viterbi. Unfortunately, the has code experienced code rot since then. Admittedly, I accept much of that blame.
================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718
http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
-TT
- Extend your code with encoding capabilities.
Ah, I just found it inside your repository.
With best regards, Vadim Yanitskiy.
2016-10-14 17:40 GMT+07:00 Vadim Yanitskiy axilirator@gmail.com:
Hi Tom,
Thank you for explainations!
Potential Viterbi optimization using SIMD methods is substantial as I demonstrated many years ago. The implementation does require separation of puncturing and Viterbi. Unfortunately, the has code experienced code rot since then. Admittedly, I accept much of that blame.
I think it would be really good to have/use your Viterbi implementation inside the libosmocoding. Regarding to some remarks to your code, I am ready to fix them (such as malloc -> talloc).
Moreover, recently I had a conversation with Alexander Chemeris. He also mentioned your implementation, which would be better to use in embedded platforms (such as UmSITE) due to performance reasons.
In summary, my concern is about the implementation and not the API. Perhaps we could pull the puncturing into the library as Max suggests. Then, separately, consider performance changes to the internal puncturing and Viterbi implementations.
So, my suggestion is to:
- Extend your code with encoding capabilities.
- Merge Viterbi transcoder with the libosmocoding.
- Merge libosmocoding into libosmocore as a sub-library or spawn a separate repository.
Any opinions?
With best regards, Vadim Yanitskiy.
2016-10-13 1:54 GMT+07:00 Tom Tsou tom@tsou.cc:
On Wed, Oct 12, 2016 at 10:58 AM, Max msuraev@sysmocom.de wrote:
Is there some microbenchmark available? Perhaps we can use it to improve generated code?
Potential Viterbi optimization using SIMD methods is substantial as I demonstrated many years ago. The implementation does require separation of puncturing and Viterbi. Unfortunately, the has code experienced code rot since then. Admittedly, I accept much of that blame.
================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718
http://lists.osmocom.org/pipermail/openbsc/2014-April/007365.html
-TT
On Wed, Oct 12, 2016 at 10:51 AM, Vadim Yanitskiy axilirator@gmail.com wrote:
I think the puncturing code should be part of the library (otherwise every user will have to reimplement the same thing again and again).
I am agree with you. We recently discussed this question with Tom Tsou. He said, that there was some performance related reasons to perform puncturing inside both gsm0503_pdtch_encode() / gsm0503_pdtch_decode().
From an API standpoint, it makes no difference and makes sense to move
the puncturing into the library. Regarding the implementation, there is a significant difference.
Puncturing and convolutional coding are inherently discrete steps. It is possible, as in the library, to reconstruct the non-punctured bit vector while feeding into the Viterbi at same time, but the downside of this approach is reduced optimization (or potential optimization).
The reason is that the Viterbi always runs at the full non-punctured rate and can be implemented with well known trellis coding optimizations. Puncturing is a completely separate algorithm from the Viterbi, and integrating them together provides no performance benefit at best and degradation at worst.
That said, the one advantage to puncturing inside the Viterbi is for handling continuous non-fixed length codes. But, those codes are not used by GSM or 3GPP in general, so they are not relevant here.
In summary, my concern is about the implementation and not the API. Perhaps we could pull the puncturing into the library as Max suggests. Then, separately, consider performance changes to the internal puncturing and Viterbi implementations.
-TT
-
Max -
Tom Tsou -
Vadim Yanitskiy