访问相同内存的核心数量是否有实际限制？

Question

当前向计算机添加内核的趋势是否会继续？或者，对于一组内存可以提供的内核数量是否存在一些理论上的或实际的限制？

换句话说：是将来容易的大功率台式电脑在使用一组内存1024个内核，还是容易有32组记忆，每个由32个内核访问？

或者另一种方式：我有一个4核的机器上运行良好，使用总CPU的显著量多线程程序。随着这个项目的规模不断扩大，并做了更多的工作，我能否有理由相信更强大的机器可以运行它？ 或我应该认真思考如何在多台机器上运行多个会话（或以任意多组内存）来完成工作？

换句话说，是一种纯粹的多线程方法来设计将我留在死胡同里？ （由于使用单线程方法，并取决于几年前CPU速度的持续改进）。该程序不太可能在花费超过3,000美元的机器上运行。如果那台机器不能完成这项工作，工作就不会完成。但是，如果这台3000美元的机器实际上是由32台独立电脑组成的网络（虽然它们可能共享相同的散热风扇），并且我继续采用大规模多线程方法，但机器将能够完成这项工作，但该程序不会，我会陷入一个尴尬的境地。

分布式处理看起来比多线程更大的痛苦，但如果这可能在我的未来，我想要一些警告。

Answer 1

会增加内核的计算机目前的趋势继续下去吗？

是，GHz的比赛结束。在现有技术上再加快速度是不现实的。物理学已经开始了。制造芯片的技术可能会发生戏剧性的变化，这让我们能够绕过这一切，但这显然不是“即将到来”。

如果我们不能拥有更快的核心，获得更多能量的唯一途径是拥有更多核心。

或者是否对一组内存可以提供的内核数量有一定的理论或实际限制？

绝对有一个极限。在共享内存系统中，内存是共享资源并且带宽有限。

Max processes = (Memory Bandwidth)/(Bandwidth required per process) 

现在 - 这是每个进程的带宽“数字将缓存减少，但缓存成为他们是否是一致的彼此，因为每个人都访问内存中的同一区域效率较低。 （您不能缓存存储器写如果另一个CPU可能需要你写的）

当你开始谈论庞大的系统，这样的共享资源成为主要的问题。它可能是内存带宽，CPU周期，硬盘访问，网络带宽。这涉及整个系统的结构。

---

你似乎真的在追求未来的愿景，所以你可以做好准备。这是我的要求。

我想我们将看到软件开发人员在他们的程序中看到并行的方式发生了变化。目前，我认为很多软件开发人员认为使用多线程的唯一方法是让他们中的很多人执行相同的操作。麻烦的是，他们都在争夺同样的资源。这就意味着需要引入大量的锁定，这会导致性能问题，以及微妙的错误，这些错误会令人生气并且耗费时间来解决。

这是不可持续的。

制造在20世纪初就开始了，建造大量汽车的最快方式并不是让很多人在一辆车上工作，然后，当这件事完成时，将他们全部移动到下一辆车。将汽车的建造过程分解为许多小型工作，其中一项工作的产出将成为下一个工作的补充。他们称之为装配线。在硬件设计中，它被称为管道铺设，我认为我们会看到越来越多的软件设计转向它，因为它最大限度地减少了共享资源的问题。

好的 - 在一个阶段的输出和下一个输入仍然有一个共享资源，但这只是在两个线程/进程之间，并且更容易处理。标准方法也可以用于这些接口的制作方式，消息队列库似乎正在取得重大进展。

虽然没有一个解决所有问题的方法。这种类型的管线对于可以吸收一些延迟的高吞吐量应用非常适用。如果你不能忍受延迟，你别无选择，只能去'一个任务'的许多工作人员的路线。那些是你理想地想要扔在SIMD机器/像GPU一样的阵列处理器的那些，但它只能真正胜过某种类型的问题。这些问题是有很多数据需要以相同的方式处理的问题，并且数据项之间的依赖关系很少或根本不存在。

掌握了流水线系统的消息队列技术和类似知识，并通过OpenCL等库在GPU上实现细粒度的并行处理，可以让您深入了解光谱的两端。

Answer 2

更新：多线程代码可能运行在群集计算机上，因此此问题可能没有我想象的那么重要。

我仔细检查了JLS第17章中的Java内存模型，发现它并不是而是镜像了大多数计算机的典型注册表缓存主存模型。多内存机器有机会将数据从一个内存转移到另一个（并且从一个机器上的一个线程运行到另一个机器上运行的另一个线程）。于是我开始寻找可以在多台机器上运行的JVM。我发现了几个旧的参考文献 - 这个想法已经存在，但没有遵循。然而，如果我正在读他们的公关权，那么一家公司Terracotta似乎有些东西。

无论如何，它似乎是PC通常包含几个集群计算机时，可能会有一个多机JVM。

我在Java世界以外找不到任何东西，但微软的CLR应该提供相同的机会。 C和C++以及所有其他.exe语言可能会更困难。然而，Terracotta的网站更多地讨论了在多台机器上连接JVM而不是一个JVM，所以他们的技巧也可能适用于可执行语言（如果需要，也可能是CLR）。