Здравствуйте, neFormal, Вы писали:

EP>>>>Вообще, что имеется в виду? Какой-нибудь seg-fault?
F>>>да, я про него.
EP>>Это решается компилятором и рантаймом. И проверка адресной арифметики, и контроль разыменования dangling poitners.
F>а можешь ссылок дать, где про это почитать?

Ключевые слова для поиска "pdf C++ bounds checking".

Здравствуйте, BulatZiganshin, Вы писали:

S>>Готовых механизмов для того, чтобы "уснуть" в точке вызова, и "проснуться" в момент прихода события, и при этом не занимать thread, в них нету.

BZ>а boost.coroutine? и вообще проблема не в том что языки плохие, а в том что в такой парадигме банально удобней програмировать. погляди на node.js — там от этой модели избавились, и кому это нужно?

Не сильно понятно что ты хотел сказать про нод. Вроде как растет популярность

Здравствуйте, Ikemefula, Вы писали:

I>Догадываюсь, откуда твоя боль. "однопоточная VM" — это ты скорее всего про Node.js. Ты наверное попутал Node.js с абстрактным джаваскриптом.
I>Node.js как VM никогда, ни разу не был однопоточной VM. И это несмотря на то, что js в ноде однопоточный. Парадокс ? Как то так

А на что еще потоки, кроме js? Ну IO допустим. Два потока. А еще?

Здравствуйте, meadow_meal, Вы писали:

_>>>Мы пишем игровые сервера на Эрланге, приходилось интегрировать bullet3d (порядка 500 динамических миров на сервер, шедулер справляется), box2d, самописные тайловые и воксельные движки, но это 5-10% задач, большая часть времени все равно уходит на игровую логику, так что достоинствами Эрланга наслаждаемся в полный рост.
F>>а что за игрушки?
_>Block n Load
_>Entropy
_>Battlestar Galactica Online
_>и другие

да, прикольно. но 500 запущенных инстов с физикой и прочими динамическими штуками на одном серваке вызывают вопросы, как у вас оно запускается?

Здравствуйте, so5team, Вы писали:

S>Шедулеры ОС прекрасно справляются с этой штукой и труда в доведения шедулеров ОС до state-of-the-art тратиться в разы больше, чем для шедулера Erlang-а.

пока что огромного числа системных тредов я нигде не видел. все пытаются их минимизировать.

S>Это возможно и в случае, если адресация акторов не привязана к конкретным узлам.

ну да.

S>Т.к. Erlang VM вам нужно деплоить на все узлы кластера, точно так же вы можете деплоить хоть нативный код, хоть jar-ы, хоть .NET-овские сборки.

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

F>>что это значит в данном случае? а то я подозреваю, что мы об одном и том же.
S>Это значит, что у актора есть ID/имя, по которому к актору можно обратиться из любого узла вне зависимости от того, где актор в данный момент находится.

значит об одном.

F>>не понимаю пока, чем это может быть полезно. видимо, это для просто параллельных рассчётов, где не важно расположение актора.
F>>а когда хочется размещать это-там-а-это-вон-там, то подобное поведение начинает мешать.
S>Не противоречит ли "хочется размещать это-там-а-это-вон-там" вашему же собственному требованию о прозрачности?

я не говорю об идентичности всех узлов.
наоборот, невозможность управления ролью отдельных узлов вредит.

Здравствуйте, neFormal, Вы писали:

F>пока что огромного числа системных тредов я нигде не видел. все пытаются их минимизировать.

Блин, сколько можно повторять

Автор: so5team
Дата: 05.06.15

?

F>вся логика узлов размещена в коде с настройкой через конфиги.

На каждый узел заливается одинаковый набор исполнимых файлов и библиотек. Далее вся логика узлов размещена в коде с настройкой через конфиги.
ЕМНИП, были специализированные дистрибутивы Linux-а, заточенные под вычислительные задачи, в которых на каждом узле был лишь базовый образ ОС. Когда узел поднимался, он забирал с мастер-узла образ расчетной задачи и запускал ее у себя.

S>>Это значит, что у актора есть ID/имя, по которому к актору можно обратиться из любого узла вне зависимости от того, где актор в данный момент находится.

F>значит об одном.

Это присуще далеко не только Erlang-у. Прозрачность ссылок для распределенной системы -- это очевидный плюс.

F>наоборот, невозможность управления ролью отдельных узлов вредит.

Не доводилось пользоваться Orleans, но даже если у них этого нет, то сделать такую вещь не сложно.

Здравствуйте, so5team, Вы писали:

F>>пока что огромного числа системных тредов я нигде не видел. все пытаются их минимизировать.
S>Блин, сколько можно повторять

Автор: so5team
Дата: 05.06.15

?

ну, приведи доказательства этого "думаю"
можно больше не повторять

