1

133,784,560エントリが必要なルックアップテーブルをコンパイルしています。0 - 7,462

の最大値は、7,462内に含めることができます13 bits。これにより、約207MBのルックアップテーブルが得られます。

値を指定する16 bitと、ルックアップテーブルのサイズが50mbさらに大きくなります。

ルックアップテーブルのサイズがさらに大きくなることは、今日の時代では重要ではありませんが、可能な限り薄くしておくとよいでしょう。

LUTがメモリにロードされるとき、13ビットの範囲の値を評価するために、？を評価する場合と比較して、どのくらいのオーバーヘッドがあり16 bitsますか？コンピューターで実行可能な形式に変換するための中間ビット演算があると思いますか、それとも間違っていますか？

何十億もの比較を実行するブルートフォース分析プログラムに関与するため、すべてのクロックサイクルが重要です。少し大きいLUTを使用する必要がありますか？

4

4 に答える 4

4

私は13ビットではなく16ビットの値に固執します。ブルートフォース分析と数十億の比較を行っているので、追加の50MBは支払うべき小さな代償のようです。また、13ビットの場合を管理するコードは非常に複雑になることにも注意してください。通常、複数の16ビット（または32ビットなど）の値を読み取り、シフトして結合する必要があるためです。必要な実際の値。つまり、値＃nの抽出は、単に「テーブルから取得する」よりもはるかに複雑になります。

ただし、確実に知る唯一の実際の方法は、両方を試して確認することです...しかし、最終的に使用しない可能性のある13ビット値の取得コードを実装する時間がない限り、私はおそらくそうしません。わざわざ。

于 2010-10-15T23:41:35.683 に答える
3

両方の方法を試して、どちらが速いかを確認してください。また、これはC++にドロップするのに適した候補だと思います。これは、C＃から直接参照できるマネージC++プロジェクトにカプセル化できます。これにより、アプリの他の部分に直接アクセスしながら、必要なすべての低レベルの最適化を実行できます。

于 2010-10-15T23:36:38.667 に答える
3

私の推測では、それは時期尚早の最適化の場合です。ビットをいじるのは非常に高価であり、偶然の一致によってキャッシュのパフォーマンスがこれら2つのサイズの間のどこかでひじに当たらない限り、おそらく余分なメモリアクセスコストを小さくします。

結局のところ、それを試してみる以外に方法はありません。

于 2010-10-15T23:41:50.900 に答える
2

LUTがメモリにロードされる場合、16ビットを評価する場合と比較して、13ビットの範囲の値を評価するためにどのくらいのオーバーヘッドがありますか？

次のような配列にデータを格納することを意味すると仮定します。

AAAAAAAA AAAAABBB BBBBBBBB BBCCCCCC
CCCCCCCD DDDDDDDD DDDDEEEE EEEEEEEE
EFFFFFFF FFFFFFGG GGGGGGGG GGGHHHHH
HHHHHHHH ...
  • LUTエントリが格納されているメモリアドレスを計算するのはより複雑です。のように（コンパイラに）2を掛けることはできませんshort[]。
  • また、13ビット値が2つの配列要素（または、基になる配列がの場合は3つ）に分割される可能性があるという事実にも対処しましたbyte[]。
  • さらに、「中間ビット演算」。
于 2010-10-15T23:58:00.050 に答える