Существует ли верхний предел количества объектов в образе Smalltalk?

Я провожу эксперимент НЛП, в котором понятия являются агентами системы, предназначенной для порождения эмерджентных свойств, состоящих из новых понятий (вот ссылка для тех, кто не знает, что такое Emergence). Smalltalk (особенно диалект Pharo) кажется идеальным для такого рода приложений из-за легкости, с которой я могу создавать полностью инкапсулированные концептуальные объекты, которые относятся друг к другу как независимые агенты, и того факта, что SmallTalk позволяет мне проверять состояние системы во время ее работы.

Меня беспокоит, не начнет ли система задыхаться, если присутствует слишком много объектов и все отправляют сообщения друг другу. Теоретически моя реализация может породить миллионы концептуальных объектов, и я не хочу тратить время на разработку этого в SmallTalk, если система не может обрабатывать что-то настолько большое.

  1. Существуют ли ограничивающие факторы (программные, а не аппаратные) относительно количества активных объектов в образе SmallTalk?

  2. Может ли система справиться с потоком сообщений, который присутствует в системе с миллионами болтающих объектов?

Заранее спасибо за вашу помощь!


smalltalk pharo squeak
person snerd    schedule 31.10.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я полагаю, что внутренний рабочий размер указателей объектов в Pharo по-прежнему составляет 32 бита. Были разговоры о 64-битных версиях, но одно дело иметь 32-битную виртуальную машину, работающую на 64-битной машине, и совсем другое — иметь настоящую 64-битную виртуальную машину.

Таким образом, здесь есть неявный предел, но все же есть место для «миллионов» объектов. Начните достигать «сотни миллионов», и вы вполне можете столкнуться с некоторыми ограничениями.

Наличие миллионов объектов в конце концов не является проблемой, теперь управление переходит к потокам, а в этом случае Pharo не выполняет много потоков. Таким образом, на самом деле речь идет о том, сколько реальных различных контекстов у вас будет, не обязательно объектов как таковых.

Наличие цепочки из миллионов объектов, взаимодействующих друг с другом, на самом деле не имеет большого значения, вы просто столкнетесь с любыми накладными расходами на передачу сообщений в базовой виртуальной машине, чтобы ограничить сырую производительность. Pharo работает довольно быстро, но не так быстро, как Java. Будет ли это достаточно быстро для вас, вам решать.

Я также не могу говорить о том, насколько хорошо Pharo GC обрабатывает миллионы живых объектов, я могу только предположить, что это 2013 год, Squeak (на котором основан Pharo) существует с середины 90-х годов, технология GC сейчас довольно зрелая, и я не подозреваю, что GC Pharo в этом отношении ужасно ужасен.

Я бы просто провел несколько микротестов и попробовал сам.

person Will Hartung    schedule 31.10.2013
comment
w00t - т/г за быстрый ответ! - person snerd; 01.11.2013
comment
Как и обновление, выпущенное несколько лет спустя, Squeak (а также Pharo и Cuis) доступен в форме 64-битного указателя. Как и VisualWorks, GemTalk и, вероятно, другие реализации. Так что шансы исчерпать идентичность объекта невелики. А с текущими ценами на оперативную память шансы иметь достаточно памяти, чтобы решить проблему с переменным мечом, минимальны. - person timrowledge; 26.03.2018

arrow_upward
3
arrow_downward

Относительно 1: количество объектов ограничено виртуальным адресным пространством, доступным виртуальной машине, которое в стандартных сборках составляет всего несколько сотен МБ. Мой текущий образ Squeak содержит более 3,5 миллионов экземпляров Object в состоянии ожидания, что должно дать вам представление о том, что возможно.

Относительно 2: My Squeak image отправляет около 26 миллионов сообщений в секунду на моем не очень современном Intel Core i7 2620M (но, конечно, использует только одно ядро).

Однако я сомневаюсь, что вы будете удовлетворены результатом вашего текущего подхода. Вы упомянули о проверке состояния системы — что действительно прекрасно в Squeak/Pharo — но вы не можете (вручную) проверять состояние миллионов объектов. Но опять же, я не знаю точно, что вы задумали ;)

person Leo    schedule 31.10.2013
comment
t / y, а также за то, что так быстро прыгнул на это! К вашему сведению: я не собираюсь проверять все объекты сразу, но мне нужно проверять структуры понятий (понятия могут самовоспроизводиться, порождая более сложные формы, с которыми они все еще связаны), чтобы увидеть, что делается, как это делается, и что заставило это быть сделано. Пока я могу это делать, я gtg. - person snerd; 01.11.2013