在 C# 中进行按位运算时，除了 x64 或 x86 之外，我还需要考虑 CPU 吗？答案

【问题标题】：When doing bitwise operations in C#, do I ever have to consider the CPU besides x64 or x86?在 C# 中进行按位运算时，除了 x64 或 x86 之外，我还需要考虑 CPU 吗？
【发布时间】：2012-11-15 05:28:42
【问题描述】：

我正在考虑在 C# 中进行一些按位运算，并希望确保充分利用 CPU 和总线。我还想对内存中的数据进行结构化，以免产生不必要的负载（将数据与内存页面对齐）。

作为 .NET 开发人员，我能否针对内存数据结构和对齐方式实现硬件/CPU 特定优化？

【问题讨论】：

最好的办法是首先让您的程序正常运行，然后对其进行分析以查看性能问题所在，然后再然后对其进行优化。
具体是什么类型的操作？
关注约翰的评论。此外，作为 .NET 开发人员为什么要担心硬件，它总是会改变。 C#/.Net 的好处是你不在乎；抖动将为您优化。如果您非常关心这些问题，请使用 C 或更好的汇编程序（舌头牢牢地植入检查）。
@JohnSaunders 我也为您的评论 +1（作为一般做法）。所有的 QA 单元测试都通过了，我有空闲时间来探索这一点。我不知道我是否有性能问题，因为我没有什么可比较的。这个问题将允许我创建一个“优化”基线进行比较。

标签： c# .net 64-bit 32bit-64bit micro-optimization

【解决方案1】：

对于位移 (cmets) 之类的事情，只要您在标准数据边界上工作就没有关系 - CPU 将以尊重 CPU 字节顺序的方式进行移动。但是，如果您的数据“自然”是一个字节数组，并且您通过“不安全”将其视为一个长数组作为优化，那么它将很重要：左移一个 long 非常与独立左移 8 个字节不同。不过，“关于数据类型的谎言”可能是一个有用的优化：例如，web-sockets 屏蔽是作为一个 32 位 xor 应用于数据的，它是一个字节序列。通过一些技巧，可以通过减少 64 位 xor 的数量以及最多 7 个单独的 xor 来完成。

【讨论】：

【解决方案2】：

您可以使用FieldOffsetAttribute 控制数据在内存中的表示。这是类/结构定义的一部分，因此它不能在运行时更改，但您可以针对 x86 优化一个，针对 x64 优化一个，并在运行时决定使用哪个。

不过，您问题的标题提出了不同的问题。只要您通过内置操作执行按位操作，运行时就会负责将您的代码映射到语义等效的指令。我想说的是：

byte f(byte a, byte b){return a ^ b;} // or whatever

必须在它运行的每个平台上表现相同。如果您正在执行此“不安全”操作，则 Marc Gravell 的 cmets 确实适用。这可能是你打算做什么 - 我有点不清楚。

【讨论】：

我是低级编程的新手，感觉标题没有反映问题的主体。我的目标是看看 C# 在低级操作方面能做什么？您的 FieldOffsetAttribute 示例很有趣，并且与我正在寻找的内容相关。您会建议哪些修订？
我没有任何第一手经验，这取决于你想做什么。如果您打算将 8 个字节视为 64 位长，则您必须了解其 C# 语义（正如 Marc 所说），但我猜这就是您将获得主要性能改进的方式。但是根据您的情况，使用非托管 C++ 编写此关键代码并制作不同的 x64 和 x86 二进制文件可能更有意义。然后你就可以完全访问你想要的一切。