Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
E>>>Ну, пытаемся потихоньку. И пример Одерски с передачей токенов был сделан и пропускная способность была замерена. Пока на C++, а со временем на что-нибудь управляемое, со сборкой мусора переползем.
К>>Т.е. это практически один в один Скаловский вариант? Сообщения передаются в рамках одного процесса ОС? К>>Куда заглянуть, чтобы посмотреть исходники механизма "посылальщика"?
E>Вот код этого примера. Остальные тесты производительности в дистрибутиве.
E>Уж не знаю, насколько это точно соответствует Scala, поскольку мы его написали практически сразу как ты дал ссылку на работу Одерски. Но, вроде как похоже
Т.е. на мой вопрос ты не можешь ответить? Между разными процессами можно посылать мессаги?
А по тексту...
Нужно ковырять, читаемость не особая
PI>шото типа этого
Валяюсь При всем уважении к Немерлу, удивляюсь, как может человеку больше нравиться запустить Студию, набрать и отдебажить код, скомпилить, запустить, найти ошибку, опять скомпилить, опять запустить и радоваться жизни вместо того, чтобы в консоли набрать "grep pattern file | wc -l" и тоже радоваться жизни.. Хотя оно то да, в винде консоль послабже буит..
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Т.е. на мой вопрос ты не можешь ответить? Между разными процессами можно посылать мессаги?
E>См., например, здесь
Т.е. практически получается, что нужно самому программисту заботиться о транспортном уровне (хотя, конечно, большая часть кода в библиотеке), о каналах и т.п.? В то время, когда в эрланге нужно знать только pid процесса и имя ноды, куда можно послать всё, что заблагорассудится.
И все сообщения должны быть описаны (с помощью соотв. макросов)?
Оверхед конечно заметный, но это уже интересно
Правда боюсь из-за плюсов реально использовать руки не дойдут.
Здравствуйте, Курилка, Вы писали:
К>Т.е. практически получается, что нужно самому программисту заботиться о транспортном уровне (хотя, конечно, большая часть кода в библиотеке), о каналах и т.п.? В то время, когда в эрланге нужно знать только pid процесса и имя ноды, куда можно послать всё, что заблагорассудится.
Я не знаю Erlang-а, но ведь pid и имя ноды -- это же не IP-адреса хостов. О том, чтобы передать эту информацию в приложение приходится заботится программисту, или не так?
В SObjectizer определять транспортные каналы можно как создавая транспортных агентов вручную (для мелких утилит это обычное дело), так и просто подгружая через конфигурационные файлы нужные DLL и регистрируя таким же образом нужные кооперации агентов (подробнее описано в So4 Frameworks, глава 6). Вообще, уже давно все наши большие SObjectizer приложения собираются из DLL как из конструктора и вручную создавать транспортные агенты нет необходимости.
К>И все сообщения должны быть описаны (с помощью соотв. макросов)?
Да.
Из-за того, что в плюсах нет run-time reflection другого способа передать SObjectizer информацию о сообщения и их структуре нет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Курилка, Вы писали:
К>>Т.е. практически получается, что нужно самому программисту заботиться о транспортном уровне (хотя, конечно, большая часть кода в библиотеке), о каналах и т.п.? В то время, когда в эрланге нужно знать только pid процесса и имя ноды, куда можно послать всё, что заблагорассудится.
E>Я не знаю Erlang-а, но ведь pid и имя ноды -- это же не IP-адреса хостов. О том, чтобы передать эту информацию в приложение приходится заботится программисту, или не так?
Вообще это совсем не IP-адрес
И программист не может передавать сам информацию в приложение. Есть глобально зарегистрированные процессы, к ним можно обратиться по имени. Для более хитрых вещей получается сценарийй типа: делаем запрос к менеджеру процессов, он отвечает, куда надо слать, мы шлём уже по этому адресу, где-то примерно так.
И по поводу адресов: в рамках одной машины (одного IP) может быть запущено сколько угодно нод.
E>В SObjectizer определять транспортные каналы можно как создавая транспортных агентов вручную (для мелких утилит это обычное дело), так и просто подгружая через конфигурационные файлы нужные DLL и регистрируя таким же образом нужные кооперации агентов (подробнее описано в So4 Frameworks, глава 6). Вообще, уже давно все наши большие SObjectizer приложения собираются из DLL как из конструктора и вручную создавать транспортные агенты нет необходимости.
Т.е. получается почти статическая схема агентов?
Ничего похожего на супервайзоров нету?
Чтобы перестартовать "умерший" процесс? Под тем же именем? Хотя да, имён же нет, ну с тем же прослушиваемым каналом?
К>>И все сообщения должны быть описаны (с помощью соотв. макросов)?
E>Да. E>Из-за того, что в плюсах нет run-time reflection другого способа передать SObjectizer информацию о сообщения и их структуре нет.
Ну понятно, что-то типа сериализации получается, логично.
Здравствуйте, Курилка, Вы писали:
E>>В SObjectizer определять транспортные каналы можно как создавая транспортных агентов вручную (для мелких утилит это обычное дело), так и просто подгружая через конфигурационные файлы нужные DLL и регистрируя таким же образом нужные кооперации агентов (подробнее описано в So4 Frameworks, глава 6). Вообще, уже давно все наши большие SObjectizer приложения собираются из DLL как из конструктора и вручную создавать транспортные агенты нет необходимости. К>Т.е. получается почти статическая схема агентов?
Можно и так сказать.
Вообще опыт использования SObjectizer показал, что большое количество агентов на каждый чих -- это слишком большой геморрой при разработке. Ведь в SObjectizer у агентов есть состояния и, если сообщение не обрабатывается в текущем состоянии, то оно теряется. В Erlang-е, как я помню, если сообщение в данный момент процессу не интересно, то оно остается в очереди до лучших времен.
Так что оказалось, что лучше, когда в приложении есть несколько агентов, которые выполняют работу обычным образом (т.е. в виде простого объектно-ориентированного или процедурного подхода), но между собой обмениваются асинхронными сообщениями. Реально, в самых больших задачах у нас крутится не больше тысячи агентов.
А вот состав агентов можно менять во время работы процесса динамически.
Но горячей замены кода, как в Erlang, естественно, нет -- C++ опять же. Хотя можно DLL-ки выгружать и загружать опять, но не всегда это получается сделать. Особенно, если изменения в DLL-ках серьезные и внешние связи затрагиваются.
К>Ничего похожего на супервайзоров нету?
Пока нет. Но мы работаем над этим
К>Чтобы перестартовать "умерший" процесс? Под тем же именем? Хотя да, имён же нет, ну с тем же прослушиваемым каналом?
Процесс -- это обычный процесс системы. При надобности он убивается обычным kill-ом или из Task Manager.
Если запускать процессы из-под специальных менеджеров, то эти менеджеры их сами при необходимости рестартуют.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Понять то я, например, пойму, но сходу не напишу. Но это мелочь. Ибо, мне думается, что в твоей программе функциональный баг. Который вылезет если им посчитать кол-во строк в 10ти гиговом файле. Короче, шелу — скриптинг, шарпу — шарпинг
Ну, как раз функционально тут все в порядке. Баг в производительности, которая является нефункциональным требованием. Это, естественно, связано с не вполне удачной реализацией регекспов в шарпе. В свою очередь, это связано с тем, что достаточно удобная поддержка ленивых списков (на основе которых можно делать конвееры, аналогичные | в шелле) внедрена только 1 год назад. Вот как выглядит более корректный код на C# 2.0:
...
int matches=0;
Regex r = new Regex(pattern, RegexOptions.Compiled);
foreach(string line in GetLines(fileName))
matches += r.Matches(line).Count;
Console.WriteLine(matches);
}
private static IEnumerable<string> GetLines(string fileName)
{
using(TextReader tr = File.OpenText(fileName))
while(tr.Peek()>=0)
yield return tr.ReadLine();
}
В третьем шарпе это можно записать еще компактнее благодаря екстеншн методам, но я не рискну здесь привести код, т.к. тройку знаю скорее теоретически.
Реализовать полностью корректный код можно только изменив RegEx: сейчас он умеет принимать только строку, а не IEnumerable<char>.
Поэтому предложенная реализация благополучно сдохнет на 10 гигах без переносов. В отличие, смею полагать, от grep.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали: S>Ну, как раз функционально тут все в порядке. Баг в производительности, которая является нефункциональным требованием.
Хе-хе. Посмотрел на твой код ниже. И таки не всё в порядке. Считать нужно не кол-во совпадений, а кол-во строк. Мой вывод: нормальный программист должен взять готовый инструмент, а не день отлаживать свой велосипед
S>[c#] S> foreach(string line in GetLines(fileName)) S> matches += r.Matches(line).Count; S> Console.WriteLine(matches); S>}
PI>>шото типа этого G>Валяюсь При всем уважении к Немерлу, удивляюсь, как может человеку
ещё надо человеков, которые на нём работают уважать (меня например) G>больше нравиться запустить Студию,
всегда открыто пару штук G> набрать
в консоли как будто не надо набирать G> и отдебажить код, скомпилить,
интеграция в текущем варианте компилит на лету, выделяя ошибки с задержкой 0.5 сек
можно писать много кода, не компиля G> запустить, найти ошибку,
ты сам понимаешь, что ошибка может быть только паттерне — в консоли достаточно сложный регексп ты тоже вряд ли сразу правильно наберешь G> опять скомпилить,
"опять написать команду в консоли" G> опять запустить
к тому же ты в косоли ошибешься 20 раз с лишними кавычками и т.п. G> и радоваться жизни вместо того, чтобы в консоли набрать "grep pattern file | wc -l" и тоже радоваться жизни..
представители олдскула — я посмеиваюсь в усы с вас... G> Хотя оно то да, в винде консоль послабже буит..
не знаешь — не говори
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>>Понять то я, например, пойму, но сходу не напишу. Но это мелочь. Ибо, мне думается, что в твоей программе функциональный баг. Который вылезет если им посчитать кол-во строк в 10ти гиговом файле. Короче, шелу — скриптинг, шарпу — шарпинг S>Ну, как раз функционально тут все в порядке. Баг в производительности, которая является нефункциональным требованием. S> Это, естественно, связано с не вполне удачной реализацией регекспов в шарпе. В свою очередь, это связано с тем, что достаточно удобная поддержка ленивых списков (на основе которых можно делать конвееры, аналогичные | в шелле) внедрена только 1 год назад. Вот как выглядит более корректный код на C# 2.0:
<велосипед поскипан> S>Реализовать полностью корректный код можно только изменив RegEx: сейчас он умеет принимать только строку, а не IEnumerable<char>. S>Поэтому предложенная реализация благополучно сдохнет на 10 гигах без переносов. В отличие, смею полагать, от grep.
А давайте-ка посчитаем теперь количество слов. Да еще и не в одном файле, а в нескольких.
[** vvv]$ grep "NetVa" * -h
// Это вивод всех строк в файлах *, которые совпадают с паттерном NetVa. -h отключает вывод имени файла перед строкой совпадения.
NetVampire Job: "05. chiasm - isolated.mp3"
NetVampire Job: "aerial - pound.mp3"
NetVampire Job: "asp hole.mp3"
NetVampire Job: "asp_hole.mp3"
NetVampire Job: "automobile.mp3"
NetVampire Job: "chinatown_theme.mp3"
NetVampire Job: "creepy_ambience_combat.mp3"
NetVampire Job: "crypts.mp3"
NetVampire Job: "crypts_combat.mp3"
NetVampire Job: "dangerous_places_combat.mp3"
NetVampire Job: "daniel ash - come alive.mp3"
NetVampire Job: "dark_asia_combat.mp3"
NetVampire Job: "darling violetta - a smaller god.mp3"
NetVampire Job: "default_combat.mp3"
NetVampire Job: "disturbed_and_twisted.mp3"
NetVampire Job: "disturbed_twisted_combat.mp3"
NetVampire Job: "downtown_theme.mp3"
NetVampire Job: "gargoylemusic.mp3"
NetVampire Job: "genitorturers - lecher bitch.mp3"
NetVampire Job: "glaze.mp3"
NetVampire Job: "hollywood_theme.mp3"
NetVampire Job: "lacuna coil - swamped.mp3"
NetVampire Job: "mid_short cutscene stem10.mp3"
NetVampire Job: "ministry - bloodlines.mp3"
NetVampire Job: "mission_impossible.mp3"
NetVampire Job: "mission_impossible_combat.mp3"
NetVampire Job: "moldy_old_world.mp3"
NetVampire Job: "police_alert.mp3"
NetVampire Job: "radio_loop_5.mp3"
NetVampire Job: "santa monica main bg.mp3"
NetVampire Job: "santa_monica_theme2.mp3"
NetVampire Job: "vampire extra music stem5.mp3"
NetVampire Job: "vampire_theme.mp3"
[** vvv]$ grep "NetVa" * -h | wc -w
// флаг -w говорит, что нужно считать количество слов
130
ANS>Хе-хе. Посмотрел на твой код ниже. И таки не всё в порядке. Считать нужно не кол-во совпадений, а кол-во строк. Мой вывод: нормальный программист должен взять готовый инструмент, а не день отлаживать свой велосипед
Здравствуйте, PhantomIvan, Вы писали:
G>>Валяюсь При всем уважении к Немерлу, удивляюсь, как может человеку PI>ещё надо человеков, которые на нём работают уважать (меня например)
Ну я, по моему, неуважения не высказывал... Если показалось — извини. G>>больше нравиться запустить Студию, PI>всегда открыто пару штук G>> набрать PI>в консоли как будто не надо набирать
Размер сравни G>> и отдебажить код, скомпилить, PI>интеграция в текущем варианте компилит на лету, выделяя ошибки с задержкой 0.5 сек PI>можно писать много кода, не компиля G>> запустить, найти ошибку, PI>ты сам понимаешь, что ошибка может быть только паттерне — в консоли достаточно сложный регексп ты тоже вряд ли сразу правильно наберешь
Почему же только в паттерне? В алгоритме банально может быть.. G>> опять скомпилить, PI>"опять написать команду в консоли" G>> опять запустить PI>к тому же ты в косоли ошибешься 20 раз с лишними кавычками и т.п.
Ну 20 раз точно перебор Разве что запускать перловую программу через perl -e . А так — раза достаточно, чтобы вспомнить, что кавычки забылю G>> и радоваться жизни вместо того, чтобы в консоли набрать "grep pattern file | wc -l" и тоже радоваться жизни.. PI>представители олдскула — я посмеиваюсь в усы с вас...
Ну при чем тут олдскул? Я универ закончил год назад, но все же мне очевидно, что набрать с второй-третей попытки в консоли надлежащий конвеер, чтобы получить результат, попроще чем с той же второй-третьей попытки написать программу из минимум нескольких строчек.. G>> Хотя оно то да, в винде консоль послабже буит.. PI>не знаешь — не говори
Да, не знаю, спасибо. Моим оправданием может быть лишь то, что в 2К(которая у меня дома) в дистрибутив не входит консоль подобной мощи, а в Линь — пожалуйста... Однако это совсем другой флэйм
Если уж на то пошло — консоль как раз для таких задач и предназначена и в этих задачах покруче будет, чем серебряная пуля.. Давайте еще вместо Сиквела немерловый код писать... Нет, я понимаю, что никто не вставляет SQL-запросы прямо в код.. Но все-же хоть иногда скармливаете базе SQL? А теперь представьте себе вместо него Немерле...
Здравствуйте, PhantomIvan, Вы писали:
ANS>>Хе-хе. Посмотрел на твой код ниже. И таки не всё в порядке. Считать нужно не кол-во совпадений, а кол-во строк. Мой вывод: нормальный программист должен взять готовый инструмент, а не день отлаживать свой велосипед
PI>это
PI>>в консоли как будто не надо набирать G>Размер сравни
чуть больше, ну и что?
в правильного программиста всегда таких сниппетов — склад, и ещё маленькая тележка впридачу
PI>>ты сам понимаешь, что ошибка может быть только паттерне — в консоли достаточно сложный регексп ты тоже вряд ли сразу правильно наберешь G>Почему же только в паттерне? В алгоритме банально может быть..
тут алгоритмом, мягко говоря, и не пахнет
PI>>к тому же ты в косоли ошибешься 20 раз с лишними кавычками и т.п. G>Ну 20 раз точно перебор Разве что запускать перловую программу через perl -e . А так — раза достаточно, чтобы вспомнить, что кавычки забылю
в непростых регекспах невозможно не ошибаться
G>>> и радоваться жизни вместо того, чтобы в консоли набрать "grep pattern file | wc -l" и тоже радоваться жизни.. PI>>представители олдскула — я посмеиваюсь в усы с вас... G>Ну при чем тут олдскул? Я универ закончил год назад,
скул и возраст не коррелируют, а в универе ньюскулу по определению не учат
G> но все же мне очевидно, что набрать с второй-третей попытки в консоли надлежащий конвеер, чтобы получить результат, попроще чем с той же второй-третьей попытки написать программу из минимум нескольких строчек..
сниппеты переиспользуются
где и как ты сохраняешь свои консольные команды?
G>>> Хотя оно то да, в винде консоль послабже буит.. PI>>не знаешь — не говори G>Да, не знаю, спасибо. Моим оправданием может быть лишь то, что в 2К(которая у меня дома) в дистрибутив не входит консоль подобной мощи, а в Линь — пожалуйста... Однако это совсем другой флэйм
ничего, это зарелижено недавно, и знают об этом только виндовские спецы
но заметь, я ничего в сторону юникса не говорил
G>Если уж на то пошло — консоль как раз для таких задач и предназначена и в этих задачах покруче будет, чем серебряная пуля.. Давайте еще вместо Сиквела немерловый код писать... Нет, я понимаю, что никто не вставляет SQL-запросы прямо в код.. Но все-же хоть иногда скармливаете базе SQL? А теперь представьте себе вместо него Немерле... бугага
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Контрольный вопрос: она таки подсчитывает колличество совпадающих строк или колличество вхождений паттерна в строку?
Если имелассь в виду исходная комманда "grep pattern file | wc -l", то она подсчитывает количество совпавших строк. Насколько я смог понять, программа PhantomIvan делает то же самое
написано за 2 минуты
ANS>Контрольный вопрос: она таки подсчитывает колличество совпадающих строк или колличество вхождений паттерна в строку?
количество совпадающих строк
но это всё неважно, важно что шелловики могут не замечать, что сливают в дискуссии,
а техника "скриптов" на основе немерле всё равно будет более прогрессивной
При всем уважении к Немерлу, удивляюсь, как может человеку больше нравиться запустить Студию, набрать и отдебажить код, скомпилить, запустить, найти ошибку, опять скомпилить, опять запустить и радоваться жизни вместо того, чтобы в консоли набрать "grep pattern file | wc -l" и тоже радоваться жизни.. Хотя оно то да, в винде консоль послабже буит..
1.2.0 alpha rev. 655
