我在某处读到，在页面边界旁边执行未对齐加载或存储之前(例如使用 _mm_loadu_si128/_mm_storeu_si128 内在函数)，代码应该首先检查整个 vector (在此case 16 bytes)属于同一页，不属于则切换到非 vector 指令。我知道如果下一页不属于进程，这是防止核心转储所必需的。
但是如果两个页面都属于进程怎么办(例如，它们是一个缓冲区的一部分，并且我知道该缓冲区的大小)？我写了一个小测试程序，它执行未对齐的加载和跨越页面边界的存储，它没有崩溃。在这种情况下，我是否必须始终检查页面边界，或者足以确保我不会溢出缓冲区？
环境:Linux、x86_64、gcc
最佳答案
分页行分割对性能不利，但不影响未对齐访问的正确性。 当您提前知道长度时，足以确保您不会读取超过缓冲区的末尾。
为了正确性，在实现类似 strlen 的东西时，您经常需要担心它，当您找到标记值时，循环会停止。该值可以位于 vector 中的任何位置，因此只需执行 16B 未对齐加载就会读取数组末尾。如果终止 0 在一页的最后一个字节中，并且下一页不可读，并且您的当前位置指针未对齐，则包含 0 的加载byte 还将包含来自不可读页面的字节，因此它会出错。
一种解决方案是执行标量直到您的指针对齐，然后加载对齐的 vector 。对齐加载总是完全来自一页，也来自一个缓存行。因此，即使您将读取字符串末尾之后的一些字节，也可以保证不会出错。 Valgrind虽然可能对此不满意，但是标准库 strlen 实现使用它。
除了对齐指针之前的标量，您可以从字符串的开头执行未对齐的 vector (只要它不会跨越页面行)，然后执行对齐的加载。第一个对齐的加载将与第一个未对齐的加载重叠，但这对于像 strlen 这样的函数来说完全没问题，它不关心它是否两次看到相同的数据。
出于性能原因，避免分页行可能是值得的。即使您知道您的 src 指针未对齐，让硬件处理高速缓存行拆分通常会更快。但在 Skylake 之前，页面拆分有大约 100c 的额外延迟。 (Down to 5c in Skylake)。如果你有多个指针可以相对于彼此不同地对齐，你不能总是只使用序言来对齐你的 src。 (例如 c[i] = a[i] + b[i]，c 对齐但 b 不对齐。)
在这种情况下，可能值得使用分支在页面拆分前后执行对齐加载，并将它们与 palignr 组合。
分支预测错误 (~15c) 比页面拆分延迟更便宜，但会延迟一切(不仅仅是加载)。因此它也可能不值得，这取决于硬件和计算与内存访问的比率。
如果您正在编写一个通常使用对齐指针调用的函数，则只使用未对齐的加载/存储指令是有意义的。任何检测未对齐的序言只是已经对齐的情况的额外开销，并且在现代硬件(Nehalem 和更新的)上，地址上的未对齐加载在运行时证明是对齐的，与对齐加载指令具有相同的性能。 (但是对于未对齐的加载，您需要 AVX 将其作为内存操作数折叠到其他指令中。例如 vpxor xmm0, xmm1, [rsi])
通过添加代码来处理未对齐的输入，您正在减慢常见的对齐情况以加快不常见的未对齐情况。对未对齐的加载/存储的快速硬件支持让软件在少数确实发生的情况下将其留给硬件。
(如果未对齐的输入很常见，那么值得使用序言来对齐您的输入指针，尤其是如果您使用的是 AVX。连续的 32B AVX 加载将缓存行拆分每隔一个负载。)
参见 Agner Fog's Optimizing Assembly guide更多信息，以及 x86 中的其他链接标记维基。
关于c - SSE:跨页边界的未对齐加载和存储，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37736496/