“嗯并行化”算法不能由多个线程加快

Question

对不起，问一个问题一个我知之甚少的话题，但这种想法真的被窃听了我，我一直没能找到在互联网上的任何答案。

背景： 我正在和我的一位计算机科学研究的朋友谈话。我大多在特设的发展，所以我大部分的CS概念的理解是在功能级（我知道如何使用他们，而不是他们的工作）。他说，转换“以及并行化”算法已经在单个线程运行到一个运行在多线程并没有导致他期待处理速度提高一点。

推理： 我问他是什么计算机的体系结构，他是上运行此算法，他说，16核心（非虚拟化）。根据我对多核处理器的了解，在多核上运行的算法的处理速度增加应该大致与其并行化程度成正比。

问题： 算法如何“正确并行化”并正确编程以在真正的多核处理器上运行，而不是多跑几次？是否有一些我在这里失踪的信息，或者更可能是实施的问题？

其他的东西：我问是否这些线程可能占用比任何单独的内核可用的功率更大，显然每个内核运行在3.4 GHz。这比算法所需要的要多得多，并且在运行诊断程序时，内核在运行时不会超时。

Answer 1

性能与核心数量往往是一个S-状的曲线 - 首先，它明显增加，但由于锁定，共享缓存以及他们的债务进一步核不加那么多，甚至可能会降低喜欢拍摄。因此没有什么神秘的。如果我们知道更多关于算法的细节，可以找到一个想法加快速度。

Answer 2

很可能共享东西。共享内容可能并不明显。

其中最常见的非显而易见的共享资源是CPU缓存。如果线程正在更新相同的高速缓存行，那么高速缓存行必须在CPU之间反弹，从而放慢一切。

这可能是因为访问（即使只读）在内存中彼此靠近的变量而发生的。如果所有访问都是只读的，那么它是可以的，但是如果即使一个CPU正在写入该缓存行，它也会强制反弹。

解决这个的蛮力方法是将共享变量到看起来像结构：

struct var_struct { 
    int value; 
    char padding[128]; 
}; 

而不是硬编码128，你可以研究什么样的系统参数或预处理宏定义的超高速缓存行您的系统类型的大小。

可以发生共享的另一个地方是系统调用。即使看似无辜的职能也可能在全球锁定。我似乎回想起有关解决这个问题的Linux，并回顾了返回进程和线程标识符以及父标识符的函数的锁。