F>>вся логика узлов размещена в коде с настройкой через конфиги.
S>На каждый узел заливается одинаковый набор исполнимых файлов и библиотек. Далее вся логика узлов размещена в коде с настройкой через конфиги.
S>ЕМНИП, были специализированные дистрибутивы Linux-а, заточенные под вычислительные задачи, в которых на каждом узле был лишь базовый образ ОС. Когда узел поднимался, он забирал с мастер-узла образ расчетной задачи и запускал ее у себя.

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

S>Это присуще далеко не только Erlang-у. Прозрачность ссылок для распределенной системы -- это очевидный плюс.

да, само собой.

Здравствуйте, neFormal, Вы писали:

S>>Блин, сколько можно повторять

Автор: so5team
Дата: 05.06.15

?

F>ну, приведи доказательства этого "думаю"

Какого именно "думаю"? Того, что: "Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е."?

Так это не "думаю", это объективный медицинский факт. Одна из иллюстраций была приведена уже давно. Это бы Erlang-ерам не мешало бы показать что-нибудь сравнимое с такой тяжести/объемом задачей, в которой и concurrency, и parallel, и distributed...

Здравствуйте, so5team, Вы писали:

S>>>Блин, сколько можно повторять

Автор: so5team
Дата: 05.06.15

?
F>>ну, приведи доказательства этого "думаю"
S>Какого именно "думаю"?

опечатался. имел в виду это:

Полагаю, что 64-х битовые Linux, FreeBSD, Windows. На хорошем железе, да.

S>Это бы Erlang-ерам не мешало бы показать что-нибудь сравнимое с такой тяжести/объемом задачей, в которой и concurrency, и parallel, и distributed...

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

Здравствуйте, neFormal, Вы писали:

F>да, прикольно. но 500 запущенных инстов с физикой и прочими динамическими штуками на одном серваке вызывают вопросы, как у вас оно запускается?

Конкретно в этом случае каждый отдельный Bullet3d dynamic world был эрланг драйвером, апдейт был 10 раз в секунду (по 6 симуляций в апдейте). Сами миры были среднего размера — десятки (до сотни) динамических объектов, ну и некоторое количество статики (до десятков тысяч мешей в некоторых случаях, обычно меньше). Async thread'ы не понадобились. Физика не была узким местом, bullet очень быстрый. Ну и специфика космоса, конечно, до узкой фазы почти не доходит.

Здравствуйте, meadow_meal, Вы писали:

F>>да, прикольно. но 500 запущенных инстов с физикой и прочими динамическими штуками на одном серваке вызывают вопросы, как у вас оно запускается?
_>Конкретно в этом случае каждый отдельный Bullet3d dynamic world был эрланг драйвером, апдейт был 10 раз в секунду (по 6 симуляций в апдейте). Сами миры были среднего размера — десятки (до сотни) динамических объектов, ну и некоторое количество статики (до десятков тысяч мешей в некоторых случаях, обычно меньше). Async thread'ы не понадобились. Физика не была узким местом, bullet очень быстрый. Ну и специфика космоса, конечно, до узкой фазы почти не доходит.

да, космос не так нагружен. я смотрел больше на block'n'load

Здравствуйте, neFormal, Вы писали:

S>>Какого именно "думаю"?

F>опечатался. имел в виду это:
F>

F>Полагаю, что 64-х битовые Linux, FreeBSD, Windows. На хорошем железе, да.

В составе SO5 есть бенчмарк для thread_pool-диспетчеров. Только что запустил его на iCore-7, 2.4GHz, 8Gb RAM, Win 8.1 64-bit.
Со 100K нитями в пуле.
Отработал, пруф. Было съедено где-то 7Gb RAM.
Даже результаты какие-то показал:

bash-3.1$ _vc_12_0_x64/release/_test.bench.so_5.thread_pool_disp.exe -c 100000 -a 2 -m 10 -t 100000

coops: 100000, agents in coop: 2, msg per agent: 10 (at start: 1), total msgs: 2400000

dispatcher: thread_pool

*** demands_at_once: default (4)
*** threads in pool: 100000
*** FIFO: default (cooperation)
creating cooperations: 4.299s
messages: 2400000, total_time: 4.364s
price: 1.818333333e-006s
throughtput: 549954.1705 messages/s
shutdown: 69.051s

Т.е. 100K нитей стартует всего чуть больше, чем за 4s. Останавливается, правда, гораздо медленнее, но это, возможно, из-за индивидуальных join-ов для каждой нити.

Наглядная демонстрация того, что даже 64-бит Windows Home на далеко не серверном железе позволяет запускать 100K нитей. Что уже про Linux-ы/Unix-ы говорить.

S>>Это бы Erlang-ерам не мешало бы показать что-нибудь сравнимое с такой тяжести/объемом задачей, в которой и concurrency, и parallel, и distributed...

