1

我正在编译一个需要有133,784,560条目的查找表，其值范围为0 - 7,462

的最大值7,462可以包含在 内13 bits。这给了我们一个大约 207 MB 的查找表。

一个16 bit值会增加我们的查找表大小50mb。

在当今时代，查找表大小的额外增加并不显着，但保持它尽可能薄会很好。

当 LUT 加载到内存中时，与评估 13 位范围的值相比，评估 13 位范围的值有多少开销16 bits？我假设会有一些中间位操作将其转换为计算机可用的格式，还是我错了？

每个时钟周期都很重要，因为这将涉及一个蛮力分析程序，该程序将运行数十亿次比较。我应该坚持使用稍大的LUT吗？

4

4 回答 4

4

我会坚持使用 16 位值而不是 13 位。由于您正在进行强力分析和数十亿次比较，因此额外的 50MB 似乎是一个很小的代价。还要记住，管理 13 位案例的代码会更加复杂，因为您通常必须读取多个 16 位（或 32 位或其他）值并移位和组合以获得您需要的实际值。换句话说，提取值#n将比简单地“从表中检索它”复杂得多。

然而，唯一真正确定的方法是尝试两者并查看......但除非你有时间实现你可能最终不会使用的 13 位值检索代码，否则我可能不会不要打扰。

于 2010-10-15T23:41:35.683 回答
3

我会说两种方式都尝试一下，看看哪个更快。另外，我认为这是进入 C++ 的好人选。您可以将其封装在托管 C++ 项目中，您可以直接从 C# 引用该项目。这将允许您进行所有您想要的低级优化，同时仍然可以直接访问您的应用程序的其余部分。

于 2010-10-15T23:36:38.667 回答
3

我的猜测是这是过早优化的情况。位摆弄非常昂贵，并且可能会使额外的内存访问成本相形见绌，除非您的缓存性能恰好在这两种大小之间达到肘部。

最终，没有什么可以替代只是尝试一下。

于 2010-10-15T23:41:50.900 回答
2

当 LUT 加载到内存中时，与评估 16 位相比，评估 13 位范围的值有多少开销？

假设您的意思是将数据存储在这样的数组中：

AAAAAAAA AAAAABBB BBBBBBBB BBCCCCCC
CCCCCCCD DDDDDDDD DDDDEEEE EEEEEEEE
EFFFFFFF FFFFFFGG GGGGGGGG GGGHHHHH
HHHHHHHH ...
  • 计算存储 LUT 条目的内存地址更为复杂。您不能像使用short[].
  • 您还必须处理这样一个事实，即您的 13 位值可能会被拆分为 2 个数组元素（如果基础数组是 a ，则为 3 个byte[]）。
  • 加上“中间位操作”。
于 2010-10-15T23:58:00.050 回答