Smalltalk图像中的对象数量是否有上限？

Question

我正在组建一个NLP实验，其中概念是系统中的代理，旨在产生由新概念组成的Emergent属性（here's a link用于那些不知道Emergence是什么的人）。 Smalltalk（特别是Pharo方言）似乎是这种应用程序的理想选择，因为我可以轻松地创建完全封装的概念对象，这些对象作为独立代理彼此相关，并且SmallTalk允许我检查系统正在运行的状态。

我担心的是，如果存在太多对象并且所有对象都发送消息，系统是否会开始阻塞。从理论上讲，我的实现可以产生数百万个概念对象，如果系统无法处理那么大的东西，我不想把时间花在SmallTalk上。

1. 是否有限制因素（软件因素，而非硬件） 关于SmallTalk图像中活动对象的数量？

2. 系统可以处理可能存在的消息流量 在一个拥有数百万个健谈对象的系统中？

提前感谢您的帮助！

Answer 1

关于1：对象的数量受VM可用的虚拟地址空间的限制 - 在标准版本中，虚拟地址空间仅为几百MB。我当前的Squeak图像在其空闲状态下包含超过350万个Object个实例 - 这应该会让您对可能的内容有所了解。

关于2：我的Squeak图像在我不太新的英特尔酷睿i7 2620M上每秒执行大约2600万条消息发送（当然只使用一个核心）。

但是，我怀疑您对目前方法的结果感到满意。你谈到了检查系统的状态 - 在Squeak / Pharo中真的非常棒 - 但是你不能（手动）检查数百万个物体的状态。但话说回来，我不确切地知道你在做什么;）

Answer 2

我相信Pharo中对象指针的内部工作大小仍为32位。有64b版本的喋喋不休，但是在64b机器上运行32b VM是一回事，而另一件事就是拥有一个实际的，64b直通VM。

所以那里有一个隐含的限制，但仍有“数百万”对象的空间。开始接触“百万的百万”，你可能会遇到一些限制。

最终拥有数百万个对象并不是一个真正的问题，现在它转移到控制线上，而Pharo在这种情况下并没有做太多的线程。因此，实际上你将拥有多少实际不同的上下文，而不一定是对象本身。

拥有数百万个对象链相互交换并不是什么大不了的事，你只需要在底层虚拟机中运行任何传递开销的消息来限制原始性能。 Pharo相当快，但它不是Java快。是否足够快，你可以回答。

我也不能说Pharo GC处理数百万个活物的程度如何，我只能说它是2013年，Squeak（Pharo所依据的）自90年代中期以来一直存在，GC技术已经相当多了现在已经成熟了，我并不怀疑Pharo的GC在这方面非常糟糕。

我会简单地做一些微基准测试并亲自尝试。