F>ещё бы оно дёшево было, то совсем было бы здорово.
F>я ж писал, что нужно добиться паритета по ключевым вопросам, а потом уже можно торговаться по поводу тяжести вычислений, скорости работы и цены разработки.
F>для кого-то будет критична скорость работы, для кого-то цена.

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

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Это понятно, тут со stateless хорошо то что они требуют ровно столько памяти, сколько требуется. Но вопрос-то был про другое.
EP>Тем не менее, я без проблем запускал 400k stackful корутин на ноутбуке

Автор: Evgeny.Panasyuk
Дата: 30.11.13

, причём это далеко не предел.

Я уже читал твои отчеты (познавательно, кста) и не согласен с тем, чтобы уменьшать стек под корутину. Ведь не знаешь же, сколько реально стека потребуется для каких-нить промежуточных вычислений.

Поэтому, stackfull корутин должно быть не много в системе. Если нужны многие-многие тыщщи обработчиков, то, скорее всего, такие обработчики будут "легковесными" в своей логике, в этот сценарий хорошо заходит stackless.

WH>>Лучший в мире генератор парсеров уже есть.
I>Опять "лучший" и уже наверное третий год обещаний "скоро мы сделаем тааакоое !"
Чисто развеять сомнения — сорцы нитры открыты, можешь дать ссылку на хотя-бы аналогичный?

Здравствуйте, Sinclair, Вы писали:

V>>IAX — это порождение Linux, на нем нет IOCP, но есть вот такие трюки. И есть еще целый набор "фиктивных" файлов, типа eventfd, на которых можно организовать похожую схему.
S>Непонятно, что делать с нефиктивными файлами.

epoll
Фишка с ним такова, что на нем тоже можно ожидать многими потоками одновременно и механизм epoll не даст разным потокам одно и то же событие.

S>Напомню, что исходная проблема — ровно в том, что традиционные императивные ЯП ориентированы именно на концепцию "control flow", и весь ввод-вывод предполагается блокирующим.
S>Готовых механизмов для того, чтобы "уснуть" в точке вызова, и "проснуться" в момент прихода события, и при этом не занимать thread, в них нету.

Библиотек корутин для С++ давно больше одной. Самая известная — бустовская, но она не была самой первой.


S>Вот про это я и спрашивал. А про то, как организовать IOCP для веб-сервера, если у нас нету IOCP — это другой вопрос, на мой вкус малоинтересный. Особенно если ответ на него предполагает замену клиентских браузеров на клиентов протокола AIX.

Про это тоже идут споры не один десяток лет. TCP для HTTP — это для 99% сценариев из пушки по воробьям. Давно уже высказывались мысли, что для HTTP больше подойдет message-oriented протокол, но, в отличие от UDP, чтобы гарантировалась доставка.

Здравствуйте, Ikemefula, Вы писали:

I>Опять "лучший" и уже наверное третий год обещаний "скоро мы сделаем тааакоое !"
Генератор парсеров уже сделан. Можно использовать. Но это одна из частей всей найтры.

Здравствуйте, meadow_meal, Вы писали:

_>для 2) — не имеет значения, так как N всегда мало.
Ровно до тех пор, когда их вдруг станет много. Именно это случилось в истории по ссылке.
Пока сообщений было мало, всё работало. Стоило одной из подсистем немного задуматься, как вся система свалилась в кому.

_>Не знаю, есть ли у эрланга фундаментальные проблемы, но selective receive точно не одна из них.
1)Динамическая типизация -> неустранимые тормоза.
2)selective receive -> неустранимые тормоза + отказ в обслуживании в результате кратковременного сбоя.
При том, что ни то ни другое не нужно.

Здравствуйте, so5team, Вы писали:

S>Ну хоть начало доходить, что в зависимости от условий Erlang может быть, а может и не быть подходящим выбором для конкретной задачи.

наконец-то до тебя дошло то, что я писал ещё несколько постов назад

Здравствуйте, neFormal, Вы писали:

S>>Ну хоть начало доходить, что в зависимости от условий Erlang может быть, а может и не быть подходящим выбором для конкретной задачи.

F>наконец-то до тебя дошло то, что я писал ещё несколько постов назад

Тогда зачем был написан вот этот список:

ага, все умеют "свою половину языка Erlang".
так много слов а суть проста. другим технологиям необходимо добиться паритета по следующим пунктам:
1. параллельное выполнение множества задач
2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)
3. единое пространство потоков/процессов на нескольких физических юнитах

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

Здравствуйте, Ikemefula, Вы писали:

S>>>Готовых механизмов для того, чтобы "уснуть" в точке вызова, и "проснуться" в момент прихода события, и при этом не занимать thread, в них нету.

BZ>>а boost.coroutine? и вообще проблема не в том что языки плохие, а в том что в такой парадигме банально удобней програмировать. погляди на node.js — там от этой модели избавились, и кому это нужно?

I>Не сильно понятно что ты хотел сказать про нод. Вроде как растет популярность

что там модель с колбеками и она банальна неудобна по сравнению с зелёными потоками. а популярность растёт постому что альтернатив, т.е. реваоалихация зелёных потоков среди популярных скриптовых языков (js/python) пока что нету