目前向计算机添加核心的趋势会继续吗？或者对一组内存可以提供的内核数量有一些理论上或实际限制吗？
另一种方式：未来的高性能台式电脑是否容易拥有使用一组内存的1024个内核，或者它是否容易拥有32组内存，每个内存是由32个内核访问的？或者另一种方式：我有一个多线程程序，在4核计算机上运行良好，占用了大量的CPU。随着这个程序规模的扩大和更多的工作，我能否有理由相信更强大的机器可以运行它？ 或我是否应该认真考虑在多台计算机上运行多个会话（或者无论如何都要多组内存）才能完成工作？
换句话说，纯粹的多线程设计方法是否会让我陷入死胡同？ （因为使用单线程方法并且依赖于CPU速度的持续改进，几年前会做什么？）该程序不太可能在花费超过3000美元的机器上运行。如果那台机器无法完成工作，那么工作将无法完成。但如果这台3000美元的机器实际上是一台由32台独立计算机组成的网络（虽然它们可能共用相同的冷却风扇）并且我继续采用大规模多线程方法，机器将能够完成工作，但程序不会，而且我将会处于一个尴尬的境地。
分布式处理看起来比多线程更痛苦，但如果这可能在我的未来，我想要一些警告。
答案 0 :(得分：1)
目前向计算机添加核心的趋势会继续吗？
是的，GHz比赛结束了。在当前技术上不再提高速度是不切实际的。物理学已经阻碍了。制造芯片的技术可能会发生戏剧性的转变，这使我们能够绕过这一点，但它显然不是“即将到来”。
如果我们不能拥有更快的内核，获得更多功能的唯一方法就是拥有更多内核。
或者对一组内存可以提供的内核数量有一些理论或实际限制吗？
绝对有限制。在共享存储器系统中，存储器是共享资源并且具有有限的带宽。
Max processes = (Memory Bandwidth) / (Bandwidth required per process)
现在 - 缓存可以减少“每个进程的带宽”数字，但如果每个人都必须相互连贯，因为每个人都在访问相同的内存区域，缓存效率会降低。 （如果另一个CPU可能需要您编写的内容，则无法缓存内存写入）
当你开始讨论庞大的系统时，像这样的共享资源成为主要问题。它可能是内存带宽，CPU周期，硬盘访问，网络带宽。它归结为整个系统的结构。
你似乎真的要求展望未来，以便你做好准备。这是我的看法。
我认为我们会看到软件开发人员在程序中看到并行性的方式发生了变化。目前，我想说很多软件开发人员都认为使用多线程的唯一方法就是让很多人做同样的事情。麻烦的是他们都在竞争相同的资源。这意味着需要引入大量锁定，这会导致性能问题，以及令人烦恼且耗时的细微错误。
这是不可持续的。
制造工作在20世纪初制定，制造大量汽车的最快方法是不要让很多人在一辆车上工作，然后，当一辆车完成后，将它们全部移到下一个车上汽车。这是将汽车制造过程分成许多小工作的过程，其中一个工作的输出是下一个工作。他们称之为装配线。在硬件设计中，它被称为管道衬里，我认为我们会看到越来越多的软件设计转向它，因为它最大限度地减少了共享资源的问题。
当然 - 在一个阶段的输出和下一个阶段的输入上仍然存在共享资源，但这仅在两个线程/进程之间，并且更容易处理。关于如何构建这些接口也可以使用标准方法，并且消息队列库似乎在这里取得了重大进展。
但是，对于所有问题，没有一种解决方案。这种类型的管道非常适合可以吸收一些延迟的高吞吐量应用。如果你不能忍受延迟，你就别无选择，只能选择“单一任务中的许多工人”路线。那些是你理想的想要在SIMD机器/阵列处理器（如GPU）上投掷的那些，但它只对某种类型的问题非常擅长。这些问题是以相同方式处理大量数据的问题，而且数据项之间几乎没有依赖关系。
熟悉流水线系统的消息排队技术和类似技术，并通过OpenCL等库在GPU上利用细粒度并行性，可以让您深入了解频谱的两端。
答案 1 :(得分：0)
更新：多线程代码可能在群集计算机上运行，因此可能这个问题不像我想象的那么重要。
我正在仔细检查JLS中的Java内存模型，第17章，并发现它不镜像大多数计算机的典型寄存器缓存主内存模型。多存储器机器有机会将数据从一个存储器干净地转移到另一个存储器（从一个机器上运行的一个线程到另一个机器上运行的另一个线程）。所以我开始搜索可以在多台机器上运行的JVM。我发现了几个旧的参考文献 - 这个想法已经存在，但没有遵循。然而，如果我正在阅读他们的PR，那么一家公司Terracotta似乎有所作为。
无论如何，似乎当PC通常包含多个集群机器时，可能会有一台多机JVM。
我在Java世界之外什么都找不到，但微软的CLR应该提供相同的机会。 C和C ++以及所有其他.exe语言可能更难。但是，Terracotta的网站更多地讨论了在多台机器上连接JVM而不是一台JVM，因此它们的技巧也可能适用于可执行语言（如果需要，可能还有CLR）。