n0name2,
LCR>>Короче, как выразился Влад, "тест из разряда "физики шутят"". Что с той, что с другой стороны.
N>Тест говорит о том, что мифическое приемущество Erlang в concurrent программировании по сравнению с Java объясняется скорее тем, что Erlangисты не понимают как задачу решить оптимально средствами Java, а не тем, что есть некие фундаментальные ограничения у самой JVM.
N>Проводились ли вообще вменяемые сравнения или ничего поинтереснее адепты Erlang предложить немогут? Скорость создания потоков мне не интересна — обычно массово их не создают а обходятся пулами.
Надо сказать, что скорость создания и уничтожения процессов — это очень важная характеристика, потому что _такое_ количество процессов держать в пуле — самоубийство. И вся идеология в Эрланге построена вокруг этого — агрессивное программирование, supervision hierarchy и "параллельно-ориентированное программирование" (COP, одна параллельная сущность мира отображается 1-в-1 на процесс).
Так что интересно? Одновременное количество работающих процессов? Пиковая нагрузка? Или время отклика на приоритетное сообщение при максимальной нагрузке?
Довольно давно Ulf Wiger делал тест на Спарке — кольцо из 20 миллионов процессов (6 миллионов без хибернейта) и пускал сообщение по кольцу. Время создания процесса было прорядка 6 микросекунд, время посылки сообщения было что-то тоже порядка 6 микросекунд. (Где-то полгода назад мы обсуждали скалистые акторы и там были все ссылки, да и ты тоже учавствовал).
Я ссылаюсь на этот стресс-тест исключительно для того, чтобы не ввязываться в бессмысленные замеры, имхо в таких задачах очевидно, что java не конкурент ни разу.
(Другое дело, что когда мы пишем документооборот для фирмы на 50 человек, то эрланг будет явный оверкилл — гораздо важнее наличие библиотек, тут уже перевес на стороне java.)
Здравствуйте, n0name2, Вы писали:
N>Не, как раз Apache заводит отдельный процесс на каждого клиента.
Apache стартует N процессов в каждом по M потоков. В конфиге всё настраивается.
N>Вообще, приличный Java web server рвет Apache как тузик грелку. А для большого кол-во requestов есть NIO (non blocking IO), в одном потоке можно обрабатывать сколько хочешь клиентов
На практике non blocking, а по нашенски overlapped не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п.
N>здесь
Да, интересно конечно...
N>Воспроизвести тест как на твоей ссылки конечно мало реально, но, известно что NIO based серверы практически не деградируют при большом кол-ве клиентов.
Ээээ... я ссылки не давал. Я вообще про YAWS напомнил, только в рамках наезда шо Ырланговцы показывают какие-то примеры "физики шутят". А насчёт известно — то мне неизвестно. Нужно разбираться, а пока кроме усложнения я ничего не вижу.
Здравствуйте, Курилка, Вы писали:
К>Реализовать ты сможешь, только SRT гарантировать будет по меньшей мере очень сложно.
В Элраге нет никаких гарантий. Да и надбность в большинстве задач сомнительна.
И вообще, о каких реалтайм-гаратниях можно говорить под Виндовс или Линукс? Это не реалтайм-ОС. Они даже илюзорные софт-реалтайм-гарантии дать не могут. Ведь в Винде без проблем может запуститься высокоприортитетный поток на неопределенное время. И привет лунатикам (с).
К>Как реализовать гранулируемость до чего нибудь уровня редукций — очень хороший вопрос. Возможно это можно сделать на Немерле путём работы с АСТ. К>Плюс ещё надо реализовать достаточно эффективный шедулер.
На Немерле без вопросов можно повтыкать проверки в разные места. Но конечно с библиотечными фцнкциями это не поможет. Вот только тоже самое будет и с Эрлэнгом. Он ведь все равно для чтения файла или доступа к сети будет вызвать внешний код. А это значит, что гаратнировать уже 100% ничего нельзя.
В общем, решение работающее для многих жизненных случаев сделать можно. А идеал и на Эрлэнге не достижим. Идеальное решение можно сделать только в рамках управляемой ОС. Такой как Сингулярити. Вот там все по честному. Там тебе и чествный шедулер способный самостоятельно распределять нагрузку по процессорам и отнимать управление у работающего процесса. Там тебе полный котроль GC. И какава с чаем (с).
К>Кстати на Скала сейчас они уже сделали пересылку сообщений между JVM, только вот ресив там постоянно сидит в цикле и поллит результаты, т.е. 100% загрузку ЦПУ получаем. Надо будет написать авторам, какие у них планы по развитию этого детища
Думаю, что все это эксперементы сильно оторванные от жизни. Чтобы получить что-то действительно жизненное надо иметь реальную задачу и насщную необходимость ее решать красивыми методами. Вот у Эриксона такая задача бала. А у создателей Скалы — нет.
ЗЫ
Кстати, подумалось, что для большинства задач реального мира было бы достаточно исползовать и потоки ОС. Все же найти задачу где действительно потребовлось бы запускать 100 и более параллельных потоков (не спящих) не так то просто. А на сотнях потоков все и так будет работать на ура. Учитывая же, что эти потоки скорее всего и так загрузят процессор по самое нехочу можно сказать, что решение будет более чем жизныенным и востребованным.
По крайней мере решилась бы проблема прозрачного возаимодействия потоков с минимумом (а в идеале отсуствием) блокировок. Это уже не мало.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Как минимум в эрланге нет циклов, поэтому если не выполнять функции (что приведёт к вызову др. редукций), то единственный способ сделать задержку это написать кучу присваиваний каких-нибудь, но даже в этом случае у тебя будет конечное время (и хз какой у тебя должен быть бимфайл чтобы полчаса получилось).
Ты будешь смеяться, но в Немерле тоже нет циклов. Это ничего не значит. Концевая рекурсия в ФЯ всегда оптимизирвется и преобразуется в цикл. Иначе ФЯ будет вываливаться по переполеннию стека.
Задержки же возможны по куда более прозоическим соображениям. Ведь любая программа (в том числе Эрлэнговая) вызвается в неуправляемой ОС. И любое обращение к функциям ОС может привести к томозам. Я уже не говорю об активизации высокоприоритетных потоков (в других процессах ОС, например). Тут вообще ничего не поделаешь. Так что гарантии эти очень иллюзорны.
К>В императивном же байткоде тебе сделать беск. цикл можно вполне просто, в этом и возникает проблемка.
Это какая-то фигня. Нет тут никакой разницы. У тебя вно нездоровое отношение к функциональщине. Что там, что там будут инструкции. Натыкав проверок в нужных местах ты получишь достаточную гранулярность перехвата. Проблема будет только с библиотеками и кодом СО. Но эта проблема будет и в Эрлэнге.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А кто-то проводил реальные эксперементы эффективности? Есть доставерная информация о том, что Эрлэнговый ЖЦ дествительно эффективнее дотнетного? Ведь кроме псевда-раелтайм-гарантий еще важна эффективность. И не фатк, что алгоритм с поколениями плюс джит-компиляция не окажется эффктивнее. Лично у меня большое подозрение, что окажется и сильно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Одна сборка мусора при иммутабельности реально уже офигенно выигрывает.
Есть реальные данные? Что на счет проигрыша за счет интерпретации? Не факт, что ЖЦ может скоменсировать эти тормоза. Обычно ЖЦ не так и много времени отедает. А вот код выполняется все время.
К> Просто речь о том выигрыш от такого подхода при обычном императивном программинге довольно мал, вот это и показали green threads
Где показали?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
E>>"Одна задача -- один процесс" -- гораздо более простая модель для разработки. E>>Тем более, что убивать почившие процессы в такой модели гораздо проще, чем потоки в пуле.
N>Чем принципиально отличается следующие два куска кода с т.з. простоты:
<skipped/>
N>Другое дело если им нужно активно взаимодействовать — тут нужно уже смотреть задачу конкретную.
Вопрос заключается в том, что создание потока требует накл. расходов, также как и переключение между активными потоками, в отличие модели эрланга, где самым критичным (я думаю) может быть передача больших объёмов данных путём пересылки сообщний.
N>Non blocking IO — да, это чуть сложнее, согласен. Хотя, над ним уже построили высокоуровневые абстракции и ничего особенно сложного там нет. Да и в типовом проекте это вообще не нужно. Кстати, простота программирования в императивном vs функциональном стиле это отдельная тема, конечно и тут все не столь очевидно.
Ммм, есть функция, результат её не зависит от чего-либо кроме входных параметров, что тут неочеведного?
Правда побочные эффекты сказываются (файлы, сетевой трафик), только вот это всё дело можно изолировать, собственно логику (суть решамемой задачи) отдельно рассматривать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Cyberax, Вы писали:
VD>А кто-то проводил реальные эксперементы эффективности? Есть доставерная информация о том, что Эрлэнговый ЖЦ дествительно эффективнее дотнетного? Ведь кроме псевда-раелтайм-гарантий еще важна эффективность. И не фатк, что алгоритм с поколениями плюс джит-компиляция не окажется эффктивнее. Лично у меня большое подозрение, что окажется и сильно.
Здравствуйте, VladD2, Вы писали:
К>>Реализовать ты сможешь, только SRT гарантировать будет по меньшей мере очень сложно.
VD>В Элраге нет никаких гарантий. Да и надбность в большинстве задач сомнительна.
Создатели языка пишут, что есть, Влад пишет, что нет. Интересно кто прав?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Ты перепутал, эт ко второму относится. Мутабельность на самом распараллеливании напрямую не сказывается, вроде как
VD>Кстати, а Эрлэнг таки позволяет изменять данные (делать побочные эффекты)? Вроде как тут все в один голос твердили, что он не чистый ФЯ.
Что значит "изменять данные"? Переменные неизменяемы (single assignment). Но функции могут иметь побочные эффекты (e.g. файловая система, сет. трафик, та же посылка сообщений), монад вроде как не наблюдается, чтобы "бороться" с этим делом
Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
There are some original design decisions that make retrofitting a
static type system difficult. Two of the big ones are dynamic code
loading and the message passing, but there are most likely lots
of small snags where functions would have been designed with
different semantics (and different type signatures!) if dynamic
typing weren't available. This is of course partly the "much work"
argument again, but the combination of dynamic typing and advanced
pattern matching is a core characteristic of Erlang, which, for one
thing, leads people to happily write code that would require a PhD
on type systems to even compile in e.g. ML or Haskell. Many would
argue that this is not necessarily a good thing — that static typing
enforces a type discipline that is ultimately good for you.
The truth of that possibly varies depending on problem domain.
Anyway, since we have both Concurrent ML and Concurrent Haskell,
I don't see that making Erlang statically typed is a high priority.
Concurrent ML was designed at roughly the same time as Erlang.
While Erlang's main requirement was to support programming of
robust telecoms systems, a main challenge with Concurrent ML was
to add concurrency in a way that didn't break the type system.
This lead to some fundamentally different design decisions, as
I understand it.
Существую некоторые исходные архитектурные решения, которые делают
добавление стат. системы типов трудным. Два наибольших — динамическая
загрузка кода и пересылка сообщений, но возможно существует много
маленьких "моментиков" где функции имели бы другую
семантику (и другие сигнатуры типов!) если не было бы
динамической типизации. Это, конечно, от части опятьже аргумент по поводу
объёма работ, но комбинация динамической типизации и расширенного
паттерн-матчинга является неотъемлимой характеристикой Эрланга, которая, с
одно стороны, позволяет людям писать код, который бы потребовал PhD
для компиляции в системах типов (напр. как в ML или Haskell). Многи бы
поспорили, что это не обязательно хорошая особенность и, что статическая типизация
порождает "дисциплину типов", что очень полезно.
Правда, наверное, зависит от области применения.
В любом случае, т.к. существуюи Concurrent ML и Concurrent Haskell,
я не думаю, что введение статической типизации в Эрланге имеет высокий приоритет.
Concurrent ML был создан примерно в то же время как и Erlang.
В то время как основым требованием к Erlang была поддержка программирования
устойчивых систем в телекоме, главной задачей Concurrent ML было
добавление параллелизма таким образом, чтобы это не "сломало" систему типов.
Это привело к фундаментально другим архитектурным решениям,
насколько я понимаю.
ANS>Это хак. вообще 1 тред (кстати с какими параметрами ты это запускал?). И выполнить вообще всё последовательно. Ты получиш еще больше количество сообщений в сек.
ANS>Я не понял. Используется одна общая очередь на все треды? Это баг.
Это не хак, я этим хочу показать что задачу мы выполнили (передали 1млн мессэджей от одного потока другому). Каким способом это делается — создается много потоков или два это неважно. Просто в Erlang это эффективней решить созданием потоков, а в Java пулом. Тот хак в C#, о котором ты говоришь, приводит к тому, что исходная задача вообще не решается. Если ты настаиваешь на том, что исходная задача это создание 1млн потоков, то потрудись объяснить зачем это нужно.
ANS>ЗЫ. Тест на Erlang, скорее всего, тоже туфта
Здравствуйте, n0name2, Вы писали:
ANS>>Это хак. вообще 1 тред (кстати с какими параметрами ты это запускал?). И выполнить вообще всё последовательно. Ты получиш еще больше количество сообщений в сек.
ANS>>Я не понял. Используется одна общая очередь на все треды? Это баг.
Что на счет одной очереди? Или я что-то не досмотрел?
N>Это не хак, я этим хочу показать что задачу мы выполнили (передали 1млн мессэджей от одного потока другому). Каким способом это делается — создается много потоков или два это неважно.
Я так понимаю, задача — обеспечить максимально конкурентный приём сообщений, а не максимальную пропускную способность (которая будет при схеме "один тред всё время отправляет, потом он всё время принимает"). Отображает ли это исходный тест на Erlang — я не готов сейчас сказать.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Надо сказать, что скорость создания и уничтожения процессов — это очень важная характеристика, потому что _такое_ количество процессов держать в пуле — самоубийство. И вся идеология в Эрланге построена вокруг этого — агрессивное программирование, supervision hierarchy и "параллельно-ориентированное программирование" (COP, одна параллельная сущность мира отображается 1-в-1 на процесс).
Зачем держать большое кол-во потоков в пуле? Оно должно быть просто достаточно для того, чтобы загрузить системные ресурсы. Для начала можно взять кол-во потоков равное кол-ву CPU. Просто у нас будет длинная (несколько миллионов вхождений) очередь заданий для каждого потока. Чем это принципиально отличается? Какие именно практические задачи нельзя решить с помощью маленького пула потоков и длинной очереди?
LCR>Так что интересно? Одновременное количество работающих процессов? Пиковая нагрузка? Или время отклика на приоритетное сообщение при максимальной нагрузке?
Интересно кол-во запросов, которое может быть обработано в секунду. Т.е. throughput. Под запросом я понимаю — рендеринг web страницы или например в терминах телекома запрос на инициализацию звонка.
LCR>Довольно давно Ulf Wiger делал тест на Спарке — кольцо из 20 миллионов процессов (6 миллионов без хибернейта) и пускал сообщение по кольцу. Время создания процесса было прорядка 6 микросекунд, время посылки сообщения было что-то тоже порядка 6 микросекунд. (Где-то полгода назад мы обсуждали скалистые акторы и там были все ссылки, да и ты тоже учавствовал).
Проблема в тех скалИстых алгоритмах в том, что они пытаются подстроится под модель Erlang. В терминах Java можно решить эту задачу как поставить в очередь 20млн задач и поочередно их выполнить (с помощью пула из 2-4 потоков) передавая результат выполнения одной задачи на вход другой. Таким образом мы бы решили туже бизнес задачу гораздо быстрее на Java чем на Erlang (т.е я уверен что можно достичь скорости выполнения одной задачи быстрее чем 6мксек).
LCR>Я ссылаюсь на этот стресс-тест исключительно для того, чтобы не ввязываться в бессмысленные замеры, имхо в таких задачах очевидно, что java не конкурент ни разу.
Пока ни одной не искуственно выдуманной задачи я не видел. Тем более такой, что не решается эффективно с помощью рула и non blocking IO.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Допустим у тебя 32 проца. Соответсвенно тред пул у тебя на 32 треда. Тебе не кажется это несколько... ограниченным?
А в чем проблема? Зачем тебе больше потоков чем процессоров? Единственная причина по которой это нужно — если потоки блокируются на вводе/выводе. Это решается с помощью NIO.
Здравствуйте, fddima, Вы писали:
F> На практике non blocking, а по нашенски overlapped не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п.
Это только потому, что библиотек нет на .NET нормальных, которые предоставляют несколько более высокий уровень чем raw selectors. На Java есть таже Apache Mina, которая делает все это совершенно тривиальным. Кроме того, по большей части, это вообще скрыто от юзера т.к. этим всем занимается web сервер.
F> Ээээ... я ссылки не давал. Я вообще про YAWS напомнил, только в рамках наезда шо Ырланговцы показывают какие-то примеры "физики шутят". А насчёт известно — то мне неизвестно. Нужно разбираться, а пока кроме усложнения я ничего не вижу.
Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.
Здравствуйте, Курилка, Вы писали:
К>Вопрос заключается в том, что создание потока требует накл. расходов, также как и переключение между активными потоками, в отличие модели эрланга, где самым критичным (я думаю) может быть передача больших объёмов данных путём пересылки сообщний.
Я говорю о том, что если использовать пулы потоков, то никаких накладных расходов нет. Ни на переключение м/у активными потоками, ни на создание нового. Есть поток, он обрабатывает входную очереди и все. Единственные расходы — это передача данных м/у потоками и засыпание/просыпание потока (когда некоторое время очередь пуста), но, это оч незначительно.
Накладные расходы в Erlang на переключение наверняка есть. Все-таки там есть stack.
Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д.
Здравствуйте, n0name2, Вы писали:
N>Накладные расходы в Erlang на переключение наверняка есть. Все-таки там есть stack.
Где его нет? И расходы на переключение везде есть...
N>Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д.
Наверняка? Я бы не стал утверждать что в Erlang и/или Java где-то, что-то хуже проработано. Всё таки для этого нужно изучать внутренности и первого и второго.
).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п. 
