考虑到作为独立计算引擎的对象的核心模型（存储是实例变量，CPU 是类方法）响应从一个到另一个传递的消息，Smalltalk 似乎非常适合大规模并行处理核心数。然而，Smalltalk 在这个领域仍然非常薄弱，它依赖于自己的模拟多任务功能，而这些功能并没有利用现代处理器的硬件功能。
这是为什么呢？主要问题是什么？可变性是关键，还是 Smalltalk 特有的东西？
首先，让我们回想一下，GemStone 证明了 Smalltalk 可以扩展以支持并行计算。当然，问题仍然存在，因为 GemStone 是一个非常复杂的系统（例如，在垃圾收集器中思考！）并且所有其他方言都不会这样做。
并行计算需要线程安全的代码；否则竞争条件会一直出现。问题在于，使 Smalltalk 代码线程安全会增加各处的复杂性。例如考虑一下
OrderedCollection >> addLast: anObject
lastIndex = array size ifTrue: [self makeRoomAtLast].
lastIndex := lastIndex + 1.
^array at: lastIndex put: newObject
这些代码行之间的中断可能会导致接收器的内部状态不一致。当然，这种情况也可能发生在非并行执行中，因为 Smalltalk 支持中断。然而，Smalltalk 使用此功能的方式仅限于不经常发生的关键部分，因此在某种程度上受到控制。
之所以在Smalltalk中添加线程安全代码不是那么自然，是因为在Smalltalk中我们有一个图像。这意味着所有进程共享大量对象，包括所有类、编译方法等。系统及其应用程序广泛使用的 Smalltalk 的动态特性使事情变得更加困难。
根据我个人的经验，在 Smalltalk 中实现多核功能的一个好方法是启动不同的操作系统进程（无头映像的实例）并使用 Smalltalk 信号量和进程来协调它们。在这种方法下，每个操作系统进程都在主映像（带有 UI 的映像）中由 Smalltalk 进程表示。主映像和无头进程之间的通信可以依赖于套接字（或任何其他功能）。当然，调试时你要付出代价。事实上，您最终会在日志文件中跟踪大量事件，并在“无头”进程中打开调试器，直到您了解出了什么问题。但可以做到，不仅仅是作为演示，而是真正的“工业强”产品。
困难？无
只需启动多个 Pharo 实例并让它们通过套接字进行通信或将其最终数据保存到一个公共文件中。您的操作系统将管理每个实例并将其发送到不同的核心中执行。 OSProcess 模块提供了这样的功能，并且已经成功实现，如 Hydra 和 RoarVM ，问题是没有人使用它们。
实际上并行性最难的事情是让人们使用它。如今的硬件应用很少能达到单核 100% 的性能。我几乎没有让 Pharo 超过 10%。
与许多编程动态编程语言一样，Smalltalk 是一种开发人员性能语言，而不是一种应用程序性能语言。
如果您确实遇到如此繁重的处理问题，您应该使用 C 和 C++ 等语言，它们是非常注重应用程序性能的语言。不仅使用这些语言变得更加困难，而且即使使用正确的库，并行性也很难正确实现。硬件的设计非常奇怪，并且有很多你必须注意的问题。
这就是为什么并行性更适合这些编程语言。当然，您可以用 C/C++ 创建库并让 Pharo 或其他 Smalltalks 使用它们。 Python 就是这样做的。 Python 和 Pharo 非常相似，因为它们都使用 GIL 并具有绿色线程。问题是，您必须将线程连接回主线程，以便虚拟机能够直接访问它，但有一些方法可以解决这个问题，就像我说的那样，套接字通信、管道、共享内存映射文件等等。
Python的并行库都是基于C/C++的。
并行性本身是一个非常棘手的主题，即使您具有并行性，您的代码也可能会像在单线程和单核上运行一样慢。但这是应用程序性能的一个普遍问题，当您想要尽可能多地发挥作用时，您必须了解硬件的工作原理。
现在的硬件本身非常复杂。语言是您最不关心的问题。
在 Smalltalk 中完全有可能，但坦率地说，没有多少人对此感兴趣。我在过去 2 年经常光顾的 Pharo 邮件列表中看到了有关并行性的问题，也许有一两次。即使对于并发性，也很少有人提出相关问题。
ObjectConnect 的 Smalltalk MT 实现了 Windows 原生多线程。 (http://objectconnect.com/)