在 64 位机器上,我可以安全地并行处理 64 位四字的各个字节吗?
Posted
技术标签:
【中文标题】在 64 位机器上,我可以安全地并行处理 64 位四字的各个字节吗?【英文标题】:On a 64 bit machine, can I safely operate on individual bytes of a 64 bit quadword in parallel? 【发布时间】:2017-10-24 17:34:27 【问题描述】:背景
我正在对图像中的行和列进行并行操作。我的图像是 8 位或 16 位像素,我在 64 位机器上。
当我对列进行并行操作时,两个相邻的列可能共享相同的 32 位 int
或 64 位 long
。基本上,我想知道我是否可以安全地并行操作同一个四字的各个字节。
最小测试
我编写了一个最小的测试函数,但我无法使其失败。对于 64 位 long
中的每个字节,我同时在顺序有限的域 p
中执行连续乘法。我知道Fermat's little theorem a^(p-1) = 1 mod p
当p
是素数时。我为我的 8 个线程中的每一个更改了 a
和 p
的值,并执行了 k*(p-1)
与 a
的乘法运算。当线程完成时,每个字节应该是 1。事实上,我的测试用例通过了。每次运行时,我都会得到以下输出:
8 101010101010101 101010101010101
我的系统是 Linux 4.13.0-041300-generic x86_64,配备 8 核 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz。我用 g++ 7.2.0 -O2 编译并检查了程序集。我添加了“INNER LOOP”的程序集并对其进行了评论。在我看来,生成的代码是安全的,因为存储只是将低 8 位写入目标,而不是进行一些按位算术并存储到整个字或四字。 g++ -O3 生成类似代码。
问题:
我想知道这段代码是否总是线程安全的,如果不是,在什么情况下它不是。也许我很偏执,但我觉得为了安全起见,我需要一次对四字进行操作。
#include <iostream>
#include <pthread.h>
class FermatLTParams
public:
FermatLTParams(unsigned char *_dst, unsigned int _p, unsigned int _a, unsigned int _k)
: dst(_dst), p(_p), a(_a), k(_k)
unsigned char *dst;
unsigned int p, a, k;
;
void *PerformFermatLT(void *_p)
unsigned int j, i;
FermatLTParams *p = reinterpret_cast<FermatLTParams *>(_p);
for(j=0; j < p->k; ++j)
//a^(p-1) == 1 mod p
//...BEGIN INNER LOOP
for(i=1; i < p->p; ++i)
p->dst[0] = (unsigned char)(p->dst[0]*p->a % p->p);
//...END INNER LOOP
/* gcc 7.2.0 -O2 (INNER LOOP)
.L4:
movq (%rdi), %r8 # r8 = dst
xorl %edx, %edx # edx = 0
addl $1, %esi # ++i
movzbl (%r8), %eax # eax (lower 8 bits) = dst[0]
imull 12(%rdi), %eax # eax = a * eax
divl %ecx # eax = eax / ecx; edx = eax % ecx
movb %dl, (%r8) # dst[0] = edx (lower 8 bits)
movl 8(%rdi), %ecx # ecx = p
cmpl %esi, %ecx # if (i < p)
ja .L4 # goto L4
*/
return NULL;
int main(int argc, const char **argv)
int i;
unsigned long val = 0x0101010101010101; //a^0 = 1
unsigned int k = 10000000;
std::cout << sizeof(val) << std::endl;
std::cout << std::hex << val << std::endl;
unsigned char *dst = reinterpret_cast<unsigned char *>(&val);
pthread_t threads[8];
FermatLTParams params[8] =
FermatLTParams(dst+0, 11, 5, k),
FermatLTParams(dst+1, 17, 8, k),
FermatLTParams(dst+2, 43, 3, k),
FermatLTParams(dst+3, 31, 4, k),
FermatLTParams(dst+4, 13, 3, k),
FermatLTParams(dst+5, 7, 2, k),
FermatLTParams(dst+6, 11, 10, k),
FermatLTParams(dst+7, 13, 11, k)
;
for(i=0; i < 8; ++i)
pthread_create(threads+i, NULL, PerformFermatLT, params+i);
for(i=0; i < 8; ++i)
pthread_join(threads[i], NULL);
std::cout << std::hex << val << std::endl;
return 0;
【问题讨论】:
C++ 标准版并不特别关心系统的字长。只要不同的线程从不在同一个字节上竞争,就可以了。 (定义的行为)你正在做的转换和类型双关也很好,因为严格别名规则对char
有一个例外。然而,您有多个线程写入内存中的相邻字节这一事实将导致 性能 问题,即使不存在会影响代码。
感谢@Mystical。我会确保牢记性能问题。并在适合性能时确保线程对不同的单词进行操作。
@MFisherKDX:我创建了一个小基准,并提出了一个问题:***.com/questions/46919032/…
@BeeOnRope 如果它需要在 cmets 中解释为什么它是重复的,也许我不应该将它作为重复关闭。特别是因为***.com/questions/47008183/… 也比我链接的两个更多。
@PeterCordes - 你不敢暗示 C 和 C++ 在某种程度上有任何共同点。你会被你指的是哪种语言和C不是C++和C++不是C人群私刑:)。事实上,我不得不四处搜索以检查 C11
显然提供了与 C++11 类似的保证来回答这个问题。
【参考方案1】:
答案是肯定的,您可以通过不同的线程安全地对 64 位四字的各个字节进行并行操作。
它的工作原理令人惊讶,但如果它不起作用,那将是一场灾难。所有硬件的行为都好像一个内核在其自己的内核中写入一个字节,不仅标记高速缓存线是脏的,而且还标记了其中的哪些字节。当缓存线(64 或 128 甚至 256 字节)最终被写入主存时,只有脏字节实际修改了主存。这是必不可少的,否则当两个线程在处理碰巧占用同一缓存行的独立数据时,它们会互相丢弃对方的结果。
这可能对性能不利,因为它的工作方式部分是通过“缓存一致性”的魔力,当一个线程写入一个字节时,系统中具有相同数据行的所有缓存都会受到影响。如果它们是脏的,它们需要写入主内存,然后要么删除高速缓存行,要么从另一个线程捕获更改。有各种不同的实现方式,但通常都很昂贵。
【讨论】:
您说得对,它是安全的,但您的第二段不是 x86 或任何其他常见架构上缓存一致性的硬件机制。实际发生的情况是 CPU 在“拥有”该行之前无法修改缓存行(MESI 的独占/修改状态),因此没有其他内核拥有该行的副本,无论是脏的还是其他的,而存储提交L1D。相关:Can modern x86 hardware not store a single byte to memory?. 使用 MESI 的硬件不需要按字节跟踪脏/干净,事实上大多数都不需要。 DDR1/2/3/4 DRAM 以 64 字节突发传输,与高速缓存行大小相同。您的最后一段似乎是在您修改之前描述缓存行的其他副本无效。这是必不可少的部分:如果多个核心确实写入了相同的字节,那么仅基于每个字节跟踪脏度会导致缓存不一致。 缓存一致意味着两个缓存对于同一行中的任何字节都不能有冲突的数据,因此任何有效的副本都可以安全读取。 谢谢。我认为您的 cmets 更好地解释了该机制的实际工作原理。无论如何,它仍然必须在字节级别工作,否则我们将永远无法让任何 SMP 代码工作。以上是关于在 64 位机器上,我可以安全地并行处理 64 位四字的各个字节吗?的主要内容,如果未能解决你的问题,请参考以下文章
64 位比较交换 (CAPS) 是不是应该在 32 位机器上工作? (或 64 位机器?)