C计算13位而不是本机16位的开销

我想这是一个过早优化的例子。比特篡改是相当昂贵的,而且可能会使额外的内存访问成本相形见绌,除非纯粹是巧合,否则您的缓存性能在这两个大小之间的某个地方遇到了瓶颈。

归根结底,没有什么可以替代仅仅是尝试一下。

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

然而,唯一真正能确定的方法是尝试两者并看到…但是,除非您有时间实现13位值检索代码,而您最终可能不会使用这些代码,否则我可能不会费心。

我想说试两种方法,看看哪一种更快。此外,我认为这是一个很好的候选人进入C++。你可以把它封装在一个托管C++项目中,你可以直接从C++中引用它。这将允许你做所有你想要的低级优化,同时仍然可以直接访问你的应用程序的其余部分。

当LUT加载到内存中时, 有多少开销需要评估 范围为13位的值, 与评估16位相比?

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

AAAAAAAA AAAAABBB BBBBBBBB BBCCCCCC
CCCCCCCD DDDDDDDD DDDDEEEE EEEEEEEE
EFFFFFFF FFFFFFGG GGGGGGGG GGGHHHHH
HHHHHHHH ...

• 计算存储LUT条目的内存地址要复杂得多。你不能像使用编译器那样把2乘以 short[] .
• 您还可以处理这样一个事实:您的13位值可能被拆分为2个数组元素(如果基础数组是 byte[] )
• 加上“中间位操作”。