私は現在、ターボ デコーダーのマルチスレッド ソフトウェア実装に関するコンピューター サイエンスの論文を作成しています。基本的な問題は次のとおりです。
- (y1, ..., yn) を、チャネルを介して受信したノイズの多いビットのシーケンスとします。2 つの SISO デコーダが並行して動作します (それぞれがシーケンスの最初のビットと {1,2} のパリティ ビット y1j, j を受信します)。現在のビットが 0 または 1 のいずれかであること)、次の反復のために他の SISO デコーダーに供給されます。受信したビットが短いデータ フレームに分割されるとします。(SISO はソフト入力、ソフト出力を意味します。これは、各デコーダーが入力のビット確率の推定値を取得し、独自の推定値を出力するためです)
LLR の各計算には、各フレームのビット量 (およびエンコーダーが初期シーケンスのパリティ ビットを作成するために使用するビット量) に応じて、多数のシリアル化された ACS 操作が必要です。このような計算は、ネストされた for サイクル (2 つの SISO デコーダーが並行して動作するそれぞれについて) で合計できます。
for i=1 to N_FRAMES:
for j=1 to N_ELS_FRAMES:
for k=1 to 4:
for l=1 to N_STATES:
do_ops()
上記のループは実際にはアルゴリズムに表示されませんが、各反復で行われる操作と非常によく一致することに注意してください。一般に、N_STATES は約 8 または 16 (各エンコーダーが入力シーケンスのパリティ ビットを計算するために使用するビットの量によって異なります) であり、do_ops() には合計、最大、およびベクトルの正規化が必要です。
最初は Jython を使用して実装を試みましたが、結果はかなりがっかりしました。上記のネストされたループの操作は、マルチスレッド バージョンでは、適度な (~2 ミル) ビット量で約 20 分 (!) かかりました。
一方、Java 実装では、アルゴリズムのシングル スレッド バージョンを使用すると、最大 1 秒、最大 4 ミル ビットが必要です。
なぜこれほど大きな違いがあるのでしょうか。