-
Notifications
You must be signed in to change notification settings - Fork 314
Benchmark LDPC Encoder #1423
-
|
Hi all, |
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 1 comment · 3 replies
-
|
Hi @mirazabal, If you want to be exact, yes, you should include |
Beta Was this translation helpful? Give feedback.
All reactions
-
|
Hi @dvdgrgrtt . Thanks for the reply. Here my measurements: Vanilla ./build/tests/benchmarks/phy/upper/channel_coding/ldpc/ldpc_encoder_benchmark -T avx2 -R 10000 After applying the following diff +#include "srsran/phy/upper/channel_coding/ldpc/ldpc_encoder_buffer.h" ./build/tests/benchmarks/phy/upper/channel_coding/ldpc/ldpc_encoder_benchmark -T avx2 -R 10000 Vanilla, without the changes BG=1 LS=384 cb_len=25344| 6064.6| 5936.7| 5814.1| 5583.6| 1979.3| 1650.3| 1650.3| => 8448/6e9 ~= 1400 ns With the changes BG=1 LS=384 cb_len=25344| 2236.6| 2219.0| 2201.7| 2145.2| 1187.6| 1118.3| 1118.3| => 8448/2.2e9 ~= 3900 ns My own benchmark using libbenchmark Without changes BM_LDPC_SRS/384/384 1712 ns 1711 ns 416877 With changes BM_LDPC_SRS/384/384 4065 ns 4065 ns 174381 So, around two-three times slower. The result looks consistent, and since memory accesses are the most expensive operation, I think that it makes sense. Please, let me know if I am not measuring it correctly. |
Beta Was this translation helpful? Give feedback.
All reactions
-
|
Hi @mirazabal, |
Beta Was this translation helpful? Give feedback.
All reactions
-
|
Hi @dvdgrgrtt thank you very much for the quick answer. Shall I create a PR for the benchmark with your suggested changes? Other quick question. According to my understanding, according to 3GPP TS 38.212 version 15.2.0 Release 15 Section 7.2.2 AFAIU, this means that if the info bits are less than or equal to 292, the graph (BG) will always be 2 i.e., BG2. Thus, a Zc min of 14 is needed, i.e., 14x22 = 308 while 13x22=286. When the project measures BG1 with lower Zc (e.g., BG=1 LS=10 cb_len=660 | 78.1| 77.8| 77.5| 67.7| 34.8| 29.0| 29.0|), is it there for completeness, or does it exist a case in 5G where such encoding is needed/foreseen? |
Beta Was this translation helpful? Give feedback.
Hi @mirazabal,
thanks for the report! I have to admit I didn't expect such a difference. I only have one suggestion - instead of
std::vector<uint8_t> tmp(max_cb_length_bg*ls), I'd dostd::vector<uint8_t> tmp(cb_length), so you can compare the bit-rate (or encoding time) for different codeblock lengths - right now, you're always writing the whole codeblock, that's why you get the same result for each two consecutive lines. Recall that, in NR, you'll need more or less redundancy bits depending on the redundancy version and the MCS (this was one of the reasons for separating the high-rate region from the rest), and, in my opinion, it's interesting to know at least the two extreme values. Of …