声称自己不“多核”友好的程序

您会时不时看到这个短语或类似词，通常指的是声称它们并非旨在充分利用多核处理器的程序。这在视频游戏编程中尤其常见。（当然，许多程序没有并发并且不需要它，例如基本脚本等）。

怎么会这样？许多程序（尤其是游戏）固有地使用并发性，并且由于OS负责CPU上的任务调度，那么这些程序是否固有地没有利用可用的多个内核？在这种情况下，“利用多核”意味着什么？这些开发人员实际上是在禁止OS任务调度并强制进行亲和力还是自己进行调度？（听起来像是主要的稳定性问题）。

我是Java程序员，所以也许由于抽象或其他原因我不必处理这个问题。

良好的并发性不仅需要在应用程序中抛出几个线程并希望达到最佳状态，还需要更多。从令人尴尬的并行到纯顺序，程序并发的方式有很多。任何给定的程序都可以使用阿姆达尔定律来表达问题或算法的可扩展性。令人尴尬的并行应用程序的几个条件是：

• 没有共享状态，每个函数仅取决于传入的参数
• 无法访问物理设备（图形卡，硬盘驱动器等）

还有其他条件，但仅凭这两个条件，我们就能理解为什么特别是游戏不像您想的那样利用多核优势那么容易。首先，将要共享的世界模型必须共享，因为不同的功能可以计算物理，运动，应用人工智能等。其次，该游戏模型的每一帧都必须使用图形卡在屏幕上进行渲染。

公平地说，许多游戏制造商都使用第三方生产的游戏引擎。花费了一段时间，但是这些第三方游戏引擎现在比以前更加并行。

在处理有效的并发方面存在更大的架构挑战

并发可以采用多种形式，从后台运行任务到对并发的完整体系结构支持。某些语言为您提供了非常强大的并发功能，例如ERLANG，但它要求您对构建应用程序的方式进行不同的思考。

并非每个程序都真正需要完整的多核支持的复杂性。这样的示例之一是税务软件或任何表单驱动的应用程序。当您大部分时间都花在等待用户做某事上时，多线程应用程序的复杂性就没那么有用了。

一些应用程序使自己可以使用更尴尬的并行解决方案，例如Web应用程序。在这种情况下，平台以令人尴尬的方式并行启动，这取决于您不必强加线程争用。

底线：

并非所有应用程序都没有充分利用多个线程（因此没有内核）而受到真正的伤害。对于那些受此影响的应用程序，有时计算对并行处理不友好，或者协调起来的开销会使应用程序更加脆弱。不幸的是，并行处理仍然不如要做的好。

许多程序（尤其是游戏）固有地使用并发性，

不，实际上是相反的。大多数应用都是以单线程思维方式编写的，开发人员从未进行必要的更改来支持并发。

在C，C ++和C＃中，您需要明确告知应用程序启动新线程和/或进程。

我认为您过多地关注线程的调度，而没有过多关注潜在线程中的数据处理。跨线程和/或进程共享数据需要某种形式的同步。如果您将应用程序更改为使用多个线程，但未能实现该同步，则可能会发现很多难以跟踪代码中的错误的地方。

对于我研究过的多线程应用程序，我通常从不担心调度，而只担心数据同步。我唯一需要担心的问题是，由于数据同步不正确，我在追逐比赛条件时。

通常，当应用程序说它不能使用多个内核时，这意味着它们没有适当的同步来保护数据操作。

这与多核无关，而与多线程有关。操作系统可以调度线程在其喜欢的任何内核上运行，并且这种调度对于正在调度的程序是透明的。但是，许多程序不是使用多个线程编写的，因此它们只能一次在一个内核上运行。

为什么要编写单线程程序？它们更易于编写和调试：一种事情接连发生（而不是同时发生并可能互相影响的多种情况）。否则您的程序可能没有针对多核计算机（就像旧游戏一样）。在某些情况下，如果上下文切换和线程之间的通信所产生的开销超过了并行执行所获得的速度，则多线程程序甚至可能比单线程版本运行得慢（程序的某些部分可能无法并行化）。

这不是一个完整的答案。这是一个警告性的故事。

有一天我以为我会向我的并发编程课程中的学生展示一个并行的快速排序。我认为Quicksort应该很好地并行化。我使用了两个线程。在我的单核计算机上运行它。结果是：

• 单线程版本为14秒。
• 2线程版本为15秒。

这是我所期望的。

然后，我在较新的双核计算机上进行了尝试。

• 单线程版本为11秒。
• 2线程版本为20秒。

这两个线程共享剩余任务的队列。似乎队列对象的字段在一个内核的缓存和另一个内核的缓存之间来回移动。