使用位域来节省内存答案

【问题标题】：Using Bit Fields to save memory使用位域来节省内存
【发布时间】：2014-10-30 16:03:18
【问题描述】：

我目前正在大学里开始一个关于 ps3 的项目，我们得到了代码优化程度的分数。

我和我的伙伴一直在研究位字段，因为我们正在处理数百万个 0 到 255 之间的数字。我们想我们是否可以将 4 个整数打包成 4 个字节（典型的整数大小的内存块）而不是一个我们可以将使用的内存减半。我们认为处理数据是我们可以做出的最大优化之一，我们正在研究一切。值得麻烦吗？就编辑整数而言，这似乎是一件相当困难的事情。我们还有一个问题，理想情况下，我们需要依赖于数字的不同位字段，因为多达 255 个需要 9 位，但大多数不需要这么多位。

然后，我们还可以将数据快速传递到 spu 处理器，并希望在我们将并行性引入代码时看到巨大的改进。

【问题讨论】：

“4 个整数到 4 个字节”不需要位域。使用char 类型，每个类型占用一个字节（unsigned char 用于从 0 到 255 的值）。如果您希望位域小于一个字节，请使用位域。
优化通常是速度和空间之间的权衡。位域可以节省空间，但处理速度比整数慢。
这是您应该阅读的similar analysis。您将不得不考虑生成的机器代码将如何变化。
255 需要 8 位，而不是 9。
您的压缩看起来像 google 的 varints - developers.google.com/protocol-buffers/docs/encoding。您将需要时间来压缩/解压缩数据，这可能比传输整个整数更糟糕。

标签： c++ bit-manipulation ps3

【解决方案1】：

如 cmets 所述：

“优化通常是速度和空间之间的权衡。位域可以节省空间，但处理速度比整数慢。”

位域很少使用有几个原因

它们操作起来很复杂，并且不会在内存使用方面产生巨大的节省。如果您的值小到足以保证一个位域，那么 char 应该可以充分地完成这项工作，char 中的 8 位与 int_32 中的 32 位相比，不会增加访问数据的开销。
他们是implementation specific - 小心。

一般经验法则：

让它工作
- 如果慢，就让它工作得更快
- 如果太大，则使其更紧凑

（请注意，如果您知道要存储的内容，则可以预先估计大小。直到您开始优化缓存行（速度和内存），只要它“适合”，您可能会给自己一个内存使用情况）

仅供参考，位域最常见的用法是将数据打包成专为传输而设计的数据结构。 This is just the first example I could find

【讨论】：

感谢您的回复，非常感谢。无符号字符是完美的！
仅供参考，访问硬件设备时经常使用位操作。大多数代码不使用结构中的位字段，而是使用位值的位与和位或。这种技术阐明了在查看结构的位字段时可能不明显的位顺序。
位域是完全可移植的。假设位域的布局是一致的。在“传输数据结构”中使用位域的想法错误地依赖于后一种假设。
@user3375989 正如 Basile 在他的回答中所说，如果 char 大于 8 位，则可能需要使用 uint8_t（通常情况并非如此，但标准仅指定 minimum 大小）
@MSalters 是的 - 问题是在不同机器之间移动数据时使用它们。当机器 A 上的数据在机器 A 上使用时，使用相同代码构建的应用程序可以正常工作，机器 B 上的数据也是如此，但机器 A 上的数据可能无法在机器 B 上正确处理。修改后的答案为 implementation specific instead

【解决方案2】：

您只需要来自<cstdint> C++ 标头（或C99 中的<stdint.h>）的int8_t（有符号）或uint8_t（无符号）8 位整数。无需使用位字段（不可移植、缓慢且不易使用 - 例如，您无法获取它们的地址或引用）。

对于并行向量处理，还可以考虑OpenCL 和OpenMP，最后考虑OpenACC。最好使用最新的编译器，它也支持C++11。请注意，SPU 是非常特定于硬件的。

^{根据您的应用程序，您可能会对 SPU 的实际性能感到有些失望，而且 OpenCL、OpenMP 或 OpenACC 都不是灵丹妙药。并行很难。}

【讨论】：

是的，我知道并行性的成功程度完全取决于应用程序/问题。
比这更糟糕。并行性还取决于系统（操作系统、硬件和编译器）和数据