Здравствуйте, Пацак, Вы писали:
П>Интереснее было бы, если бы каждый процесс получал некоторые данные извне (можно эмулировать через ГСЧ для простоты), анализировал их и в зависимости от результата решал, что ему делать дальше: П>- завершиться штатно П>- сдохнуть аварийно П>- запустить N дочерних процессов и опрашивать их при дальнейшем анализе П>- притормозить на время и известить об этом родителя П>- грохнуть принудительно всех детей П>- и т.п.
П>Я ж так понимаю Мамут в своих спичах делает упор на легкость именно управления процессами, а не тупо их создания в количестве "дофига штук". А легкость управления лучше всего проверяется его многообразием.
Фокус в том, что реализации actor model для других языков уже предоставляют готовые инструменты для этого (в Akka и C++ Actor Framework чуть ли не 1-в-1 слизано из Erlang-а, в SObjectizer чуть-чуть иначе, собственно, вот пример). Только это не является частью языка, а сделано в виде библиотек. Потому и игнорируется Mamut-ом.
Re[35]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, so5team, Вы писали:
S>Фокус в том, что реализации actor model для других языков уже предоставляют готовые инструменты для этого (в Akka и C++ Actor Framework чуть ли не 1-в-1 слизано из Erlang-а, в SObjectizer чуть-чуть иначе, собственно, вот пример). Только это не является частью языка, а сделано в виде библиотек. Потому и игнорируется Mamut-ом.
Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга) и утверждает, что на специализированном языке то же самое можно сделать проще и красивее. Сам я, как человек далекий от сложных распределенных вычислений, в этом совершенно не копенгаген, но интуиция мне подсказывает, что лучше всего такие вещи обсуждать на примерах. Ну а раз уж в плане утверждений Мамута никто за язык не тянул — то и примеры, получается, тоже с него.
Ку...
Re[36]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Пацак, Вы писали:
П>Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга) и утверждает, что на специализированном языке то же самое можно сделать проще и красивее.
Так кто ж спорит с тем, что если язык заточен под конкретную задачу, то эта задача будет воплощена на этом языке с минимальными усилиями?
Проблема в том, что есть языки общего назначения, которые предназначены для более широкого круга задач. И как раз в силу своей универсальности они и не тянут в себя всего, а позволяют сторонним разработчикам делать недостающие инструменты в виде библиотек. Как показывает практика, работает это весьма неплохо.
Особую пикантность спору придает то, что Erlang довольно специфичен и если выйти за рамки комфортной для него ниши, например, пробовать сделать на Erlang-е тяжелый расчет, в котором используются расшаренные между несколькими потоками данные, то окажется, что это сделать не так то и просто. Даже потому, что в Erlang-е нет такого понятия, как массив с прямым доступом по индексу. Не говоря уже про расшаренные (да еще и не дай Бог) мутабельные данные. Т.е. пока на Erlang-е делаешь то, для чего он предназначен, то все хорошо. Но шаг влево, шаг вправо и все. Тогда как другие языки, которые противопоставляются Erlang-у, позволяют двигаться в более широких пределах. И как раз из-за необходимости двигаться в более широких пределах в этих языках (особенно если речь идет об императивных, вроде Java и C#, и уж тем более об императивных и нативых, вроде C++/Eiffel/Ada) нельзя внедрить модель конкурентности из Erlang-а на уровне стандарта языка.
Об этом Mamut-у неоднократно намекали с разной степенью прозрачности. Но все как горохом об стенку.
Re[33]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд.
встраивай VM, как JS, и вперёд.
скорей всего придётся сделать свою VM, т.к. дефолтную под это использовать будет странно.
странно предлагать энларг для таких вещей. это же фреймворк, по сути.
да, его можно использовать для широкого круга задач из бэкенда, но использовать его, как язык общего назначения, глупо.
by design, как говорится.
...coding for chaos...
Re[36]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Пацак, Вы писали:
П>Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга)
вообще этого не было. по крайней мере в отношении akka в этом треде.
ну и akka уже странновато называть отдельной библиотекой. в скалке оно давно заменило старую реализацию акторов. по крайней мере в той версии, которую(другую) запустил Одерски(забыл название).
реализация же этого на чём-то ещё — да, является половиной эрланга. может для кого-то это и плохо. но моя точка зрения, что было бы неплохо это иметь на какой-то иной технологии. пусть даже это JVM.
на нативных языках это невозможно без поддержки ядра. потому что нужны метрики для рассчёта затрат процессора(а эрланг это делает ровно так же, как и питон: через подсчёт действий интерпретатора), чтобы можно было балансить шедулером(системным али нет) лёгкие потоки. с поддержкой этого в ядре проблема нивелируется.
когда это станет возможным в системе, то остальное можно будет реализовать уже любыми доступными средствами.
хотя, единственной недоступной, как мне кажется, фичой останется заливка кода в рантайме. потому что без VM нельзя заменить какой-то модуль другим вариантом. но если это возможно, то тоже нет никаких проблем с реализацией этой фичи(ну, если архитектуры не отличаются).
в эрланговских приложениях горячие апдейты тоже редко используются(есть разные проблемы с обновлением состояния), но это активно используется в отладке и иногда в продавшоне.
...coding for chaos...
Re[8]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Философ, Вы писали:
Ф>не учтя при этом, что свойство из другого потока может быть изменено, и всё — привет отладка логированием. Ф>Ясен пень, что этот пример взят с потолка, но суть проблемы он в принципе демонстрирует.
по ходу срача я так понял, что предлагается такого просто не делать
как и баги вообще.
...coding for chaos...
Re[37]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>на нативных языках это невозможно без поддержки ядра. потому что нужны метрики для рассчёта затрат процессора(а эрланг это делает ровно так же, как и питон: через подсчёт действий интерпретатора), чтобы можно было балансить шедулером(системным али нет) лёгкие потоки. с поддержкой этого в ядре проблема нивелируется.
1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду.
2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
Re[32]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали: M>Угу. Сферовакуумный оферхед из твоих фантазий. mmkay.
Аргументированно. ))) M>Там решение строго на основе единообразных инструментов, если что. А не в виде «расширения к языку с равным уровнем поддержки в разных компиляторах».
Ну да, только оно не работает. ) M>Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
Десяток потоков — это что конкретно? ) Вот скажем если мы возьмём десктопные или мобильные приложения (по задачам многопоточности они не особо отличаются), то там обычно требуется что-то вроде главного потока (в котором весь GUI), переодически запускающего несколько фоновых. Так такие вещи реализуются вообще абсолютно тривиально, т.к. у нас есть в языке поддержка системных потоков, а вместе с GUI библиотекой автоматом получаем готовую очередь у главного потока. В итоге даже не надо ставить какие-то крутые библиотеки, а можно просто писать так:
Скрытый текст
class MyWindow: public Window{
Button start_button, stop_button;
Editbox adress;
Textbox output;
public:
MyWindow()
{
start_button.Connect(ClickEvent, [&]{//Connect - функция из GUI библиотеки
start_button.Enable(false);
thread([&, url=adress.text()]{//thread - класс из стандартной библиотеки C++try{
auto cancel=Cancel();
PostMessage(ThreadEvent, MakeMessage(Message::Start, cancel));//PostMessage - функция из GUI библиотекиauto data=DownloadFile(url, cancel);//наша длительная блокирующая фоновая операция
PostMessage(ThreadEvent, MakeMessage(Message::End, data));
}catch(exception& e){
PostMessage(ThreadEvent, MakeMessage(Message::Error, e));
}
}).detach();
});
Connect(ThreadEvent, [&](auto message){
switch(message.id){
case Message::Start:
stop_button.Connect(ClickEvent, [&, cancel=message.Get<Cancel>()]{
stop_button.Enable(false);
cancel();
});
stop_button.Enable();
break;
case Message::End:
output<<message.Get<string>();
start_button.Enable();
stop_button.Enable(false);
break;
case Message::Error:
MessageBox("Error", message.Get<exception>().what());
start_button.Enable();
stop_button.Enable(false);
}
});
}
};
Причём это ещё считай пример на голом C++, т.е. без подключения крутых библиотек многопоточности и без линеаризации кода через сопрограммы. С этим всем код ещё сократился бы раз в два при той же функциональности. ) Ну так и какие проблемы ты видишь здесь? ) M>/o\ Просто без комментариев. У него, видите ли, претензия к функции, про котороую сразу написано, что она гипотетическая.
ОК, мы уже поняли, что решения на Эрланге предложенной мною простейшей задачки на многопоточность не существует. _>>Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? ) M>Нет.
Хм, тогда поясни подробнее свою точку зрения. От претензии на универсальное решение в многопоточности ты вроде как уже отказался. Но при этом и нишевость не признаешь. Тогда что? )
Re[34]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
I>>Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд.
F>встраивай VM, как JS, и вперёд. F>скорей всего придётся сделать свою VM, т.к. дефолтную под это использовать будет странно.
Предполагалось что ответ будет давать Мамут
Re[38]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
Целевая область будет меняться в зависимости от того, как хорошо ты сможешь шедулить. На ЯП общего назначения типичный код может и не делать никаких библиотечных вызовов долгое время.
Кроме того, в таких языках пока не ясно, чем обеспечить гарантии, что глобальное состояние юзается корректно.
Re[38]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду.
и получается ситуация наоборот. т.е. совсем не то.
EP>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
это зависит от того, насколько ты считаешь себя умней шедулера.
да и как по yield'ам ты будешь оценивать затраты времени?
...coding for chaos...
Re[39]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>и получается ситуация наоборот. т.е. совсем не то.
Что значит наоборот, и почему не то?
EP>>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)? F>это зависит от того, насколько ты считаешь себя умней шедулера.
В каком смысле?
Во всех примерах что я видел на Erlang — расстояние между библиотечными вызовами минимальное — получили сообщение, на его основе выбрали следующее действие, создали и отправили новое сообщение, либо сделали какой-то вызов. Если такой сценарий не типичный для реального кода, то хотелось бы увидеть код с типичным сценарием.
F>да и как по yield'ам ты будешь оценивать затраты времени?
Например через какой-нибудь performance counter или cycle counter.
Re[39]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, в таких языках пока не ясно, чем обеспечить гарантии, что глобальное состояние юзается корректно.
1. Инструкцией программистам "глобальное состояние не менять".
2. Проверять наличие глобального состояния через символы в объектных файлах, и выдавать ошибку при наличии оного.
3. Верификатор кода запрещающий часть языковых конструкций, например на базе Clang AST Matcher.
4. Опциональная защита страниц (а-ля PAGE_NOACCESS) не относящихся к текущему процессу.
5. Генерация компилятором соответствующих проверок, либо маскирование любого доступа к памяти (то есть вместо *p будет что-то типа current_process_memory[index_p & 0x400], либо исползование индексов ограниченной разрядности).
Re[40]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>>и получается ситуация наоборот. т.е. совсем не то. EP>Что значит наоборот, и почему не то?
афаик в эрланге шедулер останавливает потоки, а не потоки решают, когда им отдать управление.
потому что управлять очередью инструкций к интерпретатору легко.
в питоне, кстати, тоже передача управления между тредами определяется количеством инструкций. я уже писал об этом где-то выше.
EP>>>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)? F>>это зависит от того, насколько ты считаешь себя умней шедулера. EP>В каком смысле?
если ты изнутри кода отдаёшь управление, то ты берёшь работу шедулера на себя.
можно этого не делать.
EP>Во всех примерах что я видел на Erlang — расстояние между библиотечными вызовами минимальное — получили сообщение, на его основе выбрали следующее действие, создали и отправили новое сообщение, либо сделали какой-то вызов. Если такой сценарий не типичный для реального кода, то хотелось бы увидеть код с типичным сценарием.
затрудняюсь назвать типичный сценарий, т.к. у меня местами большие блоки кода.
F>>да и как по yield'ам ты будешь оценивать затраты времени? EP>Например через какой-нибудь performance counter или cycle counter.
yield'ы же у тебя изнутри кода дёргаются.
а тебе надо снаружи хоть по тем же счётчиками (кстати, что за cycle counter? откуда он?) прервать выполнение. чтобы поток не смог зависнуть.
это если мы говорим о более-менее здоровой реализации, а не о соглашениях на проекте.
...coding for chaos...
Re[41]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>>>и получается ситуация наоборот. т.е. совсем не то. EP>>Что значит наоборот, и почему не то? F>афаик в эрланге шедулер останавливает потоки, а не потоки решают, когда им отдать управление. F>потому что управлять очередью инструкций к интерпретатору легко.
А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции.
F>>>да и как по yield'ам ты будешь оценивать затраты времени? EP>>Например через какой-нибудь performance counter или cycle counter. F>yield'ы же у тебя изнутри кода дёргаются. F>а тебе надо снаружи хоть по тем же счётчиками прервать выполнение. чтобы поток не смог зависнуть.
Если именно нужно прерывать по счётчикам — то смотри пункт 1. Другой вариант — отдельный watchdog поток.
F>(кстати, что за cycle counter? откуда он?)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>потому что управлять очередью инструкций к интерпретатору легко. EP>А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции.
да, если только с помощью генерёжки где-то на уровне инструкций процессору.
теперь осталось реализовать тот самый soft-realtime(т.е. прерывание ожидания ответа по таймеру) и своя половина эрланга с менее удобным, но более быстрым языком у нас готова.
F>>(кстати, что за cycle counter? откуда он?) EP>https://en.wikipedia.org/wiki/Time_Stamp_Counter
о_О никогда б не догадался.
...coding for chaos...
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>C++ AMP — это же не кроссплатформенно. EP>>Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL. _>Спецификации — это дело десятое.
Вообще, поинт в том, что C++ AMP style намного ближе к идиомам C++ нежели OpenACC, независимо от того взлетит или нет.
_>Нужна именно реализация. MS вряд ли создаст реализацию под другие платформы. А другие тем более не будут.
AMD and Microsoft jointly released C++ AMP version 1.2 compiler that supports Linux alongside Windows.
EP>>Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки. _>Ну это как с SIMD в данный момент. Автовекторизация вполне себе работает, но руками можно сделать заметно быстрее.
Да, но в случае с GPGPU проблема строго сложнее, причём на порядки:
* данные нужно передавать между CPU RAM <-> GPU RAM — эта передача может перечеркнуть весь выигрыш.
* Множество потоков разбито на блоки, которые в свою очередь разбиты на под-блоки simd'ы (warp'ы). На каждом из уровней свои ограничения и особенности, правильно используя которые можно получать приличное ускорение (либо огромные просадки, если неправильно).
* Есть несколько видов явной памяти, каждая из которых опять-таки имеет свои ограничения и особенности.
Re[43]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>>>потому что управлять очередью инструкций к интерпретатору легко. EP>>А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции. F>да, если только с помощью генерёжки где-то на уровне инструкций процессору.
Да, об этом и речь.
F>и своя половина эрланга с менее удобным
Насколько я вижу, основное удобство в Erlang это Pattern Matching (в C++ PM по типам реализуется легко, так как уже встроено в компилятор, а вот PM по выражениям/значениям — да, сложнее и не удобно).
А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее.
Re[44]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее.
имея опыт в программировании от stl до хаскела, скажу что чем высокоуровневей язык, тем удобней и надёжней программирование, особенно в многопоточной среде кстати. при описании сложных алгоритмов обработки данных stl всё ещё втрое уступает хаскелу по объёму кода (довелось недавно один модуль переписать..)
Люди, я люблю вас! Будьте бдительны!!!
Re[45]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
EP>>А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее. BZ>имея опыт в программировании от stl до хаскела, скажу что чем высокоуровневей язык, тем удобней и надёжней программирование,
чистота != высокий уровень
императивность != низкий уровень
BZ>особенно в многопоточной среде кстати.
Какая разница мутируем ли мы локальные переменные функций?
BZ>при описании сложных алгоритмов обработки данных stl всё ещё втрое уступает хаскелу по объёму кода (довелось недавно один модуль переписать..)
