В чем заключается сложность параллельного создания Smalltalk?

Question

Учитывая основную модель объектов, которые являются независимыми вычислительными двигателями (хранилище является экземпляром vars, CPU - это методы класса), реагируя на сообщения, переданные от одного к другому, казалось бы, Smalltalk был бы естественным подходом для параллельной обработки на массивных количество ядер. Тем не менее, это область, где Smalltalk по-прежнему очень слаб, отвечая на свои собственные моделируемые функции многозадачности, которые не используют аппаратные возможности современных процессоров.

Почему это? Каковы основные проблемы? Является ли изменчивость ключом, или это нечто более специфичное для Smalltalk?

Answer 1

Прежде всего, напомним, что 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. При таком подходе каждый процесс ОС представлен в основном изображении (с пользовательским интерфейсом) процессом Smalltalk. Связь между основным изображением и безголовыми процессами может основываться на сокетах (или любой другой функции). Конечно, вы платите цену при отладке. Фактически, вы в конечном итоге отслеживаете множество событий в файлах журналов и открываете отладчики в «безгласных» процессах, пока не поймете, что пошло не так. Но это может быть сделано не только как демонстрация, но и для реального «промышленного сильного» продукта.

Answer 2

Сложность? Нет

Просто запустите несколько экземпляров Pharo и попросите их обмениваться данными через сокеты или сохранить их окончательные данные в общий файл. Ваша ОС будет управлять каждым экземпляром и отправлять его для выполнения в diffirent core. Модуль OSProcess предлагает такую ​​функциональность и имеет успешные реализации, такие как Hydra и RoarVM, проблема в том, что их никто не использует.

На самом деле самое сложное в параллелизме - заставить людей использовать его. Сегодняшние аппаратные приложения редко попадают в 100% одного ядра. Я едва сделал Фаро выше 10%.

Также как и многие языки программирования динамического программирования Smalltalk - это язык разработки разработчика, а не язык приложений.

Если у вас действительно есть такая серьезная проблема с обработкой, вы должны использовать такие языки, как C и C++, которые являются ориентированными на производительность приложений языками.Не только его труднее использовать этот язык, но даже параллелизм очень трудно сделать правильно даже с правой библиотекой. Аппаратное обеспечение очень странное, мудрый дизайн, и там, как тонна ошибок, о которых вы должны знать.

И вот почему параллелизм лучше подходит для этих языков программирования. Конечно, вы можете создавать библиотеки на C/C++ и использовать Pharo или другие smalltalks. Python делает это. Python и Pharo очень похожи, поскольку они используют GIL и имеют зеленые потоки. Получается, что вам придется присоединяться к вашим потокам обратно в основной поток, чтобы виртуальная машина имела прямой доступ к ней, но есть способы обойти это, как я уже говорил, сокетную связь, трубы, файлы с общей памятью и многое другое.

Патентные библиотеки Python - все основанные на C/C++.

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

Аппаратное обеспечение сегодня является суперкомплексным. Язык - это наименьшая из ваших проблем.

В Smalltalk вполне возможно, но, откровенно говоря, в этом не так много людей. Я видел вопросы о параллелизме в списках рассылки Pharo, которые я посещаю последние два года, может быть, один или два раза. И даже для параллелизма его очень редко кто-то задает вопрос об этом.