Сравните Pharo vs Go

[Александр]

Переучиваюсь на Go...

Плююсь и матюкаюсь ) но продолжаю жрать кактус...

//много разных причин... даже сложно обсуждать.., но вот Go... и ничего особо с этим не поделать (сейчас)

Мне интересно, как решено "параллельное"  програмирование в PHaro?
что то есть, это ясно... можно форкнуть процесс с неким приоритетом...
Но очень мало информации обо всём этом плавает на поверхности..

[Dennis Schetinin]

Зеленые нити (Process, BlockClosure>>#fork(At:)), семафоры.

"Concurrent Programming in Pharo" by Yuriy Tymchuk [http://pillarhub.pharocloud.com/hub/Uko/concurrentProgrammingInPharo].

Promises и Futures — по вкусу

В рамках одного образа все это на одном процессоре/ядре. Вроде бы что-то там было для организации (эффективного?) обмена данными между образами (общая память?), но сейчас не нашел — могу вообще бредить по этому поводу :)

Ну, и не забываем учитывать это: https://blog.golang.org/concurrency-is-not-parallelism  ;)

--

Best regards,

Dennis Schetinin

чт, 21 мар. 2019 г. в 23:56, Александр <gen...@live.ru>:

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес sugr+uns...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Dennis Schetinin]

Кстати, а почему Go, а не Erlang (например)?

--

Best regards,

Dennis Schetinin

чт, 21 мар. 2019 г. в 23:56, Александр <gen...@live.ru>:

Переучиваюсь на Go...

--

[Dennis Schetinin]

…и забыл про TaskIt: https://github.com/sbragagnolo/taskit

--

Best regards,

Dennis Schetinin

чт, 21 мар. 2019 г. в 23:56, Александр <gen...@live.ru>:

Переучиваюсь на Go...

--

[Александр]

пятница, 22 марта 2019 г., 10:49:43 UTC+3 пользователь chaetal написал:

Кстати, а почему Go, а не Erlang (например)?

Ну на самом деле это сложный вопрос, не всё от меня и моего желания зависело, компромиссный вариант, в общем можно считать "так получилось"
 
Про concurrency is not parallelism я знаю, просто некорректно термин применил, по началу сложно правильно в этой кухне разобраться  (т.с. эрзац параллелизм).

Собственно хотел бы посмотреть в сторону того смогу ли я чего нибудь из своих фаро-наработок переписать в т.с. многопоточном ключе (если я опять правильно употребляю понятия) или то что нужно уже сразу переписать на Го.

Вот мне например непонятно. Если я запускаю Фаро, то в top я вижу сразу 2 идентичных процесса (видимо по числу ядер процессора).

А что это значит? Это как то можно использовать или это такой чёрный ящик который работает только вод капотом ВМ?
А если не могу использовать, то как вообще работают процессы в рамках образа? Только на одном ядре и фактически последовательно (периодически переключаясь между собой).

И вообще интересно насколько безопасно пытаться делать что то более ли менее сложное в фаро в таком ключе (или возможность есть, но фактически никто не использует)?

(несколько раз образ крашился просто при открытии процесс браузера)  

[Александр]

Ага, что-то сначала  упустил это сообщение.

Про образ и одно ядро теперь понятно

интересно всё же, в последних версиях фаро получается запускается несколько образов по кол-ву ядер, можно ли с этим как  то работать или это кухня ВМ

пятница, 22 марта 2019 г., 10:43:42 UTC+3 пользователь chaetal написал:

[Alexander Kogan]

Здесь наверноеуместно Gemstone  сравнивать. Параллельные виртуальные машины делят общий образ.

[vvm...@gmail.com]

У "типичных" Smalltalk'ов (VAST/VW/Pharo) нити ST-процессов "зелёные", что не помогает утилизации ядер многоядерных процессоров. Поэтому [для утилизации N ядер] выходят из положения, запуская M виртуальных машин (M >= N), одна из которых является координатором других (или некоторые из которых является координатором других). Cincom для этого написала framework под названием Polycephaly. "Зато" у Instantiations есть image components (IC), которые можно грузить в shared memory, т.е., они оказывабтся общими для разных VM и так можно потытаться сэкономить ОЗУ. Координатором/балансиловщиком может служить что-то не smalltalk-чье, наподобие Apache.

С другой стороны, если происходит работа со сложными математическими вычислениями или длительными запросами к базам данных, логично переложить основную работу на кого-то ещё, более подходящего, вызывая функции из DLL и получая готовый или почти готовый результат. Тут может быть очень полезен Multihread FFI. Пока некая зелёная нить ждёт ответа от вызванной функции, в это время может выполняться другая зелёная нить. Так мы можем иметь множество работающих (на разных ядрах одновременно) функций.

В VAST и VW такое есть уже десятки лет. А что с Pharo творится - я даже банально не в силах читать их maillist.

[Александр]

Спасибо
Выглядит сложно, но что-то стало яснее

суббота, 23 марта 2019 г., 12:24:06 UTC+3 пользователь vvm...@gmail.com написал:

[vvm...@gmail.com]

код1

t2 = [ код2 ] fork. "Или forkAt:"

t3 = [ код3 ] fork.

код4.

На зелёных нитях это всё на одном процессорном ядре, т.е. код2 (нить t2), код3 (нить t3) и код4 (ещё какая-то нить) одновременно не выполняются, хотя трудно сказать, какой именно код выполняется. Семафоры используются, чтобы переключаться. К примеру, код2 поработал и встал (ждёт семафора2), запустилась какая-то другая нить, выбранная по каким-то правилам (приоритету и т.п.). Эта другая нить может послать семафору2 сигнал и код2 продолжится (всё остальное не работает).

Ещё мы можем вызвать из код2 что-то внешнее, к примеру, функцию из DLL. Пока мы не получим ответа, ни код2, ни код3, ни код4, код в имидже выполняться не будет (но может выполняться что-то вспомогательное типа сборки мусора - в другой OS-нити). Если это не специальный случай (вроде как у Squeak'а/Pharo TCP/IP асинхронный) и если это если не Threaded FFI.

Когда мы в нити t2 вызвали функцию f2 из dll, используя Threaded FFI, а потом вызвали в той же нити t2 ещё какую-то функцию, оба вызова должны ("незаметно" для программиста на ST) произойти в одной и той же OS-нити, хотя не в основной OS-нити VM. (По крайней мере, базоданновые драйвера это требуют для корректной работы). Нить t2 "подвисает" до получения ответа, но основная OS-нить продолжает работать.

"Полицефалия" добавляет запуск/останов имиджей-рабов из имиджа-хозяина и какой-то механизм передачи сообщений.

По идее, можно даже не заботиться об этом, просто запустить кучу имиджей, а данными обмениваться - даже XML-ками и JSON'ами (это для примера). Или даже можно запустить M одинаковых вебсерверов, назначить им разные порты, а перед ними поставить балансировщик нагрузки.