... или почему имплементация Erlang style concurrency под обычные VM очень проблематична (“очень проблематична” – это потому что я ненавижу слово “невозможно”). Я собираюсь довольно сильно углубиться в детали (в конце концов, внимание к деталям – это то что отличает профи от любителя )
1. Хотя даже сами эрланговцы шутят, что soft real time – это “basically nothing”, тем не менее разница между soft real-time и отсутствием вообще каких-либо гарантий существенна. (Для сложных систем обеспечить SRT довольно трудно, и существуют ли вообще сложные системы с HRT я не знаю).
A hard realtime system is one which can guarantee that a certain action will always be carried out in less than a certain time. Many simple embedded systems can make hard realtime guarantees, e.g. it is possible to guarantee that a particular interrupt service routine on a Z80 CPU will never take more than 34us. It gets progressively harder to make such guarantees for more complex systems.
Many telecomms systems have less strict requirements, for instance they might require a statistical guarantee along the lines of "a database lookup takes less than 20ms in 97% of cases". Soft realtime systems, such as Erlang, let you make that sort of guarantee...
Language features which make it hard(er) for programmers to roughly estimate performance were never added to Erlang. For instance, Erlang doesn't have lazy evaluation.
--
Система с жёстким временем это такая, что опеределённое действие будет всегда завершаться в определённый промежуток времени. Множество простых встроенных систем могуть допускать жёсткие временные ограничения, например возможно гарантировать, что прерывание на CPU Z80 никогда не превысит больше 34 микросекунды. И с ростом сложности систем дать подобные гарантии всё тяжелее и тяжелее.
Много телекоммуникационный систем имеют более мягкие ограничения, например, они могут требовать статистическую гарантию скажем "поиск в базе данных требует меньше 20 милисекунд в 97% случаев". Платформы с мягким временем, такие как Эрланг, позволяют вам давать гарантии подобного рода...
В Эрланг никогда не добавлялись фичи, которые бы усложняли оценку времени выполнения. Например, в Эрланге нет ленивых вычислений.
--
(http://www.erlang.org/faq/x1138.html)
Кроме того, для задач телекома важно, чтобы и время отклика было очень мало (речь идёт о милисекундах). Здесь “soft” означает, “мы не можем _абсолютно_ гарантировать всё, но мы проектировали платформу с самого начала так, чтобы можно было _практически_ гарантировать достаточно быстрый отклик”. Это гораздо больше того, что может сказать здесь, скажем, Ява (и это неудивительно, поскольку Ява проектировалась так, чтобы сказать кое-что в другом месте).
То есть этим абзацем я хочу сказать, что SRT отнюдь не пустой звук и фатально влияет на весь дизайн системы как в малом масштабе (например, отсутствие деструктивного изменения туплов), так и в большом (например, отсутствие встроенных ленивых вычислений). И это требование может (и будет) конфликтовать с существующими платформами (куда требование SRT не закладывалось).
2. Первый отпечаток – это решение о том, как распределяется время среди процессов. Наприме, в есть аналогичные легковесные процессы в Питоне (stackless microthreads, Candygram), в Яве (Scala actors) и в Лиспе (Distel). В сущности, что такое параллельная программа на лёгких процессах? Грубо говоря, это большой однопоточный while (или хвостово-рекурсивный эквивалент):
while (true)
{
int n = decide();
work_in_process(n);
}
Функции, которые пишет программер, при компиляции будут порезаны на мелкие кусочки переходами на внешний уровень, так что поток управления неявно размазывается по функциям work_in_process(n). Очевидно, что пока work_in_process(n) не отработает, передать управление в work_in_process(n+1) мы не можем. Теперь предположим, что программер пишет
xml_tree = xml.parse();
Внимание вопрос: как выдрать управление из функции parse и передать в work_in_process(n+1)? Если эта функция из фреймворка? Если эта функция из third-party библиотеки? Скала и Питон разводят руками. Distel – потенциально опасные функции помечаются специальным соглашением о наименовании. То же самое придётся делать с функциями, вызывающими эти, функциями второго, третьего и т.п. уровня. Такая операция замыкания на множестве функций вырежет добрую половину (если не больше) всех доступных библиотек и функций.
Файберы не решают этой проблемы, потому что внедрить переход к другому файберу в функцию parse технически трудноосуществимо. Либо похожий (скорее фантастический) вариант – послайсить тяжёлые функции по результатам предварительного прогона – то есть внедрить в их код команды возврата к шедулеру. Однако, во-первых, технически я не представляю как это сделать. Во-вторых, нужно где-то хранить контекст, чтобы потом можно было продолжить выполнение. В-третьих, у этого подхода есть жёсткие ограничения по масштабируемости. В-четвёртых, этот подход плохо подстраивается под меняющиеся условия – если какой-то участок
Остаётся одно – выдрать управление с помощью потоков ОС. Получается, от чего ушли к тому пришли.
По мне так не очень весело, а больше способов я лично не вижу.
Ситуация с Concurrent Haskell и E лучше, но там, насколько мне известно, тоже нельзя дать никаких гарантий даже в предположении идеальной операционки. Единственный конкурент – Oz (как утверждают его авторы). Однако строго говоря там другая модель параллельности ну и опять же – свой рантайм.
Эрланг – это функциональный язык реализованный на основе редукций. В то время как скажем в питоновских микропотоках или скалистых акторах квант времени определяется на основе количества выполненых инструкций байт-кода, в Эрланге квант определяется на основе количества редукций. Разница принципиальная: выполнение одной инструкции байткода может длиться от времени выполнения нескольких машинных инструкций до времени перехода Солнца из стадии жёлтого карлика в стадию красного гиганта. В то же время одна редукция выполняется _всегда_ быстро (верхняя граница существует и весьма мала; кстати поэтому в гвардах можно делать только жёстко ограниченный набор операций).
Это означает что эрланговский процесс (в противовес вышеперечисленным) не может оккупировать процессор на долгое время. Вдобавок, шедулер имеет и обеспечивает необходимую точность: _практически гарантируется_, что процесс получит управление во временном окне X (где X зависит от многих факторов, но для целевых приложений его хватает с запасом). Любой математик/программист может вывести все необходимые вероятностные оценки на время отклика и испытать их практически. Естественно, нужно учитывать вносимые флуктуации железом и операционкой. Если с практической точки зрения, нас волнует доступность сервиса, то следует учесть, что доступность и ограничения на время сильно коррелируют. Возьмите правильное железо, и правильную операционку, и при должном подходе к делу вы тоже получите девять девяток доступности, как в случае мегасвитча AXD-301.
3. “Selective receive” это три маленьких пункта:
1. Если очередь пуста, процесс блокируется.
2. Все сообщения в мэйлбоксе “паттерн-матчатся”, соответствующее сообщение удаляется из мэйлбокса и запускается обработка сообщения, которая может длиться сколь угодно долго.
3. Все сообщения в мэйлбоксе сортируются по категориям так, что наиболее приоритетные сообщения берутся первыми.
“Selective receive” имеет преимущества по сравнению с FIFO:
If one may receive input from multiple, uncoordinated senders, there is no way to predict the order in which the inputs will arrive. So you either explicitly handle all permutations, or find a way to reorder messages where applicable. This is essentially what the selective receive does...
This radically reduces the number of combinations we are forced to write code for.
--
Если процесс получает на вход сообщения от нескольких хаотических отправителей, невозможно предсказать порядок получения сообщений. Поэтому вы либо явно обрабатываете все перестановки, или находите способ перестроить сообщения для обработки. Это в сущности то, что делает selective receive...
Это значительно уменьшает количество комбинаций, для которых мы должны написать код.
--
(Ulf Wiger, http://www.erlang.org/ml-archive/erlang-questions/200606/msg00213.html)
Однако требуются значительные усилия, чтобы реализовать его эффективно. А именно, (1) как только в мэйлбокс некоторого приоритетного процесса приходит сообщения, он (процесс) должен мгновенно получить управление (прямой доступ к шедулеру), (2) чтобы разбить сообщения на категории, нужно в худшем случае сканировать весь мэйлбокс, следовательно сканирование может занять большое время, (3) в силу специфики приложений receive запросто может стать узким местом, (4) реализация receive требует некоторой возни с массивами, в частности in-place resize, а для этого нужно взаимодействие с gc.
Считаю, что этих четырёх пунктов должно быть достаточно для того, чтобы реализовать receive на уровне виртуальной машины, а не на уровне байткода.
(Подробнее про семантику selective receive читаем мегасообщение от Richard’а O’Keefe)
4. GC в Эрланге – это произведение искусства. Ну ладно, просто классный:
Armstrong and Virding have proposed a one-pass mark-and-sweep garbage collector. The collector is designed for languages that prohibit destructive operations (i.e. values can not be overwritten), and is used in a Erlang implementation. Since destructive operations are not allowed, references can only refer to older objects. The collector marks the objects from the youngest to the oldest. If no other object has referred to an object that is being marked, it can be reclaimed immediately (since only younger objects can refer to it.) All objects are kept in a singly linked list to keep the objects in order. All GC operations have predictable runtime behavior. Thus, it can be used for real-time systems if it is scheduled to guarantee memory availability.
--
Армстронг и Вирдинг предложили однопроходной mark-and-sweep сборщик мусора. Сборщик спроектирован для языков, которые запрещают деструктивные операции (то есть значения не могут быть перезаписаны), и используется в реализации Эрланга. Поскольку деструктивные операции недопустимы, ссылки могут лишь указывать на более старые объекты. Сборщик помечает объекты начиная с самых новых и заканчивая самыми старыми. Если нет других объектов, ссылающихся на помеченный, этот объект может быть немедленно освобождён (поскольку только более новые объекты могуть на него ссылаться). Все объекты завязаны в список и образуют порядок. Все операци сборщика имеют предсказуемое время работы. Таким образом, такой сборщик может быть использован для систем реального времени чтобы гарантировать выделение памяти, если есть гарантия того, что сборщик получит управление.
--
([AV95] Joe Armstrong and Robert Virding. One-pass real-time generational mark-sweep garbage collection.)
То есть мало того, что он быстрый (один проход по списку – вот и вся сборка мусора), так ещё имеет предсказуемое время работы.
По этой теме можно также взглянуть сюда (ссыла от Cyberax )
Это ещё не всё. Чтобы увеличить независимость процессов, каждый процесс обслуживается сборщиком отдельно, то есть имеет собственную кучу. Преимущество – можно просто выбросить все данные для процесса, когда этот процесс мрёт. Расшаривание одной большой кучи может привести к более частым сборкам мусора, что нежелательно.
GC должен одинаково хорошо работать как в случае частых перезапусков процессов, так и в случае множества долгоживущих многососущих и многовыплёвывающих процессов.
В то же время, можно сделать так, что если какому-то критическому процессу не будет хватать памяти, то ему будет выделена память за счёт бездействующих процессов.
Наконец, в последнее время появилась “гибридная” модель с расшаренной кучей, где локальная посылка сообщений проходит вообще без какого-либо копирования (см. erl -hybrid) и с сохранением SRT. Это вообще принципиально э... очень проблематично без взаимодействия с gc.
5. Я конечно ляпнул про “интеллектуальность” шедулера. На самом деле он просто удовлетворяет ряду условий:
- scheduling is preemptive.
— a process is suspended if it enters a receive statement, and there is no matching message in the message queue.
— if a receive timer expires, the process is rescheduled.
---
— многозадачность вытесняющая.
— процесс останавливается всякий раз, когда он доходит до receive, и в очереди нет подходящих под паттерны сообщений.
— если время таймера (условие after в операторе receive) истекает, процесс будет перепланирован для того, чтобы первым получить time-slice.
---
(Ulf Wiger, http://www.erlang.org/ml-archive/erlang-questions/200104/msg00072.html)
Обратите внимание на первый и третий пункты. Чтобы обеспечить эти пункты, нужно иметь возможность шедулеру в любой момент получить управление (вот он SRT). И для совсем тяжёлых случаев у нас есть
In a runtime environment that supports it, it should be possible to also have erlang processes at interrupt priority (meaning that they will be allowed to run as soon as there is something for them to do — not having to wait until a 'normal' priority process finishes its timeslice.)
--
В окружении, поддерживающем прерывания, также заложена возможность иметь процессы с приоритетом "interrupt" (что означает, что они должны получить управление как только будет что-то им для выполнения — то есть нет необходимости ждать, пока процесс с нормальным приоритетом доработает до конца своего time-slice'а).
--
(Ulf Wiger, http://www.erlang.org/ml-archive/erlang-questions/200104/msg00072.html , конец сообщения)
То есть здесь конечно рулит не сам шедулер как таковой, а то что он тесно склеен с рантаймом и поэтому обеспечивает такие возможности.
Ну я надеюсь, я достаточно подробно пояснил, почему я считаю, что Эрланг невозможен под jvm/.net? Хочу правильно поставить акцент: я не отрицаю возможность lightweight библиотеки, я всего лишь навсего очень-очень сильно сомневаюсь, что она может составить конкуренцию Эрлангу на _его_ поле боя и на смежных площадях:
Telephone systems have to handle 95% of maximum supported load while being attacked with 100 times that load.
Erlang is designed for telephone systems by the biggest supplier of telephone systems in the world. It works.
--
Системы телефонии должны работать при нагрузке 95% от максимально возможной при этом выдерживать пиковую нагрузку превышающую максимальную в 100 раз. Эрланг был создан для систем телефонии самым большим поставщиком таких систем в мире. И он работает.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ну я надеюсь, я достаточно подробно пояснил, почему я считаю, что Эрланг невозможен под jvm/.net?
Т.е. фактически две причины:
— реализация вытесняющего, а не корпоративного распаралеливание как (как я понял), например, в Скала,
— однопроходный GC, с предсказуемым временем работы.
Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Т.е. фактически две причины:
IT>- реализация вытесняющего, а не корпоративного распаралеливание как (как я понял), например, в Скала,
Это можно сделать только в ОС. Эрлэнг тоже это не делает.
IT>- однопроходный GC, с предсказуемым временем работы.
Это требование для систем реального веремени. К тому же для Явы уже есть РВ-GC.
IT>Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
Ни первое, ни второе не нужно для большинства бизнес-задач коих большинство.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Ну я надеюсь, я достаточно подробно пояснил, почему я считаю, что Эрланг невозможен под jvm/.net?
IT>Т.е. фактически две причины:
IT>- реализация вытесняющего, а не корпоративного распаралеливание как (как я понял), например, в Скала, IT>- однопроходный GC, с предсказуемым временем работы.
IT>Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
Реализовать ты сможешь, только SRT гарантировать будет по меньшей мере очень сложно. На той же Скале я напишу в коде актора бесконечный цикл и он "съест" поток.
Как реализовать гранулируемость до чего нибудь уровня редукций — очень хороший вопрос. Возможно это можно сделать на Немерле путём работы с АСТ.
Плюс ещё надо реализовать достаточно эффективный шедулер.
Кстати на Скала сейчас они уже сделали пересылку сообщений между JVM, только вот ресив там постоянно сидит в цикле и поллит результаты, т.е. 100% загрузку ЦПУ получаем. Надо будет написать авторам, какие у них планы по развитию этого детища
IT,
IT>Т.е. фактически две причины:
IT>- реализация вытесняющего, а не корпоративного распаралеливание как (как я понял), например, в Скала, IT>- однопроходный GC, с предсказуемым временем работы.
IT>Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
Если мы говорим о любительской реализации, где мы готовы забить на эффективность и все библиотеки (будем пользоваться только нашими спец-функциями), то
0. Ничего не мешает.
(За прототип можно взять Distel — программа преобразуется с помощью макросов к CPS и на каждом таймслайсе выполняется несколько сотен редукций).
Если мы говорим о промышленной реализации, то причин чуть больше. Для промышленной реализации нам нужны следующие вещи:
1. Библиотеки.
2. Возможность ставить временные ограничения.
3. Критические примитивы, реализованные на уровне ВМ.
4. Тесное взаимодействие с gc.
Если мы говорим о достаточно хорошей реализации, которой будут все пользоваться, и которая победит потоки, то нам нужны только
1. Библиотеки
(но ты подожди радоваться, может я ещё чего вспомню )
И строго говоря, в последнем случае нам необязательно ориентироваться именно на модель Эрланга. Мы можем выбрать любую на вкус:
(Various kinds of) locks and monitors
STM's
Pi-calculus and CCS
CSP, Occam
Asychronous Pi-calculus, Pict
Join calculus, functional nets, JoCaml, polyphonic C#.
Concurrent logic programming, Oz
Actors, Erlang
CML synchronous events
Ada rendezvous
--
Martin Odersky "Tackling Concurrency — Language or Library?"
О, смотри! Мы можем выбрать первый пункт и вообще ничего не делать!
IT wrote: > Т.е. фактически две причины:
Их больше
> — реализация вытесняющего, а не корпоративного распаралеливание как (как > я понял), например, в Скала,
Корпоративное распараллеливание — это когда директор говорит 100
подчиненным что-нибудь сделать.
Есть кооперативное распараллеливание. В Скале не совсем оно, как
я понял.
> — однопроходный GC, с предсказуемым временем работы. > Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
Мутабельность переменных.
Здравствуйте, Cyberax, Вы писали:
C>IT wrote: >> — однопроходный GC, с предсказуемым временем работы. >> Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR? C>Мутабельность переменных.
Ты перепутал, эт ко второму относится. Мутабельность на самом распараллеливании напрямую не сказывается, вроде как
Курилка wrote: >> > — однопроходный GC, с предсказуемым временем работы. >> > Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR? > C>Мутабельность переменных. > Ты перепутал, эт ко второму относится. Мутабельность на самом > распараллеливании напрямую не сказывается, вроде как
Я про однопроходность GC говорил.
Здравствуйте, Курилка, Вы писали:
IT>>Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
К>Реализовать ты сможешь, только SRT гарантировать будет по меньшей мере очень сложно. На той же Скале я напишу в коде актора бесконечный цикл и он "съест" поток.
Это не должно быть проблемой. Компилятор может вставить в твой цикл код, который будет передавать управление шедулеру и никто ничего не съест. Проблема будет в случае вызова кода, который не контролируется компилятором. Проблема, типичная для кооперативной многозадачности.
К>Как реализовать гранулируемость до чего нибудь уровня редукций — очень хороший вопрос. Возможно это можно сделать на Немерле путём работы с АСТ.
АСТ тут не причём. Вытесняющая многозадачность возможна только насильственным путём, когда у рабочего потока никто ничего не спрашивает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
C>Есть кооперативное распараллеливание. В Скале не совсем оно, как C>я понял.
О! Точно, коперативное. Я уже и забыл как это называется.
>> — однопроходный GC, с предсказуемым временем работы. >> Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR? C>Мутабельность переменных.
А это тут каким боком? Мутабельность уже учтена в GC.
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: >> > — однопроходный GC, с предсказуемым временем работы. >> > Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR? > C>Мутабельность переменных. > А это тут каким боком? Мутабельность уже учтена в GC.
Про упрощение generational GC я уже писал, теперь напишу про трехцветный
GC
Предположим, что у нас есть граф объектов. Изначально все узлы графа
покрашены в белый цвет.
Для сборки мусора мы идем с корней и красим встреченные белые узлы в
серый цвет. При этом мутатор может работать параллельно — в граф просто
добавляются новые белые узлы (возможно, меняя цвет узла в который
добавляется новая дуга).
Затем самое интересное — если у серого узла все ссылки указывают на
серые или черные узлы, то сам узел тоже раскрашивается в черный цвет.
Как только в графе не остается серых узлов — то это значит, что мы нашли
все достижимые объекты, а все что не раскрашено — это мусор.
У этого алгоритма получается "tri-color invariant" — черные узлы не
могут указывать напрямую на белые узлы. Кстати, это база почти всех
инкрементальных алгоритмов GC.
Теперь, если у нас все переменные иммутабельны, то GC сильно упрощается
— уже помеченные черным узлы не могут поменять свой цвет! Смена цвета
происходит в том случае, если к уже существующему объекты добавляется
новая ссылка, но объекты у нас иммутабельны.
Таким образом, мы можем вместо двух проходов (покраска в серый цвет, а
потом в черный) оставить только один (покраска в черный цвет).
Теоретически, этот алгоритм можно добавить в GC для CLR/JVM — но он
будет работать только на кластерах иммутабельных объектов. А выделение
таких кластеров (без хинтов GC) — сама по себе непростая задача
Здравствуйте, VladD2, Вы писали:
IT>>- реализация вытесняющего, а не корпоративного распаралеливание как (как я понял), например, в Скала,
VD>Это можно сделать только в ОС. Эрлэнг тоже это не делает.
Э... блин, запутали вы меня. Вытесняющая — это приоритеты. Это конечно можно сделать где угодно. Я имел в виду реальный параллилизм. В общем, не о том подумал. Сори.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>>> > — однопроходный GC, с предсказуемым временем работы. >>> > Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR? >> C>Мутабельность переменных. >> А это тут каким боком? Мутабельность уже учтена в GC. C>Про упрощение generational GC я уже писал, теперь напишу про трехцветный C>GC
Это всё понятно, immutable — это хорошо для GC. Что у нас с реализацией вытесняющей многозадачности?
Если нам не помогут, то мы тоже никого не пощадим.
IT wrote: >> > А это тут каким боком? Мутабельность уже учтена в GC. > C>Про упрощение generational GC я уже писал, теперь напишу про трехцветный > C>GC > Это всё понятно, immutable — это хорошо для GC. Что у нас с реализацией > вытесняющей многозадачности?
Это смотря с какой стороны смотреть.
Если со стороны приложения, то Эрланг дает вытесняющую многозадачность —
поток приложения может быть в "любой момент" вытеснен другим потоком
(насколько я помню, там планировщик каждые ~100 редукций запускается).
Если смотреть со стороны ОС — то Эрланг представляет собой однопоточное
приложение (точнее, уже многопоточное на SMP).
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Курилка, Вы писали:
IT>>>Со вторым понятно. А что делает невозможным реализацию первого в JVN/CLR?
К>>Реализовать ты сможешь, только SRT гарантировать будет по меньшей мере очень сложно. На той же Скале я напишу в коде актора бесконечный цикл и он "съест" поток.
IT>Это не должно быть проблемой. Компилятор может вставить в твой цикл код, который будет передавать управление шедулеру и никто ничего не съест. Проблема будет в случае вызова кода, который не контролируется компилятором. Проблема, типичная для кооперативной многозадачности.
В том и вопрос — как его туда вставить и как проконтроллировать "неподвластные" вещи.
К>>Как реализовать гранулируемость до чего нибудь уровня редукций — очень хороший вопрос. Возможно это можно сделать на Немерле путём работы с АСТ.
IT>АСТ тут не причём. Вытесняющая многозадачность возможна только насильственным путём, когда у рабочего потока никто ничего не спрашивает.
ОК, как ты будешь в виртуальной машине такое делать? Не используя потоки ОС? Если ты будешь вставлять в циклы код передачи управления шедулеру, то это у нас не будет вмешательством в АСТ?
Как можно сделать такое на Скале не переделывая компилятор я не вижу. Зато по-моему это нетак сложно реализовать на макросах, если ты имеешь контроль над генерируемым в итоге кодом.
К>ОК, как ты будешь в виртуальной машине такое делать? Не используя потоки ОС? Если ты будешь вставлять в циклы код передачи управления шедулеру, то это у нас не будет вмешательством в АСТ? К>Как можно сделать такое на Скале не переделывая компилятор я не вижу. Зато по-моему это нетак сложно реализовать на макросах, если ты имеешь контроль над генерируемым в итоге кодом.
В чем проблема? Инструментируем байт код (при загрузке), в т.ч. байт код Java библиотек. Допустим, вставляем туда обращение к шедулеру при каждом 10м вызове метода.
Кстати, а редукции в Erlang имеют гарантированное время выполнения? Т.е. может одна редукция выполняться полчаса?
Здравствуйте, n0name2, Вы писали:
К>>ОК, как ты будешь в виртуальной машине такое делать? Не используя потоки ОС? Если ты будешь вставлять в циклы код передачи управления шедулеру, то это у нас не будет вмешательством в АСТ? К>>Как можно сделать такое на Скале не переделывая компилятор я не вижу. Зато по-моему это нетак сложно реализовать на макросах, если ты имеешь контроль над генерируемым в итоге кодом.
N>В чем проблема? Инструментируем байт код (при загрузке), в т.ч. байт код Java библиотек. Допустим, вставляем туда обращение к шедулеру при каждом 10м вызове метода.
Т.е. надо в рантайме перехреначить байткод. Мне кажется, что АСТ курочить полегче будет.
Т.е. у тебя тут получится, что будет выполняться не байткод, а уже какой-то перетранслированный.
N>Кстати, а редукции в Erlang имеют гарантированное время выполнения? Т.е. может одна редукция выполняться полчаса?
Насколько я понимаю да, в смысле не может. Т.к. это гарантируется рантаймом, устройством библиотек и портов (с помощью которых происходит общение с вн. миром).
Как минимум в эрланге нет циклов, поэтому если не выполнять функции (что приведёт к вызову др. редукций), то единственный способ сделать задержку это написать кучу присваиваний каких-нибудь, но даже в этом случае у тебя будет конечное время (и хз какой у тебя должен быть бимфайл чтобы полчаса получилось). Т.е. как минимум надо очень-очень постараться. Причём я не знаю может есть какое-то ограничение на длину функции/бимфайла, просто практически такое никто не делает, они довольно маленькие по объёму.
В императивном же байткоде тебе сделать беск. цикл можно вполне просто, в этом и возникает проблемка.
Здравствуйте, Курилка, Вы писали:
К>Т.е. надо в рантайме перехреначить байткод. Мне кажется, что АСТ курочить полегче будет. К>Т.е. у тебя тут получится, что будет выполняться не байткод, а уже какой-то перетранслированный.
Не, как раз для этого есть куча средств. Сделать чтобы ВСЕ методы у ВСЕХ библиотек перед началом работы вызывали scheduler это 2-3 строчки кода, плюс добавить библиотеку и изменить startup script. И вообще, байткод гораздо проще чем AST языка. Правда, конечно, stack trace будет весьма странный получатся, что осложнит отладку довольно сильно.
К>В императивном же байткоде тебе сделать беск. цикл можно вполне просто, в этом и возникает проблемка.
В принципе, трансформировать байт код так, чтобы в циклы вставлялся тоже вызов scheduler — не проблема. Правда, сейчас пока для этого соотв-ие хуки JVM не предоставляет, так что придется немного повозится. Но, это довольно просто.
Проблема может быть, конечно если у нас synchronized блок и в нем цикл, нужно будет делать wait() чтобы освободить монитор. Тут я не уверен что все сходу правильно получится.
Но, вообще — проще вернуть green threads, вот и все. Собственно, насколько я понию, их так и не убрали из JVM. Только вот никакого особенного эффекта на типовых задачах они не дают, поэтому их и убрали.
Честно говоря, вообще я не очень понимаю зачем нужно все это. В Java такого рода задачи делаются немного по другому — заводится пул потоков (практически это OS threads, размер пула определяется исходя из кол-во CPU), и есть входная очередь задач. Соот-но поток взял очередную задачу, обработал ее, взялся за следующую. Особо криминального переключения контекстов или оверхеда на создание тысяч потоков тут нет.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Курилка, Вы писали:
К>>Т.е. надо в рантайме перехреначить байткод. Мне кажется, что АСТ курочить полегче будет. К>>Т.е. у тебя тут получится, что будет выполняться не байткод, а уже какой-то перетранслированный.
N>Не, как раз для этого есть куча средств. Сделать чтобы ВСЕ методы у ВСЕХ библиотек перед началом работы вызывали scheduler это 2-3 строчки кода, плюс добавить библиотеку и изменить startup script. И вообще, байткод гораздо проще чем AST языка. Правда, конечно, stack trace будет весьма странный получатся, что осложнит отладку довольно сильно.
ОК, что ты сделаешь с нативными библиотеками?
N>Честно говоря, вообще я не очень понимаю зачем нужно все это. В Java такого рода задачи делаются немного по другому — заводится пул потоков (практически это OS threads, размер пула определяется исходя из кол-во CPU), и есть входная очередь задач. Соот-но поток взял очередную задачу, обработал ее, взялся за следующую. Особо криминального переключения контекстов или оверхеда на создание тысяч потоков тут нет.
А сотен тысяч? Причём кратковременных, когда значительным может быть время создания/убивания потока?
Переключение контекста тоже вещь не бесплатная совсем, если выполняется на 1 проце.
Для "обычных" задач конечно условия такие не наблюдаются, но они и проектируются изначально иначе, на постоянные пулы и т.д.
Здравствуйте, Курилка, Вы писали:
К>ОК, что ты сделаешь с нативными библиотеками?
Ничего. В Java они практически нигде не используются. Это большая экзотика если речь идет о типовом бизнес приложении. Разве что — есть ввод/вывод и другие native вызовы в самом JDK, но, они все-таки много времени обычно не занимают и т.к. это SRT то можно ими пренебречь. Кстати, как проблема ввода/вывода в Erlang решается применительно к scheduling?
N>>Честно говоря, вообще я не очень понимаю зачем нужно все это. В Java такого рода задачи делаются немного по другому — заводится пул потоков (практически это OS threads, размер пула определяется исходя из кол-во CPU), и есть входная очередь задач. Соот-но поток взял очередную задачу, обработал ее, взялся за следующую. Особо криминального переключения контекстов или оверхеда на создание тысяч потоков тут нет.
К>А сотен тысяч? Причём кратковременных, когда значительным может быть время создания/убивания потока?
А зачем поток каждый раз создавать? Ведь можно завести несколько (2-4) потоков, которые обрабатывают общую очередь запросов (mailbox в терминах Erlang).
К>Для "обычных" задач конечно условия такие не наблюдаются, но они и проектируются изначально иначе, на постоянные пулы и т.д.
О чем и речь — собственно, пулы потоков это обычная практика. Я согласен — JVM не для всех классов задач подходит, no silver bullet так сказать, но, мне кажется, что если реально задача не решается с помощью пула потоков, то это большая экзотика. Пожалуйста, приведи пример (только не академический а из реального, желательно не телеком, бизнеса) такой задачи.
Тотже эксперемент с green threads очень показателен — очевидно, что scheduling в стиле Erlang сделать для JVM довольно легко, но, толку это особого не даст для типовых задач. Кстати, от green threads отказались после того, как scheduler в Linux стал работать гораздо лучше и для типовых задач разница стала незаметной.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Курилка, Вы писали:
К>>ОК, что ты сделаешь с нативными библиотеками?
N>Ничего. В Java они практически нигде не используются. Это большая экзотика если речь идет о типовом бизнес приложении. Разве что — есть ввод/вывод и другие native вызовы в самом JDK, но, они все-таки много времени обычно не занимают и т.к. это SRT то можно ими пренебречь. Кстати, как проблема ввода/вывода в Erlang решается применительно к scheduling?
Есть подозрение, что трудновато будет принебречь, в любом случае тебе надо будет инструментировать весь байткод, причём не факт что это пройдёт безболезненно.
Хотя, если честно, придумывать уже где грабли могут вылезти несколько лень
N>Тотже эксперемент с green threads очень показателен — очевидно, что scheduling в стиле Erlang сделать для JVM довольно легко, но, толку это особого не даст для типовых задач. Кстати, от green threads отказались после того, как scheduler в Linux стал работать гораздо лучше и для типовых задач разница стала незаметной.
Вопрост ещё что кроме "обычности" задач ещё присутствует обычность подходов, в том числе архитектурных. Одна сборка мусора при иммутабельности реально уже офигенно выигрывает. Просто речь о том выигрыш от такого подхода при обычном императивном программинге довольно мал, вот это и показали green threads
Здравствуйте, n0name2, Вы писали:
N>Но, вообще — проще вернуть green threads, вот и все. Собственно, насколько я понию, их так и не убрали из JVM. Только вот никакого особенного эффекта на типовых задачах они не дают, поэтому их и убрали.
Как я понимаю, в java "зелёные" треды — это кооперативная многозадачность. То есть это не тот случай.
Хотя, в конечном итоге, так и делают:
At 10,000 connections, BEA JRockit 3.1 on Windows has 14 times the throughput of any other Java platform---by far, the best network scalability I have ever tested. While other Java vendors waited for better threading support in the operating system or new programming interfaces for the application, the JRockit team solved the Java threads problem right where it originated. The results are remarkable, and BEA made a wise purchase.
N>Честно говоря, вообще я не очень понимаю зачем нужно все это. В Java такого рода задачи делаются немного по другому — заводится пул потоков (практически это OS threads, размер пула определяется исходя из кол-во CPU), и есть входная очередь задач. Соот-но поток взял очередную задачу, обработал ее, взялся за следующую. Особо криминального переключения контекстов или оверхеда на создание тысяч потоков тут нет.
Здравствуйте, Курилка, Вы писали:
К>Есть подозрение, что трудновато будет принебречь, в любом случае тебе надо будет инструментировать весь байткод, причём не факт что это пройдёт безболезненно. К>Хотя, если честно, придумывать уже где грабли могут вылезти несколько лень
Возможно, что-то и вылезет, я не спорю. А код весь инструментируют, допустим в целях logging иногда. Кстати, у Sun еще есть Solaris и DTrace, который умеет в целях отладки инструментировать native код. В принципе, я когда говорил с Sunовскими представителями, они сказали что дали бы возможность инструментировать native код не только в целях отладки, но боятся
А еще в Solaris есть LWP и маппинг Java потоков на kernel scheduling entity как M на N, соот-но, там оверхед на context switch еще меньше чем при NPTL под Linux. Кстати, Niagara (T1) под Solaris себя отлично чувствует при большем кол-ве switchей.
К>Вопрост ещё что кроме "обычности" задач ещё присутствует обычность подходов, в том числе архитектурных. Одна сборка мусора при иммутабельности реально уже офигенно выигрывает. Просто речь о том выигрыш от такого подхода при обычном императивном программинге довольно мал, вот это и показали green threads
Не спорю, сборщик мусора, конечно, был бы гораздо эффективнее. Да и оверхед мутатора бы ушел тоже. Но, на сборку мусора тратятся единицы процентов CPU time. Плюс ее можно проводить в паралельном потоке (не на все 100%, но, существенную часть). Так что — овчинка выделки не стоит в данном конкретном случае.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Как я понимаю, в java "зелёные" треды — это кооперативная многозадачность. То есть это не тот случай.
В смысле? В чем принципиальное отличие green threads и Erlang actors с т.з. scheduling?
ANS>
ANS>At 10,000 connections, BEA JRockit 3.1 on Windows has 14 times the throughput of any other Java platform---by far, the best network scalability I have ever tested. While other Java vendors waited for better threading support in the operating system or new programming interfaces for the application, the JRockit team solved the Java threads problem right where it originated. The results are remarkable, and BEA made a wise purchase.
Это, скорее всего, было во времена кривого ядра Linux (до 2.6). Сейчас — не актуально.
ANS>Кстати, вот
Ну, во-первых, по большому счету, это всего лишь аргумент в тему почему MS sucks а Solaris rulezzz, во-вторых, 8к потоков зачем создавать? Может, просто пул сделать? Или NIO selectors использовать (non blocking IO)?
Здравствуйте, n0name2, Вы писали:
N>во-вторых, 8к потоков зачем создавать? Может, просто пул сделать? Или NIO selectors использовать (non blocking IO)?
"Одна задача -- один процесс" -- гораздо более простая модель для разработки.
Тем более, что убивать почившие процессы в такой модели гораздо проще, чем потоки в пуле.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, n0name2, Вы писали:
N>А еще в Solaris есть LWP и маппинг Java потоков на kernel scheduling entity как M на N
Кстати, это в прошлом. Начиная с 10 солярки, по умолчанию, используется модель 1:1. Мне всегда было интересно, если M:N была такая удобная, то почему от неё отказались?
E>"Одна задача -- один процесс" -- гораздо более простая модель для разработки. E>Тем более, что убивать почившие процессы в такой модели гораздо проще, чем потоки в пуле.
Чем принципиально отличается следующие два куска кода с т.з. простоты:
new Thread() {
public void run() {
System.out.println("Hi!");
}
}.start();
и
executor.submit(new Runnable() {
public void run() {
System.out.println("Hi!");
});
Другое дело если им нужно активно взаимодействовать — тут нужно уже смотреть задачу конкретную.
Non blocking IO — да, это чуть сложнее, согласен. Хотя, над ним уже построили высокоуровневые абстракции и ничего особенно сложного там нет. Да и в типовом проекте это вообще не нужно. Кстати, простота программирования в императивном vs функциональном стиле это отдельная тема, конечно и тут все не столь очевидно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
N>>А еще в Solaris есть LWP и маппинг Java потоков на kernel scheduling entity как M на N
ANS>Кстати, это в прошлом. Начиная с 10 солярки, по умолчанию, используется модель 1:1. Мне всегда было интересно, если M:N была такая удобная, то почему от неё отказались?
Ну как — если смотреть скорость создания потоков, то тут M:N рвет "новую" реализацию linthreads как тузик грелку, а если смотреть скорость реальных приложений то новый более простой шедулер оказался эффективнее, удалось kernel context switches сделать всего в три раза дороже чем user level switches.
Кстати, нашел тут блог адептов Erlang. Там они делают бенчмарк на message passing Java vs Erlang. Вот оригинальный исходник бенчмарка:
import java.util.concurrent.*;
public class SpawnTest extends Thread {
public static void main(String[] args) {
int M = Integer.parseInt(args.length > 0 ? args[0] : "1");
int N = Integer.parseInt(args.length > 1 ? args[1] : "1000000");
int NpM = N / M;
BlockingQueue queue = new LinkedBlockingQueue();
long startTime = System.currentTimeMillis();
for (int i = 0; i < M; i++) { new Body(queue, NpM).start(); }
for (int i = 0; i < M; i++) { try { queue.take(); } catch (InterruptedException ie) {} }
long stopTime = System.currentTimeMillis();
System.out.println((NpM * M) / ((stopTime - startTime) / 1000.0));
}
public static class Body extends Thread {
BlockingQueue queue;
int count;
public Body(BlockingQueue queue, int count) {
this.queue = queue;
this.count = count;
}
public void run() {
if (count == 0) {
try { queue.put(this); } catch (InterruptedException ie) {}
} else {
new Body(queue, count - 1).start();
}
}
}
}
Запустив его получаем удручающую скорость — всего 4073 messages/sec (на винде). Но, так на Java ни один вменяемый программист не напишет, модифицировав код всего на пару строк
import java.util.concurrent.*;
public class Test25 extends Thread {
public static Executor executor;
public static void main(String[] args) {
int M = Integer.parseInt(args.length > 0 ? args[0] : "1");
int N = Integer.parseInt(args.length > 1 ? args[1] : "1000000");
executor = Executors.newFixedThreadPool(M);
int NpM = N / M;
BlockingQueue queue = new LinkedBlockingQueue();
long startTime = System.currentTimeMillis();
for (int i = 0; i < M; i++) { executor.execute(new Body(queue, NpM)); }
for (int i = 0; i < M; i++) { try { queue.take(); } catch (InterruptedException ie) {} }
long stopTime = System.currentTimeMillis();
System.out.println((NpM * M) / ((stopTime - startTime) / 1000.0));
}
public static class Body implements Runnable {
BlockingQueue queue;
int count;
public Body(BlockingQueue queue, int count) {
this.queue = queue;
this.count = count;
}
public void run() {
if (count == 0) {
try { queue.put(this); } catch (InterruptedException ie) {}
} else {
if (count % 10000 == 0) System.out.println("" + count);
executor.execute(new Test25.Body(queue, count - 1));
}
}
}
}
Удалось получить целых 336700 messages/sec Что примерно равно результатам Erlang из тестов здесь
Однако, если применить магическую концепцию императивного программирования под названием цикл и причесать код
import java.util.concurrent.*;
public class Test25 extends Thread {
public static Executor executor;
public static void main(String[] args) throws InterruptedException {
int M = Integer.parseInt(args.length > 0 ? args[0] : "1");
int N = Integer.parseInt(args.length > 1 ? args[1] : "1000000");
executor = Executors.newFixedThreadPool(M);
int NpM = N / M;
BlockingQueue queue = new ArrayBlockingQueue(1000 * 1000);
long startTime = System.currentTimeMillis();
for (int i = 0; i < M; i++) executor.execute(new Body(queue, NpM));
for (int i = 0; i < N; i++) queue.take();
long stopTime = System.currentTimeMillis();
System.out.println((NpM * M) / ((stopTime - startTime) / 1000.0));
}
public static class Body implements Runnable {
BlockingQueue queue;
int count;
public Body(BlockingQueue queue, int count) {
this.queue = queue; this.count = count;
}
public void run() {
try {
for (int i = 0; i < count; i++) queue.put(this);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}
}
Здравствуйте, n0name2, Вы писали:
N>А зачем поток каждый раз создавать? Ведь можно завести несколько (2-4) потоков, которые обрабатывают общую очередь запросов (mailbox в терминах Erlang).
Речь идет о том, что даже переключение потоков может оказаться слишком дорогим для случая инфинитезимальных единиц работы.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, n0name2, Вы писали:
N>>А зачем поток каждый раз создавать? Ведь можно завести несколько (2-4) потоков, которые обрабатывают общую очередь запросов (mailbox в терминах Erlang). S>Речь идет о том, что даже переключение потоков может оказаться слишком дорогим для случая инфинитезимальных единиц работы.
Здравствуйте, Sinclair, Вы писали:
N>>А зачем поток каждый раз создавать? Ведь можно завести несколько (2-4) потоков, которые обрабатывают общую очередь запросов (mailbox в терминах Erlang). S>Речь идет о том, что даже переключение потоков может оказаться слишком дорогим для случая инфинитезимальных единиц работы.
А зачем потоки вообще переключать если у нас кол-во worker threads в пуле, грубо говоря, равно кол-ву CPU? Ну, конечно, не гарантируется что у нас контексты переключатся не будут, но это будет происходить весьма редко.
Если речь идет об обмене данными м/у процессами (и соот-но происходит блокировка ожидающего потока), то, все-таки в большинстве случаев мы обойдемся spin lockом (+atomic get&set) и все будет происходить чисто на user level, никаких вызовов ядреных операций.
Кроме того, даже в Erlang переключение м/у процессами и обмен данными наверняка не полностью бесплатны, более того, думаю, что в java.util.concurrent это реализовано несколько лучше.
n0name2,
N>То получается уже 1560062 messages/sec.
Хорошо. Но строго говоря, его эрланговский вариант тоже не слишком впечатляет. Если мы уж меряем скорость переписываний указателей из одного места в другое (), то почему бы не проставить везде нужные гварды, не скомпилировать hipe (хотя под Дебианом может уже) и не запустить с опцией -hybrid?
Да и потом, 1000 потоков — курам на смех. Хотя бы сотенку тыщщёнок.
Короче, как выразился Влад, "тест из разряда "физики шутят"". Что с той, что с другой стороны.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
N>>То получается уже 1560062 messages/sec.
LCR>Хорошо. Но строго говоря, его эрланговский вариант тоже не слишком впечатляет. Если мы уж меряем скорость переписываний указателей из одного места в другое (), то почему бы не проставить везде нужные гварды, не скомпилировать hipe (хотя под Дебианом может уже) и не запустить с опцией -hybrid?
На самом деле кроме копирования происходит самое главное — обмен сообщениями м/у потоками. Т.е. используются мутексы и т.д. и т.п.
LCR>Короче, как выразился Влад, "тест из разряда "физики шутят"". Что с той, что с другой стороны.
Тест говорит о том, что мифическое приемущество Erlang в concurrent программировании по сравнению с Java объясняется скорее тем, что Erlangисты не понимают как задачу решить оптимально средствами Java, а не тем, что есть некие фундаментальные ограничения у самой JVM.
Проводились ли вообще вменяемые сравнения или ничего поинтереснее адепты Erlang предложить немогут? Скорость создания потоков мне не интересна — обычно массово их не создают а обходятся пулами.
Здравствуйте, n0name2, Вы писали:
N>Тест говорит о том, что мифическое приемущество Erlang в concurrent программировании по сравнению с Java объясняется скорее тем, что Erlangисты не понимают как задачу решить оптимально средствами Java, а не тем, что есть некие фундаментальные ограничения у самой JVM. N>Проводились ли вообще вменяемые сравнения или ничего поинтереснее адепты Erlang предложить немогут? N>Скорость создания потоков мне не интересна — обычно массово их не создают а обходятся пулами.
Уже не раз приводился пример Apache vs YAWS. Apache — хороший представитель пулов, кстати.
Здравствуйте, Курилка, Вы писали:
N>>>А зачем поток каждый раз создавать? Ведь можно завести несколько (2-4) потоков, которые обрабатывают общую очередь запросов (mailbox в терминах Erlang). S>>Речь идет о том, что даже переключение потоков может оказаться слишком дорогим для случая инфинитезимальных единиц работы.
К>каких-каких?
Думаю таких.
. Почему бы не сделать вообще 1 тред (кстати с какими параметрами ты это запускал?). И выполнить вообще всё последовательно. Ты получиш еще больше количество сообщений в сек.
N> BlockingQueue queue = new LinkedBlockingQueue();
N> long startTime = System.currentTimeMillis();
N> for (int i = 0; i < M; i++) { executor.execute(new Body(queue, NpM)); }
Я не понял. Используется одна общая очередь на все треды? Это баг.
Здравствуйте, n0name2, Вы писали:
N>А зачем потоки вообще переключать если у нас кол-во worker threads в пуле, грубо говоря, равно кол-ву CPU? Ну, конечно, не гарантируется что у нас контексты переключатся не будут, но это будет происходить весьма редко.
Не фижу как это будет работать если у тебя будет только стандартная сановская JVM.
Здравствуйте, fddima, Вы писали:
F> Уже не раз приводился пример Apache vs YAWS. Apache — хороший представитель пулов, кстати.
Не, как раз Apache заводит отдельный процесс на каждого клиента. Вообще, приличный Java web server рвет Apache как тузик грелку. А для большого кол-во requestов есть NIO (non blocking IO), в одном потоке можно обрабатывать сколько хочешь клиентов
Воспроизвести тест как на твоей ссылки конечно мало реально, но, известно что NIO based серверы практически не деградируют при большом кол-ве клиентов.
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 где-то, что-то хуже проработано. Всё таки для этого нужно изучать внутренности и первого и второго.
Здравствуйте, n0name2, Вы писали:
ANS>>Допустим у тебя 32 проца. Соответсвенно тред пул у тебя на 32 треда. Тебе не кажется это несколько... ограниченным?
N>А в чем проблема? Зачем тебе больше потоков чем процессоров? Единственная причина по которой это нужно — если потоки блокируются на вводе/выводе. Это решается с помощью NIO.
Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Я так понимаю, задача — обеспечить максимально конкурентный приём сообщений, а не максимальную пропускную способность (которая будет при схеме "один тред всё время отправляет, потом он всё время принимает"). Отображает ли это исходный тест на Erlang — я не готов сейчас сказать.
Что ты понимаешь под максимальной конкурентностью? Минимальную задержку, среднюю задержку? Средняя задержка в моем решении будет меньше, минимальная, возможно, больше. Если уже речь идет об этом, тут, действительно, нужно подбирать размер пула под заданные требования. Причем, если требование по минимальной задержке разумное, то оно легко ложится на пул при небольших накладных расходах на переключение контекстов.
ANS>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.
Если ты называешь thread pool конечным автоматом или user-level threads — пусть это будет так, неважно.
N>Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д. F>Наверняка? Я бы не стал утверждать что в Erlang и/или Java где-то, что-то хуже проработано. Всё таки для этого нужно изучать внутренности и первого и второго.
Разработчики JVM занимаются годами оптимизацией блокировок, переключений контекстов и т.д. Опробовано большое кол-во различных методов, вложены огромные деньги. В Erlang поддержка SMP появилась несколько месяцев назад. При всем уважении, я в чудеса не верю. Более того, адетпы Erlang подтверждают это — в SMP конфигурации обмен сообщениями происходит медленнее в разы.
Здравствуйте, n0name2, Вы писали:
F>> На практике non blocking, а по нашенски overlapped не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п. N>Это только потому, что библиотек нет на .NET нормальных, которые предоставляют несколько более высокий уровень чем raw selectors. На Java есть таже Apache Mina, которая делает все это совершенно тривиальным. Кроме того, по большей части, это вообще скрыто от юзера т.к. этим всем занимается web сервер.
Ага, внимательно пересмотрел твою ссылку. Ну и что? Логичное решение, но вполне себе тривиал, как по мне.
Я про .NET вообще не говорил, а сделать удобные обёртки для overlapped io не такая уж и большая проблема, если такая возможность присутствует в системе. Принимать запросы по nio это круто, но веб-сервер не только с сокетами работает же, а я, глупый, почему-то подумал что у них там что-то более эдакое. Еще раз убеждаюсь, как всё обычно, ничего нового...
Хотя конечно, то что это они сделали — только плюс.
N>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.
Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.
Здравствуйте, fddima, Вы писали:
F> Ага, внимательно пересмотрел твою ссылку. Ну и что? Логичное решение, но вполне себе тривиал, как по мне.
Естественно, а ничего сложного и не нужно.
F> Принимать запросы по nio это круто, но веб-сервер не только с сокетами работает же, а я, глупый, почему-то подумал что у них там что-то более эдакое.
А чем он еще занимается? Ты базу имеешь в виду? Это тоже можно сделать в NIO стиле вполне, но, это не актуально т.к. вся ценность NIO в том, чтобы работать с большим кол-вом клиентов с низкой активностью. Кстати, IIS использует overlapped или нет? Вообще, я не очень представляю себе современный web сервер с классической моделью 1 клиент : 1 поток OS (или поток из пула).
F> Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.
Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>Я так понимаю, задача — обеспечить максимально конкурентный приём сообщений, а не максимальную пропускную способность (которая будет при схеме "один тред всё время отправляет, потом он всё время принимает"). Отображает ли это исходный тест на Erlang — я не готов сейчас сказать.
N>Что ты понимаешь под максимальной конкурентностью?
Принимать сообщения от максимального кол-ва "производителей" за определённое среднее время и не больше чем пороговое максимальное время.
ANS>>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.
N>Если ты называешь thread pool конечным автоматом или user-level threads — пусть это будет так, неважно.
Блин. У тебя fixed пул на 32 потока. Тебе нужно выполнять 33 действия одновременно. Что делать?
Здравствуйте, n0name2, Вы писали:
N>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.
Дай линк на какие-нибудь картинки, плиз. Интересно посмотреть.
А про интерпретируемость — это неправда, вообще-то. Для эрланга есть HiPE (High Performance Erlang, http://www.it.uu.se/research/group/hipe/), он входит в поставку эрланга с октября 2001-го, компилирует BEAM-файлы в нативный код для платформы.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Принимать сообщения от максимального кол-ва "производителей" за определённое среднее время и не больше чем пороговое максимальное время. ANS>Блин. У тебя fixed пул на 32 потока. Тебе нужно выполнять 33 действия одновременно. Что делать?
Зачем это нужно? Какое под этим бизнес требование? Сколько занимает исполнение одного действия? Если больше чем "пороговое максимальное время"/2, то переключений контекстов будет относительно мало и накладными расходами можно пренебречь. Если меньше, то 33я задача немного подождет и исполнится. Тут речь идет о сотнях и миллионах сообщений в секунду, я не думаю, что есть осмысленные бизнес задачи, где нужен гарантированный ответ в течение 1:100000й секунды. И для таких задач именно throughput имеет огромное значение т.к. иначе машина просто встанет (вернее, в случае erlang будет обрабатывать некое кол-во сообщений/сек, но, очередь сообщений будет расти очень быстро и в итоге все упадет по out of memory).
Здравствуйте, n0name2, Вы писали:
N>А чем он еще занимается? Ты базу имеешь в виду?
Ну и файлики тоже...
N>Кстати, IIS использует overlapped или нет? Вообще, я не очень представляю себе современный web сервер с классической моделью 1 клиент : 1 поток OS (или поток из пула).
Про IIS не знаю. У нас с его производительностью проблем нет.
N>Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET? Это то откуда?
Ну да ладно, я не адепт Erlang-а, хотя он мне и нравится больше других ФЛ-языков.
Реальных примеров я что-то не видел с обоих сторон, а выплёвывать простые html-странички для тестов — это не тест. На том же Apache, может быть включён SSI, и столько всякой ерунды, что становится вообще неясно, что с чем сраниваем и где происходит проседание, если вообще происходит.
Ну и необходимости строить динамические страницы у меня сейчас вообще нет, и вроде даже не собираюсь... так что мне нечего на это ответить.
Само собой, я бы выбрал инструмент, который бы мне наиболее подошел, скилов по эрлангу гораздо меньше, чем по дотнету, отсюда можешь сделать вывод -> я бы не стал рисковать делать на эрланге. Да и на работе никто бы не позволил.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Курилка, Вы писали:
К>>Вопрос заключается в том, что создание потока требует накл. расходов, также как и переключение между активными потоками, в отличие модели эрланга, где самым критичным (я думаю) может быть передача больших объёмов данных путём пересылки сообщний.
N>Я говорю о том, что если использовать пулы потоков, то никаких накладных расходов нет. Ни на переключение м/у активными потоками, ни на создание нового. Есть поток, он обрабатывает входную очереди и все. Единственные расходы — это передача данных м/у потоками и засыпание/просыпание потока (когда некоторое время очередь пуста), но, это оч незначительно.
Согласен. Только подходы разные.
N>Накладные расходы в Erlang на переключение наверняка есть. Все-таки там есть stack.
И? Стэк это всего лишь указатель на область памяти, поменять один указатель другим реально тяжёлая операция?
N>Кроме того, в случае если работают несколько Erlang schedulers (SMP) там вообще появляются уже расходы на межпроцессное взаимодействие (которое хуже проработано чем в Java наверняка), переключение контекстов и т.д.
Если честно, но не готов рассказывать как SMP-версия эрланга работает — просто не знаю подробностей. Про "наверняка" не уверен, но спорить не буду — т.к. подробно ни ту ни другую реализацию не знаю. Только одна мысль по поводу того, что явовские потоки не изолированны по данным друг от друга, тогда как в эрланге такого нет.
Здравствуйте, n0name2, Вы писали:
ANS>>Допустим у тебя 32 проца. Соответсвенно тред пул у тебя на 32 треда. Тебе не кажется это несколько... ограниченным?
N>А в чем проблема? Зачем тебе больше потоков чем процессоров? Единственная причина по которой это нужно — если потоки блокируются на вводе/выводе. Это решается с помощью NIO.
Хочу отметить, что весь разговор идет вокруг таких задач, которые решаются в рамках одного потока. Для таких задач действительно порождение большего, чем кол-во CPU потоков не нужно.
Если же обсуждать абстрактного коня в вакууме, то пример, когда ограничение на кол-во потоков в пуле является ограничением, привести легко.
Например, решаю я некую задачу, которая хорошо делится на 2 (или N) частей, каждая из которых может решаться отдельно (с возможным соединением результатов в конце). Например, поиск чего-то в интернете (это абстрактный пример), когда каждая порожденная пара потоков обрабатывает свою половину от объема задачи породившего их потока. Сам породивший их поток засыпает, пока не получит от них ответ. В итоге, при такой организации, работать у нас будут только те потоки, которые находятся в листьях этого "дерева". Остальные потоки будут просто загромождать пул.
Хотя я понимаю, что в этой задаче можно оставлять порождающему потоку подчасть задачи.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Проблема в том, что при этом либо ты выполняеш не больше 32 задач (этакий продвинутый MS-DOS), либо ты используеш конечный автомат, либо делаеш свои user-level threads.
Erlang выполняет не больше задач в этой постановке вопроса.
Здравствуйте, VladD2, Вы писали:
ANS>>Создатели языка пишут, что есть, Влад пишет, что нет. Интересно кто прав?
VD>Ссылки, плиз, на то где авторы что-то о гарантиях пишут.
Выбираеш в Янусе пункт меню "Действие" подпункт "Свернуть и перейти в начало темы", читаеш текст.
И, пожалуйста, осуждай Пастернака после прочтения, а не вместо.
Здравствуйте, Курилка, Вы писали:
N>>Полно бенчмарков и картинок на эту тему. Они похожи на график YAWS vs Apache как две капли воды. Только YAWS интерпретируемый и реально throughput у него гораздо меньше.
К>Дай линк на какие-нибудь картинки, плиз. Интересно посмотреть.
Похоже, погорячился насчет полно. В основном, все-таки throughput тестируют, мало кого интересуют сценарии с большим кол-вом keep alive пользователей. Сходу нашел только и . Есть без картинок замеры, но, подтверждают что такая софтина как AsyncWeb совершенно нормально работает с тысячами и десятками тысяч клиентов одновременно.
Здравствуйте, mik1, Вы писали:
M>Например, решаю я некую задачу, которая хорошо делится на 2 (или N) частей, каждая из которых может решаться отдельно (с возможным соединением результатов в конце). Например, поиск чего-то в интернете (это абстрактный пример), когда каждая порожденная пара потоков обрабатывает свою половину от объема задачи породившего их потока. Сам породивший их поток засыпает, пока не получит от них ответ. В итоге, при такой организации, работать у нас будут только те потоки, которые находятся в листьях этого "дерева". Остальные потоки будут просто загромождать пул.
Такого рода задачи не порождают большого кол-ва context switches, соот-но тут Erlang ничем толком не поможет. Согласен, что пул это не silver bullet. Миллион одновременных задач, каждая из которых делится на несколько и собирается в конце вне кластера я слабо себе могу представить. Даже тотже Google такими throughput rates не оперирует.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ну я надеюсь, я достаточно подробно пояснил, почему я считаю, что Эрланг невозможен под jvm/.net? Хочу правильно поставить акцент: я не отрицаю возможность lightweight библиотеки, я всего лишь навсего очень-очень сильно сомневаюсь, что она может составить конкуренцию Эрлангу на _его_ поле боя и на смежных площадях:
Уважаемые коллеги, обсуждающие, как аналогичные задачи можно успешно решать за счет очередей сообщений и пулов потоков. Мне кажется, вы недооцениваете одной важной вещи, которую предоставляет поход Erlang-а. Если упустить ее из виду, то очередь сообщений действительно может успешно использоваться (равно как и язык ассемблера в умелых руках). Разница всего лишь в цене и в возможностях.
А предоставляет Erlang такую штуку, как возможность оформить какую-либо автономную операцию в виде самостоятельного процесса. И наплодить таких процессов сотни тысяч. И не иметь с этим делом большого геморроя, прибивая за просто так любой процесс и очень дешево порождая новый процесс. И все это в террариуме, в котором копошатся тысячи и тысячи процессов.
В качестве примера возьмем гипотетическую доставку подписчикам RSDN текстов новых постов в виде e-mail сообщений (пример актуальный кстати, т.к. изрядный процент сообщений теряется). Предположим, что процедура доставки одного сообщения одному абоненту оформляется в виде самостоятельного процесса. Он использует механизм гарантированной доставки, повторяя попытки отсылки сообщения с возрастающим тайм-аутом после каждой неудачи. После N неудачных попыток процесс просто завершает свою работу ("на нет и суда нет"). Реализовать такой процесс в виде одного for-а не составляет труда (извините, пример не на Erlang-е, а на псевдо-языке):
deliver_message( post, recipient )
{
for(i = 0; i != N; ++i )
{
result = try_deliver( post, recipient );
if( ok != result )
{
// Если временная проблема доставки, то есть
// смысл повторить ее позже.
if( can_be_delivered_later( result ) )
sleep( (i+1)*TIMEOUT );
else
// Если SMTP сервера нет или он говорит, что
// такого получателя нет, то просто прекращаем
// дальнейшие попытки.
die( post, recipient, THESE_STUPID_BEES_MAKE_INVALID_HONEY );
}
else
// Сообщение отправлено.
die( post, recipient, HAVE_A_NICE_DAY );
}
Функция die может помечать в базе, что сообщение на данного абонента доставлять больше не нужно (для корректного продолжения работы после рестартов).
Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.
А вот альтернативные решения требуют несколько больших усилий. Самый простой вариант -- рескан с каким-то периодом базы в поиске пар сообщение/абонент, которым нужно произвести доставку. Но для того, чтобы протестировать его под нагрузкой придется сильно попотеть, набивая тестовую БД и имитируя различные исходы доставки сообщения. А так же верификации результатов тестирования.
Чуть более сложный вариант -- организация каждой пары сообщение/абонент в виде объекта. Этот объект ставится в очередь. Когда какая-то из нитей рабочего пула извлекает такой объект, она выполняет очередную попытку доставки, затем анализирует разультат доставки и принимает решение о том, что делать дальше. Здесь нужно придумывать, как ставить в очереди "отложенные" объекты, время повторной доставки которых далеко "в будущем" -- ведь вытащив такую заявку из вершины очереди рабочая нить должна понять, что еще рано, вернуть объект обратно и заснуть "до лучших" времен. Нужно самим делать механизм "прибивания" рабочих нитей которые из-за каких-то сбоев в функции try_deliver не возвращаются из обрабоки очередного сообщения.
Вот как-то так. Или я что-то не правильно про Erlang понял?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, n0name2, Вы писали:
N>Такого рода задачи не порождают большого кол-ва context switches, соот-но тут Erlang ничем толком не поможет. Согласен, что пул это не silver bullet. Миллион одновременных задач, каждая из которых делится на несколько и собирается в конце вне кластера я слабо себе могу представить. Даже тотже Google такими throughput rates не оперирует.
Да задачу представить то несложно.
Найти все сайты в интернете, в которых встречается строка "n0name2". Допускать, что у нас в массиве (или индексированной возврастающими по порядку числами табличке в БД) уже лежит список всех доменных имен Интернета.
Процессоры быстрые, коннект к инету явно медленнее. Все равно имеет смысл порождать очень много потоков. Тут размер пула заранее не задашь.
Здравствуйте, eao197, Вы писали:
E>А предоставляет Erlang такую штуку, как возможность оформить какую-либо автономную операцию в виде самостоятельного процесса. И наплодить таких процессов сотни тысяч. И не иметь с этим делом большого геморроя, прибивая за просто так любой процесс и очень дешево порождая новый процесс. И все это в террариуме, в котором копошатся тысячи и тысячи процессов.
Если опустить слово "убивать", то executor-ы в Яве эти самые АВТОНОМНЫЕ операции выполняют не хуже.
Если надо убивать, то см конец поста.
E>А вот альтернативные решения требуют несколько больших усилий. Самый простой вариант -- рескан с каким-то периодом базы в поиске пар сообщение/абонент, которым нужно произвести доставку. Но для того, чтобы протестировать его под нагрузкой придется сильно попотеть, набивая тестовую БД и имитируя различные исходы доставки сообщения. А так же верификации результатов тестирования.
Опять не вижу проблемы (в Яве). Используем ScheduledThreadPoolExecutor. Если сообщение не отправили, ставим себя же с новым увеличенным delay-ем в executor, удаляя оттуда же свой текущий экзмепляр. Имхо, должно работать.
E>Чуть более сложный вариант -- организация каждой пары сообщение/абонент в виде объекта. Этот объект ставится в очередь. Когда какая-то из нитей рабочего пула извлекает такой объект, она выполняет очередную попытку доставки, затем анализирует разультат доставки и принимает решение о том, что делать дальше. Здесь нужно придумывать, как ставить в очереди "отложенные" объекты, время повторной доставки которых далеко "в будущем" -- ведь вытащив такую заявку из вершины очереди рабочая нить должна понять, что еще рано, вернуть объект обратно и заснуть "до лучших" времен. Нужно самим делать механизм "прибивания" рабочих нитей которые из-за каких-то сбоев в функции try_deliver не возвращаются из обрабоки очередного сообщения.
Эммм... try_deliver вызывает внешний код в обоих случаях (Erlang и C#/Java) или же пользуется внутренним кодом?
Для внешнего кода убивать поток одинаково невесело и там и там.
Во внутреннем коде при желании код отправки сообщений можно оснастить вызовами аналогичными Явовскому Thread.currentThread.isInterrupted()
Так что ниточки при желании прибивать можно и там и там.
Здравствуйте, mik1, Вы писали:
M>Да задачу представить то несложно. M>Найти все сайты в интернете, в которых встречается строка "n0name2". Допускать, что у нас в массиве (или индексированной возврастающими по порядку числами табличке в БД) уже лежит список всех доменных имен Интернета. M>Процессоры быстрые, коннект к инету явно медленнее. Все равно имеет смысл порождать очень много потоков. Тут размер пула заранее не задашь.
В чистом виде задача для Non blocking IO... Просто классический пример.
E>В качестве примера возьмем гипотетическую доставку подписчикам RSDN текстов новых постов в виде e-mail сообщений (пример актуальный кстати, т.к. изрядный процент сообщений теряется). Предположим, что процедура доставки одного сообщения одному абоненту оформляется в виде самостоятельного процесса. Он использует механизм гарантированной доставки, повторяя попытки отсылки сообщения с возрастающим тайм-аутом после каждой неудачи. После N неудачных попыток процесс просто завершает свою работу ("на нет и суда нет"). Реализовать такой процесс в виде одного for-а не составляет труда (извините, пример не на Erlang-е, а на псевдо-языке):
Тоже совершенно классическая NIO задача. Здесь вообще никакого пула не нужно, все в одном потоке.
VladD2 wrote: > А кто-то проводил реальные эксперементы эффективности? Есть доставерная > информация о том, что Эрлэнговый ЖЦ дествительно эффективнее дотнетного? > Ведь кроме псевда-раелтайм-гарантий еще важна эффективность.
Мне непонятно как сравнивать.
> И не фатк, что алгоритм с поколениями плюс джит-компиляция не окажется > эффктивнее.
Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они
работать будут заметно эффективнее, чем в .NET (не нужен write barrier).
Ну а JIT — это к GC не относится.
> Лично у меня большое подозрение, что окажется и сильно.
Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг
совершенно из-за этого не подходит.
Здравствуйте, Cyberax, Вы писали:
C>Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они C>работать будут заметно эффективнее, чем в .NET (не нужен write barrier).
Извини. Меня не интересуют пустые слова. Будут данные, подходи.
А write barrier просто пушинка супротив интерпретатора и динамики.
C>Ну а JIT — это к GC не относится.
Еще как отностится. Есть две системы с разными проектными решениями. У одной поколенчатый ЖЦ, возможность модифицировать данные в хипе, компилирумый код. У второй интерпретация, своя схема ЖЦ, и т.п. Слушать разглагольствования о теоритическом превосходстве просто нет желания. Тут можно говорить только о эксперементальном подтвержедении.
>> Лично у меня большое подозрение, что окажется и сильно. C>Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг C>совершенно из-за этого не подходит.
Ну, вот сдается мне, что из-за джита и не только он может и во многих других местах отстать. А тут только и слышно что диферамбы его спер производительности без оглядки на задачи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
eao197,
E>Уважаемые коллеги, обсуждающие, как аналогичные задачи можно успешно решать за счет очередей сообщений и пулов потоков. Мне кажется, вы недооцениваете одной важной вещи, которую предоставляет поход Erlang-а. Если упустить ее из виду, то очередь сообщений действительно может успешно использоваться (равно как и язык ассемблера в умелых руках). Разница всего лишь в цене и в возможностях.
Точно! Только хотел написать n0name2-у, что обычно предметная область допускает некоторую "естественную" декомпозию. И если подходить к решению задачи неестественно (проще говоря, через зад), то предел сложности начнёт надвигаться гораздо быстрее (это такая сложность, что сколько бабла не вкладывай, довести решение до конца будет невозможно).
Мне сразу вспоминается пункт из диссертации Джо Армстронга, когда постановка задачи предполагала естественное решение в 6 процессов на соединение, но тогдашний эрланг не тянул получающееся итоговое количество потоков, и они вынуждены были сильно усложнить обслуживание соединения, сократив до 2-х (или 3-х) процессов на соединение. Усложнение решения конечно же тянет за собой усложнение тестирования (причём суперпропорционально) и поддержки. А, надо сказать, поддержка больших систем — это вполне самостоятельный проект, и отнюдь не дешёвый.
Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
Ну ответ-то собственно прост как три копейки: weblogic подошла вплотную к пределу сложности, и теперь если начать работать напильничком, то эта работа (даже для такой денежной фирмочки как BEA) рискует никогда не закончиться. Потому вот только "кенгурятники" (напр. soap) навешивают и тряпочкой протирают для создания товарного вида.
Почему Виста имеет хороший аппетит и так долго не выходила? По той же самой причине. Windows вплотную подошла к пределу сложности и дальнейшее развитие будет только как расширение функционала преимущественно _внешним_ образом.
Этот кажущийся отход от темы на самом деле не отход, а скорее поднятие точки зрения чуть выше, потому что технические возможности, человеческие возможности и наличные ресурсы (бабло и время) взаимно влияют друг на друга и чем больше масштаб систем, тем больше влияние.
E>Вот как-то так. Или я что-то не правильно про Erlang понял?
Да в общем-то даже сами создатели не поняли, чего сделали. Хотели как всегда, а получилось лучше.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Точно! Только хотел написать n0name2-у, что обычно предметная область допускает некоторую "естественную" декомпозию. И если подходить к решению задачи неестественно (проще говоря, через зад), то предел сложности начнёт надвигаться гораздо быстрее (это такая сложность, что сколько бабла не вкладывай, довести решение до конца будет невозможно).
Все верно. Не вопрос. Только вот хороший SMP scheduler user-level потоков тоже весьма непростая задача. Вообще говоря, не более простая чем довести стоимость kernel thread до стоимости lightweight thread. Ее пытались решить в Sun Solaris (LWP), плюнули и перешли на 1:1 модель. Пытались сделать в JVM несколько раз — глючило и в реальной жизни все было не так здорово. Сейчас Erlang работает на SMP в разы медленнее чем на одном ядре (что уже нонсенс для современного железа). Посмотрим, получится у них сделать более стабильный и правильный SMP scheduler. У меня есть сомнения, не вижу чем тут функциональщина сильно поможет.
LCR>Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
Прости, но вы performance profile делали? Есть большое подозрение что это application тормозит и дело не в weblogic вообще.
n0name2,
LCR>>Так что интересно? Одновременное количество работающих процессов? Пиковая нагрузка? Или время отклика на приоритетное сообщение при максимальной нагрузке?
N>Интересно кол-во запросов, которое может быть обработано в секунду. Т.е. throughput. Под запросом я понимаю — рендеринг web страницы или например в терминах телекома запрос на инициализацию звонка.
Ясно. Глянь ejabberd, eddie, YXA, Tsung.
N>Пока ни одной не искуственно выдуманной задачи я не видел.
Курилка,
К><skipped/>
К>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>><skipped/>
К>>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
LCR>Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
LCR>Кстати, что там Вадлер ответил?
Да ничего интересного:
A tool was produced but I don't think it was publically released; at any
rate it is no longer maintained. More recently, Kostis Sagonas has
produced a more sophisticated type checker for Erlang.
=============перевод=====================
Утилита (речь про type tool, что у Вадлера на сайте) была создана, но я не думаю, что
её зарелизили, в любом случае она больше не поддерживается. В недавнее время, Костис Сагонас
сделал более сложный тайп-чекер для Эрланга (речь про Dialyzer)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
N>>Интересно кол-во запросов, которое может быть обработано в секунду. Т.е. throughput. Под запросом я понимаю — рендеринг web страницы или например в терминах телекома запрос на инициализацию звонка.
LCR>Ясно. Глянь ejabberd, eddie, YXA, Tsung.
erjabberd — вполне себе нормальный сервис, не вопрос. только вот ничего сверхъестественного в его performance benchmarks (2000mess/sec, 7000users) я не вижу. Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>><skipped/>
К>>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
LCR>Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
n0name2,
LCR>>Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
N>Прости, но вы performance profile делали? Есть большое подозрение что это application тормозит и дело не в weblogic вообще.
Хи. А ещё у меня есть подозрение, что 2 GB нынче это не память. В действительности, аргумент работает в обе стороны — можно сказать, что железо неадекватно, а можно сказать, что софт слишком мрачный. Но я бы предпочёл не развивать эту тему... присоединяйся
Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>>Кстати вот интересное письмо Тобиас Линдал ещё написал, где упоминал разрабатываеммый Typer для эрланга (подробней — http://www.it.uu.se/research/group/hipe/papers/typer.pdf)
LCR>Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
F>> Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.
N>Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?
Страница странице рознь
Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
VladD2 wrote: > C>Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они > C>работать будут заметно эффективнее, чем в .NET (не нужен write barrier). > Извини. Меня не интересуют пустые слова. Будут данные, подходи. > А write barrier просто пушинка супротив интерпретатора и динамики.
Ну так я не утверждаю, что сам язык в целом быстрее. Попробуй набросать
мне план проверки производительности именно GC — я могу попробовать его
реализовать.
> C>Ну а JIT — это к GC не относится. > Еще как отностится. Есть две системы с разными проектными решениями. У > одной поколенчатый ЖЦ, возможность модифицировать данные в хипе, > компилирумый код.
GC с поколениями УЖЕ ЕСТЬ в Erlang.
> У второй интерпретация, своя схема ЖЦ, и т.п. Слушать > разглагольствования о теоритическом превосходстве просто нет желания. > Тут можно говорить только о эксперементальном подтвержедении.
А ты сравни теоретическую модель с крутым GC и крутым JITом одновременно.
> C>Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг > C>совершенно из-за этого не подходит. > Ну, вот сдается мне, что из-за джита и не только он может и во многих > других местах отстать. А тут только и слышно что диферамбы его спер > производительности без оглядки на задачи.
Где ты такие видишь? Большинство Erlang'истов вполне понимают
ограничения Erlang'а.
Здравствуйте, Mamut, Вы писали:
M>Страница странице рознь M>Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
Ну, вполне может быть, no silver bullet так сказать. Только что это за мифическая задача — пока никто сформулировать не смог. JSP разумеется изначально в байт код транслируются.
VD>Кстати, подумалось, что для большинства задач реального мира было бы достаточно исползовать и потоки ОС. Все же найти задачу где действительно потребовлось бы запускать 100 и более параллельных потоков (не спящих) не так то просто. А на сотнях потоков все и так будет работать на ура. Учитывая же, что эти потоки скорее всего и так загрузят процессор по самое нехочу можно сказать, что решение будет более чем жизныенным и востребованным.
В рассылке по Эрлангу рассматривался такой вот подход к созданию веб-приложений:
Например, чат. На каждую комнату выделяется один supervisor, каждое подсоединение — отдельный процесс, обмениваются между собой посылкой сообщений. Круто, да? В рамках Эрланга задача тривиальна и для небольших сайтов даже реализуема.
n0name2,
N>Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Интересно. Данные впечатляют, даже если дать скидку на то, что передаваемые сообщения бывают разные и цифры округлены в большую сторону... В-общем, я хочу подробнее разобраться, откуда такой чудо-throughput, и обсудить как-нибудь потом в тематическом форуме.
Курилка,
LCR>>Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
К>В смысле "страшно"?
Тулза вставляет гварды — ограничения на типы — в исходник. Производится глобальная модификация исходника. А если мой файл некорректный (ну там случайно скобку стёр, или вместо тупла список вколотил)? Лучше пусть это делает hipe. Ну или на крайний случай руками.
M>>Страница странице рознь M>>Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
N>Ну, вполне может быть, no silver bullet так сказать. Только что это за мифическая задача — пока никто сформулировать не смог. JSP разумеется изначально в байт код транслируются.
Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
Но вот если это уже будут данные, которые неизвестно откуда берутся (например, из базы), то тут уже все не так однозначно. Потому что сформулировать задачу для такого теста будет очень сложно (потому что неизвестно, согласно каким критериям и что оценивать )
Здравствуйте, Mamut, Вы писали:
M>Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
Java + NIO это совсем не Apache, на 100к юзеров оно не загнется. Думаю, слабо будет порвать Особенно на SMP. Если ты готов сделать benchmark для Yaws, то, можем попробовать.
M>Но вот если это уже будут данные, которые неизвестно откуда берутся (например, из базы), то тут уже все не так однозначно. Потому что сформулировать задачу для такого теста будет очень сложно (потому что неизвестно, согласно каким критериям и что оценивать )
Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
Здравствуйте, n0name2, Вы писали: N>А чем он еще занимается? Ты базу имеешь в виду? Это тоже можно сделать в NIO стиле вполне, но, это не актуально т.к. вся ценность NIO в том, чтобы работать с большим кол-вом клиентов с низкой активностью. Кстати, IIS использует overlapped или нет?
IIS вообще штука очень сложная. В шестерке примерно такая схема работы:
tcpip.sys -> http.sys -> w3wp.exe -> ISAPIx.dll
-> file system
Соответственно, должна быть какая-то очередь в кернел моде (хотя, скорее всего, она сильно ограничена). Насколько я знаю, кернел-моде доступ к файлухе в IIS делается вполне overlapped способом — для статики вообще потребление RAM и CPU близко к нулю. А для динамики решение о диспетчеризации принимает соответствующее расширение ISAPI. В частности, ASP.NET организует свою очередь реквестов и использует для ее разгребания пул потоков вколичестве 25*CpuCount. N>Вообще, я не очень представляю себе современный web сервер с классической моделью 1 клиент : 1 поток OS (или поток из пула).
И правильно делаешь. На самом деле современный web server, имхо, начнет загибаться значительно раньше, чем будет достигнуто системное ограничение по количеству тредов. Просто потому, что tcpip сокеты достаточно дороги, а каждый запрос, стоящий в очереди — это еще и открытое HTTP соединение.
F>> Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор. N>Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?
Как уже было замечено — смотря какую страницу. Я сходу не могу придумать пример, но думаю, что эффективная диспетчеризация может дать выигрышь на некоторых классах задач. Хотя скорее можно ожидать не большей скорости вывода каждой страницы, а увеличения числа обслуженных страниц.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали: M>Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
Боюсь что в таком случае порвет он только поджилки. Потому, что для статики с расширением .jsp будет сформирован готовый респонс, который ляжет в серверный кэш, и всё, что будет после этого мерить тест — скорость доступа web-сервера к JVM. А если у статики расширение .aspx, то я вообще не завидую эрлангу, т.к. она ляжет в кэш режима ядра и сервер будет обслуживать клиентов вообще никогда не переключаясь в user mode.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > Просто потому, что tcpip сокеты достаточно дороги, а каждый > запрос, стоящий в очереди — это еще и открытое HTTP соединение.
Мне вот тут рассказали, что на одном сервере с хорошими серверными
картами (с TCP offloading engine) спокойно держится 30000 соединений (у
них проблема — не хватает номеров портов!).
Сервер, кстати, на чистом С.
> Как уже было замечено — смотря какую страницу. Я сходу не могу придумать > пример, но думаю, что эффективная диспетчеризация /может/ дать выигрышь > на некоторых классах задач. Хотя скорее можно ожидать не большей > скорости вывода каждой страницы, а увеличения числа обслуженных страниц.
ИМХО, подход Эрланга к организации мультитредовых серверных приложений —
самый верный. То есть легкие потоки + умный планировщик в N копиях по
числу процессоров. Просто мне доводилось писать в автоматном стиле,
который, фактически и является единственным разумным вариантом для
легких потоков — и больше писать автоматы я не хочу.
Кстати, я тут узнал (после чтения исходников BEAM), что scheduler в
Erlang знает об affinity для легких потоков, так что может посылать
сообщения в поток на том же процессоре даже без блокировок. То есть, по
сути, посылка сообщения превращается в аналог вызова функции.
Кстати, никто не мешает эту же фичу реализовать в любом другом языке с
легкими потоками (даже если его имя будет начинаться на N).
Sinclair wrote: > Боюсь что в таком случае порвет он только поджилки. Потому, что для > статики с расширением .jsp будет сформирован готовый респонс, который > ляжет в серверный кэш, и всё, что будет после этого мерить тест — > скорость доступа web-сервера к JVM. А если у статики расширение .aspx, > то я вообще не завидую эрлангу, т.к. она ляжет в кэш режима ядра и > сервер будет обслуживать клиентов вообще никогда не переключаясь в user > mode.
Добавить в планы: портировать Erlang в режим ядра.
Кстати, насколько я помню, у Resin'а (еще в 2001-2002) для Java был
специальный ядерный модуль как раз для кэширования.
Кстати, если кому интересно, у того же Резина есть Quercus — реализация
PHP на Java под которой работает уже достаточно много программ (phpBB,
myphpadmin, Drupal).
M>>Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
N>Java + NIO это совсем не Apache, на 100к юзеров оно не загнется. Думаю, слабо будет порвать Особенно на SMP. Если ты готов сделать benchmark для Yaws, то, можем попробовать.
Я все никак Эрланг выучит не могу, а тут бенчмарки Как-нибудь потом
M>>Но вот если это уже будут данные, которые неизвестно откуда берутся (например, из базы), то тут уже все не так однозначно. Потому что сформулировать задачу для такого теста будет очень сложно (потому что неизвестно, согласно каким критериям и что оценивать )
N>Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
Увы. Скорее всего нет. Разве что где-нибудь у кого-нибудь разработаны для своих собственных нужд...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
LCR>>>Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
К>>В смысле "страшно"?
LCR>Тулза вставляет гварды — ограничения на типы — в исходник. Производится глобальная модификация исходника. А если мой файл некорректный (ну там случайно скобку стёр, или вместо тупла список вколотил)? Лучше пусть это делает hipe. Ну или на крайний случай руками.
Ты чего-то путаешь:
The basic usage is:
> typer my module.erl
which will read the file and create a new file called my module.ann,
located in the same directory as the original file, that contains the
type signatures for all functions in my module.erl.
Здравствуйте, Mamut, Вы писали:
N>>Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
M>Увы. Скорее всего нет. Разве что где-нибудь у кого-нибудь разработаны для своих собственных нужд...
По идее ODBC драйвера вроде есть, но дело-то в том, что ну для задач Эрланга Оракл особо не нужен, мнезии хватает, хотя иногда люди говорят, что базы получаются большие и перелизают за ограничения на объём, что есть в мнезии.
Здравствуйте, Cyberax, Вы писали:
C>Добавить в планы: портировать Erlang в режим ядра.
Я думаю, что если бы дело обстояло так просто, то в режим ядра портировали бы вообще всё. C>Кстати, насколько я помню, у Resin'а (еще в 2001-2002) для Java был C>специальный ядерный модуль как раз для кэширования.
Гм. Про это я ничего не знаю. Знаю только, что сам IIS начал работать в режиме ядра только в 6й версии. Это в каком году было?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Гм. Про это я ничего не знаю. Знаю только, что сам IIS начал работать в режиме ядра только в 6й версии. Это в каком году было?
Что интересно, когда в линуксе появился ядерный модуль для поддержки http все ржали — апач в ядро и т.д. Модуль, afaik, из линуха давно убрали, но по этому пути решили в MS пойти. Ждём пока уберут?
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Что интересно, когда в линуксе появился ядерный модуль для поддержки http все ржали — апач в ядро и т.д.
А кто, собственно, ржал? ANS>Модуль, afaik, из линуха давно убрали,
afaik, он на месте. ANS>но по этому пути решили в MS пойти. Ждём пока уберут?
Очень я сомневаюсь, что уберут. Производительность уж очень у него хорошо выглядит.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>Добавить в планы: портировать Erlang в режим ядра. > Я думаю, что если бы дело обстояло так просто, то в режим ядра > портировали бы вообще всё.
Я просто думаю, что это никому особо не нужно. Ну получим ускорение раза
в 2 для редких частных случаев, но при этом усложнится вся система и
будет уменьшена надежность.
> C>Кстати, насколько я помню, у Resin'а (еще в 2001-2002) для Java был > C>специальный ядерный модуль как раз для кэширования. > Гм. Про это я ничего не знаю. Знаю только, что сам IIS начал работать в > режиме ядра только в 6й версии. Это в каком году было?
Точно позже.
N>>>Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
M>>Увы. Скорее всего нет. Разве что где-нибудь у кого-нибудь разработаны для своих собственных нужд...
К>По идее ODBC драйвера вроде есть, но дело-то в том, что ну для задач Эрланга Оракл особо не нужен, мнезии хватает, хотя иногда люди говорят, что базы получаются большие и перелизают за ограничения на объём, что есть в мнезии.
Вообще предлагают испольщовать MySQL, а на Mnesia реализовать для него кэш
Здравствуйте, Sinclair, Вы писали:
ANS>>Модуль, afaik, из линуха давно убрали, S>afaik, он на месте. ANS>>но по этому пути решили в MS пойти. Ждём пока уберут? S>Очень я сомневаюсь, что уберут. Производительность уж очень у него хорошо выглядит.
как показывают независимые тесты, ничего там сверхестественного нет. см здесь (Greg — сотридник MS, Luis — адерт Резины).
а по чистому throughput на статическом контенте конечно IIS вообще не решение по сравнению с lighthttpd.
Здравствуйте, n0name2, Вы писали:
N>как показывают независимые тесты, ничего там сверхестественного нет. см здесь (Greg — сотридник MS, Luis — адерт Резины).
Ниче не понял. А где там собственно про сервинг статики и кернел моде? Или ты отвечаешь, не читая? Напомню, что я утверждал, что сомневаюсь в перспективе "убрать" кернел моде из IIS. N>а по чистому throughput на статическом контенте конечно IIS вообще не решение по сравнению с lighthttpd.
Интересное утверждение. Оно базируется на религиозном экстазе или эмпирическом опыте?
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>Я просто думаю, что это никому особо не нужно. Ну получим ускорение раза C>в 2 для редких частных случаев, но при этом усложнится вся система и C>будет уменьшена надежность.
А лично я думаю, что сделать это крайне сложно. В режиме ядра слишком много ограничений, чтобы можно было безболезненно исполнять произвольное приложение. Выигрыш в два раза, кстати, это очень дофига. А для некоторых частных случаев можно было бы и больший получить.
C>Вот нашел по этому доку: http://www.systemvikar.biz/java_tut/hardcore.xtp
А, не, это малополезная штука. Это всего лишь лоадбалансер, который форвардит запросы в JVM, работающие естественно в user mode. В принципе, то же самое делает http.sys.
То, что делает http.sys полезным — это его поддержка кэша и умение работать с файлухой напрямую. Выигрышь на динамических запросах по сравнению с "обычным" IIS практически незаметен.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
N>>>>Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
M>>>Увы. Скорее всего нет. Разве что где-нибудь у кого-нибудь разработаны для своих собственных нужд...
К>>По идее ODBC драйвера вроде есть, но дело-то в том, что ну для задач Эрланга Оракл особо не нужен, мнезии хватает, хотя иногда люди говорят, что базы получаются большие и перелизают за ограничения на объём, что есть в мнезии.
M>Вообще предлагают испольщовать MySQL, а на Mnesia реализовать для него кэш
Вот мне непонятно почему мускул, а тот же постгрес не пользуется популярностью у эрлангеров.
Просто вот слышал не раз факты, что переводят терабайтные базки на постгрес (вон Сони засветилась в этом, допустим, правда линки под рукой нету) с оракла, а вот про MySQL такого не припомню
Здравствуйте, Sinclair, Вы писали:
N>>как показывают независимые тесты, ничего там сверхестественного нет. см здесь (Greg — сотридник MS, Luis — адерт Резины). S>Ниче не понял. А где там собственно про сервинг статики и кернел моде? Или ты отвечаешь, не читая? Напомню, что я утверждал, что сомневаюсь в перспективе "убрать" кернел моде из IIS.
Нет, я не против kernel mode, просто ничего особенного на динамическом контенте из себя IIS не представляет.
N>>а по чистому throughput на статическом контенте конечно IIS вообще не решение по сравнению с lighthttpd. S>Интересное утверждение. Оно базируется на религиозном экстазе или эмпирическом опыте?
Здравствуйте, n0name2, Вы писали:
N>Нет, я не против kernel mode, просто ничего особенного на динамическом контенте из себя IIS не представляет.
IIS как бы сам по себе никакую динамику не предоставляет. Разве что SSI обозвать динамикой. Так что мне не вполне понятен смысл этого утверждения. N>Нет, на тестах здесь и здесь
Во втором бенчмарке IIS вообще отсутствует как класс.
В первом — показывает себя вполне хорошо:
1. Для non-keepalive рвет Апач как тузик грелку и проигрывает lighthttpd 7416:9254 (около 20%)
2. Для keepalive рвет lighttpd примерно вдвое. Проигрывает только TUX и LSWS 2.0 Pro. Что неудивительно, учитвывая принадлежность тестов
3. Тесты — сосут. Для них использовалась ровно одна клиентская машина, что в корне противоречит реальному назначению web-сервера. В частности, для non-keepalive IIS не смог участвовать в большинстве забегов, т.к. посылал нафиг лишние запросы с того же клиента. Смею ожидать, что использование более реалистичной тестовой загрузки (например, раскидать ее по паре сотен IP адресов, а также моделировать клиентский кэш) может показать совсем другие результаты. В частности, keepalive-запрос на один и тот же файл в жизни не встречается вообще никогда, стало быть то, что они называют "Small Static File KeepAlive" — вообще сферический конь в вакууме.
А тебе я посоветую
а) читать более внимательно. Чтобы впредь не аргументировать свои утверждения опровергающей их статистикой.
б) более критически относиться к синтетическим бенчмаркам.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>2. Для keepalive рвет lighttpd примерно вдвое. Проигрывает только TUX и LSWS 2.0 Pro. Что неудивительно, учитвывая принадлежность тестов
Собсно, TUX или lighthttpd — не суть важно, TUX не имеет к LSWS прямого отношения. Возможно, в других условиях IIS себя и покажет, у тебя есть другие данные?
S>А тебе я посоветую S>а) читать более внимательно. Чтобы впредь не аргументировать свои утверждения опровергающей их статистикой.
Спасибо, учту.
S>б) более критически относиться к синтетическим бенчмаркам.
А по другому объективно сложно оценить performance. Обычно как раз те вендоры, у которых самые большие с ним проблемы и апелируют к тому что мол — вот, все это от лукавого, на реальных задачах мы...
Здравствуйте, n0name2, Вы писали:
N>Собсно, TUX или lighthttpd — не суть важно
Ну нифига себе. Мы же все-таки geeks, или блондинки?
N>, TUX не имеет к LSWS прямого отношения. Возможно, в других условиях IIS себя и покажет, у тебя есть другие данные?
Он вроде как уже показал. По сравнению с большинством вебсерверов он работает просто великолепно. Столь популярный, к примеру, Apache даже в этих тестах сливает иису по полной.
TUX, который тебе так понравился — это интегрированный в ядро линукса веб сервер. Т.е подход используется тот же, что и в http.sys. Выигрыш (кстати, опять же незначительный) может быть связан с сотней разных причин — начиная от настроек логгирования, и заканчивая общей архитектурой ОС. Может оказаться, что на dual CPU TUX уйдет в глубокую дупу.
Вот, кстати, старенький benchmark, выполненный ZDNet: http://www.kegel.com/nt-linux-benchmarks.html#web. Обрати внимание на то, как IIS 5.0 (который еще не умел kernel mode!) рвет Tux2.0 на том же железе. S>>б) более критически относиться к синтетическим бенчмаркам. N>А по другому объективно сложно оценить performance. Обычно как раз те вендоры, у которых самые большие с ним проблемы и апелируют к тому что мол — вот, все это от лукавого, на реальных задачах мы...
Ну, дело-то не в вендорах.
Синтетические бенчмарки нельзя трактовать как финальные обещания: реальные запросы гораздо сложнее. Тем не менее, разницу в несколько раз (IIS:Apache 6:1) трудно догнать просто подкрутив условия теста.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Он вроде как уже показал. По сравнению с большинством вебсерверов он работает просто великолепно. Столь популярный, к примеру, Apache даже в этих тестах сливает иису по полной. S>TUX, который тебе так понравился — это интегрированный в ядро линукса веб сервер. Т.е подход используется тот же, что и в http.sys. Выигрыш (кстати, опять же незначительный) может
быть связан с сотней разных причин — начиная от настроек логгирования, и заканчивая общей
Apache он для других целей, в общем, как high performance сервер его мало кто рассматривает. Любят его потому что очень хорошо ведет себя в shared hosting (если свалился один юзерский процесс, то все остальные ничего не заметят и т.д.). Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д.
архитектурой ОС. Может оказаться, что на dual CPU TUX уйдет в глубокую дупу. S>Вот, кстати, старенький benchmark, выполненный ZDNet: S>http://www.kegel.com/nt-linux-benchmarks.html#web. Обрати внимание на то, как IIS 5.0 (который еще не умел kernel mode!) рвет Tux2.0 на том же железе.
Неверные (неполные?) данные в статье. Смотри первоисточник SPEC.org или вот еще, за другой квартал здесь
Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598.
Кстати, там был 4 way сервер, соот-но масштабируется Tux вполне нормально. Есть results для 8 way...
S>Ну, дело-то не в вендорах.
Как раз к MS доверия меньше всего.
S>Синтетические бенчмарки нельзя трактовать как финальные обещания: реальные запросы гораздо сложнее. Тем не менее, разницу в несколько раз (IIS:Apache 6:1) трудно догнать просто подкрутив условия теста.
Здравствуйте, n0name2, Вы писали:
N>Apache он для других целей, в общем, как high performance сервер его мало кто рассматривает. Любят его потому что очень хорошо ведет себя в shared hosting (если свалился один юзерский процесс, то все остальные ничего не заметят и т.д.).
Гм. То же можно сказать об IIS: падение пула ничему не мешает — просто будет выполнен рестарт. N>Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д.
Гм. По-моему, ты просто фатально не в теме. Kernel mode — не большая дырка, чем драйвер tcp/ip. Тебя не пугает, что он исполняется в режиме ядра?
N>Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598.
Ну вот поэтому я и говорю, что бенчмарки бенчмаркам рознь. В статье приведен резульат за 2001 год, на СПЕК — за 2000.
N>Как раз к MS доверия меньше всего.
Ага. С учетом того, что как раз совершенно независимые измерители показывают их превосходство почти надо всем, что шевелится, это просто смешно. Я, кстати, что-то не нашел никаких бенчмарков от MS.
N>Собственно, в 2.6 раза тоже...
Ага. В это я верю легко: IIS 5.0 ты не шибко-то разгонишь. Он должен работать примерно так же позорно, как апач. А вот шестерка сделана совершенно по другому, что и видно из лайтспидовских тестов, на которые ты сослался.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Гм. То же можно сказать об IIS: падение пула ничему не мешает — просто будет выполнен рестарт.
Рестарт чего? Всего IIS?
N>>Плюс безопасность (кстати, kernel mode это дырка та еще) и т.д. S>Гм. По-моему, ты просто фатально не в теме. Kernel mode — не большая дырка, чем драйвер tcp/ip. Тебя не пугает, что он исполняется в режиме ядра?
Все-таки, чем больше тянуть в kernel mode, тем больше вероятность какого-нить buffer overflow и получение хакером неограниченных привелегий.
N>>Tux 1.0 — 4200 попугаев, IIS 5.0 — 1598. S>Ну вот поэтому я и говорю, что бенчмарки бенчмаркам рознь. В статье приведен резульат за 2001 год, на СПЕК — за 2000.
Вообще говоря, странно что результаты не опубликованы в списке доступных на spec.org, например, за 1й квартал 2001г ничего похожего нет. Во-вторых, железо не совсем идентичное. И наконец, там фигурирует некий SWC (aka Scalable Web Cache), исполняемый в режиме ядра.
Кстати, основные приетензии вообще именно к этим тестам в том, что они тестируют полностью закэшированый fileset, поэтому SWC так себя хорошо в них ведет. Tux типа умеет на правильных NIC передавать данные с диска в сеть напрямую.
N>>Как раз к MS доверия меньше всего. S>Ага. С учетом того, что как раз совершенно независимые измерители показывают их превосходство почти надо всем, что шевелится, это просто смешно. Я, кстати, что-то не нашел никаких бенчмарков от MS.
M>>Вообще предлагают испольщовать MySQL, а на Mnesia реализовать для него кэш
К>Вот мне непонятно почему мускул, а тот же постгрес не пользуется популярностью у эрлангеров.
Возможно из-за наличия вменяемого драйвера для мускла? Под постгрес, помню, в мэйллисте кто-то обещал выложить опенсорсную версию разрабатываемого какой-то компанией драйвера, а воз и ныне там, емнип
Sinclair wrote: > C>Я просто думаю, что это никому особо не нужно. Ну получим ускорение раза > C>в 2 для редких частных случаев, но при этом усложнится вся система и > C>будет уменьшена надежность. > А лично я думаю, что сделать это крайне сложно. В режиме ядра слишком > много ограничений, чтобы можно было безболезненно исполнять произвольное > приложение.
А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к
FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем
взаимодействовать без переключения контекста.
> Выигрыш в два раза, кстати, это очень дофига. А для > некоторых частных случаев можно было бы и больший получить.
Может быть.
> C>Вот нашел по этому доку: http://www.systemvikar.biz/java_tut/hardcore.xtp > А, не, это малополезная штука. Это всего лишь лоадбалансер, который > форвардит запросы в JVM, работающие естественно в user mode. В принципе, > то же самое делает http.sys.
Насколько я помню (а я помню плохо) он еще умел кэшировать статический
контент. Может и ошибаюсь.
Здравствуйте, n0name2, Вы писали:
N>erjabberd — вполне себе нормальный сервис, не вопрос. только вот ничего сверхъестественного в его performance benchmarks (2000mess/sec, 7000users) я не вижу. Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе...
Мнэээ... Во-первых, как минимум довольно странно сравнивать message-routing framework с полноценным Jabber-сервером, вам не кажется? Во-вторых, где вы нарыли такие тесты: что же такого ужасного надо сделать с ejabberd'ом, чтобы получить 2kmess/sec x 7k? Для сравнения, при переезде jabber.ru на серверы Яндекса, был произведён ряд тестов. Нагрузка генерилась по следующей схеме: раз в 60 секунд добавляли/удаляли ростер, раз в 10 секунд посылали сообщение, раз в 60 секунд меняли статус, раз в 10 минут перелогинивались. Как легко заметить, только на сообщениях (<message/>) генерился 20kmess/sec и это на ~200k сессий (по 100k на ноду, всего две ноды). Конфигурация ноды: 2xXeon 3ghz 64bit, 8Gb RAM, 2x144gb, 1Gb Ethernet; Debian Sarge.
N>...и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Увеличивать производительность путём добавления процессоров не очень выгодно. Куда проще да и надёжнее добавить ещё одну дешёвую ноду в кластер. Я вообще не вижу большого практического смысла в SMP в кластерном сетевом софте, это же не числодробилка. А для числодробилок Erlang, ессно, не подойдёт.
Здравствуйте, n0name2, Вы писали: N>Рестарт чего? Всего IIS?
Рестарт пула. N>Все-таки, чем больше тянуть в kernel mode, тем больше вероятность какого-нить buffer overflow и получение хакером неограниченных привелегий.
Фатальность buffer overrun слабо зависит от моды, в которой все исполняется. В кернел моде повыше шанс получить BSOD, чем повышение привилегий.
N>Кстати, основные приетензии вообще именно к этим тестам в том, что они тестируют полностью закэшированый fileset, поэтому SWC так себя хорошо в них ведет. Tux типа умеет на правильных NIC передавать данные с диска в сеть напрямую.
А в чем, собственно, претензия? Современный сайт запросто влезет в пару гигов; поэтому именно аккуратное кэширование статики — ключ к успеху.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали: C>А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к C>FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем C>взаимодействовать без переключения контекста.
Проблема в том, что
а) в общем случае приложение может потребовать дофига чего еще
б) насколько я понимаю, банальный бесконечный цикл, полученный по ошибке, приведет в kernel mode к катастрофическим последствиям.
Можно обратиться к экспертам по режиму ядра за комментариями. Насколько я понял, в настоящее время программирование в этом режиме — это путь настоящих самураев. Если окажется, что Erlang обеспечивает как раз те гарантии, которые нужны этому режиму для безопасного исполнения софта, то это даст эрлангу огромные преимущества.
C>Насколько я помню (а я помню плохо) он еще умел кэшировать статический C>контент. Может и ошибаюсь.
The current errata:
POST requests are not handled
Date routines have not yet been implemented
Load-balancing is not yet done
Failure to contact a srun results in a disconnect instead of an error message.
/caucho-status isn't implemented yet.
Caching isn't implemented yet.
Logging isn't implemented yet.
HTTP/1.1 keepalive isn't implemented.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>А нам много и не надо — интерфейс для выделения памяти есть, интерфейс к > C>FS есть, сеть есть. Выигрыш будет за счет того, что с сетью будем > C>взаимодействовать без переключения контекста. > Проблема в том, что > а) в общем случае приложение может потребовать дофига чего еще
Делаем коннектор в userspace, который уже делает что нам нужно — FUSE
так вполне живет. В принципе, это даже можно было бы сделать прозрачно —
некоторые ускоренные модули просто будут работать в режиме ядра, а все
остальное — через коннектор. В общем, http.sys и получится.
> б) насколько я понимаю, банальный бесконечный цикл, полученный по > ошибке, приведет в kernel mode к катастрофическим последствиям.
Нет, к таким же как и в пользовательском — ядерный поток просто
зависнет. Процессор будет занят на 100%, но при желании поток можно
будет убить.
> Можно обратиться к экспертам по режиму ядра за комментариями. Насколько > я понял, в настоящее время программирование в этом режиме — это путь > настоящих самураев.
Ну это если на чистом С без всего.
> Если окажется, что Erlang обеспечивает как раз те > гарантии, которые нужны этому режиму для безопасного исполнения софта, > то это даст эрлангу огромные преимущества.
Собственно говоря, Erlang работает на vxWorks с кучей девяток
стабильности, так что вполне реально.
> C>Насколько я помню (а я помню плохо) он еще умел кэшировать статический > C>контент. Может и ошибаюсь. > The current errata:
C>Собственно говоря, Erlang работает на vxWorks с кучей девяток
не знал... блин как время появится надо будет на наши железки поставить -- народ повеселить и себя показать .
... << RSDN@Home 1.2.0 alpha rev. 655>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, CiViLiS, Вы писали:
C>>Собственно говоря, Erlang работает на vxWorks с кучей девяток CVL> CVL>не знал... блин как время появится надо будет на наши железки поставить -- народ повеселить и себя показать .
M>Опять не вижу проблемы (в Яве). Используем ScheduledThreadPoolExecutor. Если сообщение не отправили, ставим себя же с новым увеличенным delay-ем в executor, удаляя оттуда же свой текущий экзмепляр. Имхо, должно работать.
Для приведенного примера это действительно работает. Но вот мне очень много приходится писать подобного автоматного кода, т.е. кода, который за один раз выполняет маленький шажок и возвращает управление. Я ЗАКОЛЕБАЛСЯ, если честно. Писанина и отладка подобного кода вручную увеличивает сложность на порядок, по моим личным наблюдениям.
Здравствуйте, zinid, Вы писали:
Z>Мнэээ... Во-первых, как минимум довольно странно сравнивать message-routing framework с полноценным Jabber-сервером, вам не кажется? Во-вторых, где вы нарыли такие тесты: что же такого ужасного
Чем они принципиально отличаются, я так и не понял. JMS тоже хранит состояние каждого клиента — какие ему сообщения доставлены, как еще нет и т.д.
Z>надо сделать с ejabberd'ом, чтобы получить 2kmess/sec x 7k? Для сравнения, при переезде jabber.ru на серверы Яндекса, был произведён ряд тестов. Нагрузка генерилась по следующей схеме: раз в 60 секунд добавляли/удаляли ростер, раз в 10 секунд посылали сообщение, раз в 60 секунд меняли статус, раз в 10 минут перелогинивались. Как легко заметить, только на сообщениях (<message/>) генерился 20kmess/sec и это на ~200k сессий (по 100k на ноду, всего две ноды). Конфигурация ноды: 2xXeon 3ghz 64bit, 8Gb RAM, 2x144gb, 1Gb Ethernet; Debian Sarge.
здесь
Z>Увеличивать производительность путём добавления процессоров не очень выгодно. Куда проще да и надёжнее добавить ещё одну дешёвую ноду в кластер. Я вообще не вижу большого практического смысла в SMP в кластерном сетевом софте, это же не числодробилка. А для числодробилок Erlang, ессно, не подойдёт.
Вообще говоря, как правило, разделяемый state все-таки есть. И если его полностью не удается запухнуть на клиента, то он все-таки хранится в общей памяти или размазывается по кластеру.
В этом случае SMP себя ведет гораздо лучше чем большой кластер, да и разработка существенно проще. Плюс, все-таки, современные процы уже меньше чем с 2я ядрами не делают, в по хорошему нужно брать 4х ядерный камень. Причем, это будет гораздо дешевле чем 4е отдельных бокса. В дальнейшем ситуация, судя по всему, будет развиватся именно в этом направлении.
Здравствуйте, eao197, Вы писали:
E>Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.
Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Создать такой процесс и отладить его -- нет проблем, все весьма тривиально. Причем run-time Erlang-а гарантирует, что система не ляжет, даже если в ней одновременно будут крутиться, скажем 500K таких процессов.
G>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Вы делали какие-то тесты? Чем определяется верхний порог?
Здравствуйте, Gaperton, Вы писали:
G>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Зачем вы дезинформируете людей? :) The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.
На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
Здравствуйте, zinid, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Z>Зачем вы дезинформируете людей? The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.
Z>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать?
Здравствуйте, Курилка, Вы писали:
Z>>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596).
К>Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать?
Здравствуйте, Cyberax, Вы писали:
>> б) насколько я понимаю, банальный бесконечный цикл, полученный по >> ошибке, приведет в kernel mode к катастрофическим последствиям. C>Нет, к таким же как и в пользовательском — ядерный поток просто C>зависнет. Процессор будет занят на 100%, но при желании поток можно C>будет убить.
Это в каком ядре? Ни штатный linux ни например freebsd не допускают силовой preemption потоками из top half, а только обработчиками прерываний. Если "при желании" включает в себя вмешательство через DDB или аналог через локальную консоль — да. Но сделать например kill зайдя ssh'ем — не получится.
>> Можно обратиться к экспертам по режиму ядра за комментариями. Насколько >> я понял, в настоящее время программирование в этом режиме — это путь >> настоящих самураев. C>Ну это если на чистом С без всего.
А на других средствах ресурсов больше не будет. Меньше диверсий — да, будет. И если изложить код на каком-то промежуточном языке который будет компилироваться в то что нужно и при этом ещё и следить за аккуратным потреблением всех ресурсов — ok. Но это надо специально конструировать именно под кодирование в режим ядра.
>> Если окажется, что Erlang обеспечивает как раз те >> гарантии, которые нужны этому режиму для безопасного исполнения софта, >> то это даст эрлангу огромные преимущества. C>Собственно говоря, Erlang работает на vxWorks с кучей девяток C>стабильности, так что вполне реально.
netch80 wrote: > Это в каком ядре? Ни штатный linux ни например freebsd не допускают > силовой preemption потоками из top half, а только обработчиками > прерываний.
Linux 2.6 с CONFIG_PREEMPT.
> Если "при желании" включает в себя вмешательство через DDB > или аналог через локальную консоль — да. Но сделать например kill зайдя > ssh'ем — не получится.
Ну да, только через ядерные интерфейсы. Можно и kkill, при желании, сделать.
> C>Собственно говоря, Erlang работает на vxWorks с кучей девяток > C>стабильности, так что вполне реально. > так он же не в ядре работает?
Но с кучей девяток. А от системы особо много ему и не надо.
Здравствуйте, zinid, Вы писали:
Z>Здравствуйте, Gaperton, Вы писали:
G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем.
Z>Зачем вы дезинформируете людей?
Ну забыл несколько ноликов Суть дела это не сильно меняет. Каждый процесс в реальной системе расходует порядка нескольких килобайт памяти. Сколько там написано в документации, про минимум? Так вот, память и возросшие задержки на передачу информации и будут реальным ограничением количества процессов. Современная витруальная машина адекватно держит под сотню тыщ процессов, но 500000 — это уже перебор. А старая машина, на которой работал АХД плохо справлялась и с сотней тысяч, там народ количество процессов поджимал — в мейллисте обсуждали.
Правда, с файберами все еще хуже. Они адресное пространство сожрут быстро, их даже десятки тыщ завести сложно. На 32-х битной машине, конечно.
E>deliver_message( post, recipient )
E>{
E> for(i = 0; i != N; ++i )
E> {
E> result = try_deliver( post, recipient );
E> if( ok != result )
E> {
E> // Если временная проблема доставки, то есть
E> // смысл повторить ее позже.
E> if( can_be_delivered_later( result ) )
E> sleep( (i+1)*TIMEOUT );
E> else
E> // Если SMTP сервера нет или он говорит, что
E> // такого получателя нет, то просто прекращаем
E> // дальнейшие попытки.
E> die( post, recipient, THESE_STUPID_BEES_MAKE_INVALID_HONEY );
E> }
E> else
E> // Сообщение отправлено.
E> die( post, recipient, HAVE_A_NICE_DAY );
E>}
E>
Не верю, что может быть всё так просто и хорошо
Тут где-то подвох! В чём он?
Сразу в глаза бросается, что все входные данные мы копируем. А если там большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, что про Erlang знаю только по наслышке, поэтому может я какие вопросы задаю неправильные
А если надо ещё после завершения такого потока модифицировать разделяемые данные, то как быть?
remark wrote: > Сразу в глаза бросается, что все входные данные мы копируем. А если там > большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, > что про Erlang знаю только по наслышке, поэтому может я какие вопросы > задаю неправильные
Можно не копировать массив, а просто передать на него ссылку. Для
Erlang'а это будет одно и то же.
> А если надо ещё после завершения такого потока модифицировать > разделяемые данные, то как быть?
А у тебя НЕТ разделяемых данных Все разделяемые данные пакуются в
свои процессы.
Здравствуйте, Cyberax, Вы писали:
C>remark wrote: >> Сразу в глаза бросается, что все входные данные мы копируем. А если там >> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >> задаю неправильные C>Можно не копировать массив, а просто передать на него ссылку. Для C>Erlang'а это будет одно и то же.
При посылке сообщений это не так. Даже в рамках одной виртуальной машины при передаче сообщений (ведь об этом речь, так?) копируется все, кроме длинных binaries, которые живут в разделяемом процессами хипе, и управляются подсчетом ссылок. Происходит так потому, что у каждого процесса свой собственный хип, который подбирается, кстати, методом stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. Возможно, в будущем, когда в список стабильных фич попадет shared heap — это изменится.
Stop-and-copy — это, в частности, означает, что хип всегда занимает в два раза больше памяти, чем необходимо для хранения данных. А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
В рамках нескольких виртуальных машин, понятное дело, копируется все и всегда. Через сокет передается.
Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо.
Здравствуйте, Gaperton, Вы писали:
G>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут.
Gaperton wrote: > C>Можно не копировать массив, а просто передать на него ссылку. Для > C>Erlang'а это будет одно и то же. > При посылке сообщений это не так. Даже в рамках одной виртуальной машины > при передаче сообщений (ведь об этом речь, так?) копируется все, кроме > длинных binaries, которые живут в разделяемом процессами хипе, и > управляются подсчетом ссылок. Происходит так потому, что у каждого > процесса свой собственный хип, который подбирается, кстати, методом > stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. > Возможно, в будущем, когда в список стабильных фич попадет shared heap — > это изменится.
Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга,
там сейчас стало можно использовать общий хип.
Здравствуйте, Cyberax, Вы писали:
>> Возможно, в будущем, когда в список стабильных фич попадет shared heap — >> это изменится. C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, C>там сейчас стало можно использовать общий хип.
Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она включена по дефолту в последнем релизе, или ее можно включать "в экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные модули или там еще какую-нибудь фигню, типа поддержки SMP, которая замедляет наши программы в 10 раз?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, Gaperton, Вы писали:
G>>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных.
ANS>Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут.
Из-за разницы в алгоритмах stop-and-copy и mark-and-sweep. Разница здесь — memorymanagement.org
Суть stop-and-copy в переливании живых из одного хипа в другой, и обратно. Мертвые убиваются одним махом вместе с одним из двух хипов... Мое соображение было основано на том, что в ситуации, когда выделения памяти нет, stop-and-copy все равно занят постоянным копированием из одного хипа в другой. Следовательно, у тебя на ровном месте появляются тормоза, пропорциональные размеру выделенной памяти. Далее. В Эрланге сборщик мусора с двумя поколениями. Понятное дело — долгоживущих и короткоживущих. Следовательно, если у нас будет много часто меняющихся данных в одном процессе — это для нас плохо.
Знаешь, я тут подумал — а все фигня, на самом деле все не так. В худшем случае получим только перерасход памяти, но тормозов получить не должны. Сборщик-то инкрементальный, следовательно он будет просто реже пробегаться по хипу при его росте. Отсюда и потенциальный перерасход. Гхм, а перерасход памяти — это у нас увеличенный свопфайл, и опять тормоза
Gaperton wrote: > C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, > C>там сейчас стало можно использовать общий хип. > Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она > включена по дефолту в последнем релизе, или ее можно включать "в > экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные > модули или там еще какую-нибудь фигню, типа поддержки SMP, которая > замедляет наши программы в 10 раз?
Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см.
файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен
быть построен с --enable-shared-heap).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
C>>remark wrote: >>> Сразу в глаза бросается, что все входные данные мы копируем. А если там >>> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >>> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >>> задаю неправильные C>>Можно не копировать массив, а просто передать на него ссылку. Для C>>Erlang'а это будет одно и то же.
G>При посылке сообщений это не так. Даже в рамках одной виртуальной машины при передаче сообщений (ведь об этом речь, так?) копируется все, кроме длинных binaries, которые живут в разделяемом процессами хипе, и управляются подсчетом ссылок. Происходит так потому, что у каждого процесса свой собственный хип, который подбирается, кстати, методом stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. Возможно, в будущем, когда в список стабильных фич попадет shared heap — это изменится.
Показания расходятся
Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение.
Как это будет выглядеть и что будет копироваться?
G>Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо.
Я не пугаюсь Я хочу понять, это тривиальный размен производительности на удобную модель программирования, или тут что-то глубже и интереснее.
Здравствуйте, remark, Вы писали:
R>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>Как это будет выглядеть и что будет копироваться?
Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все.
На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>>Как это будет выглядеть и что будет копироваться?
G>На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии.
А как бы такая задача решалась на Erlang и в стиле Erlang? Ну так в двух словах.
G>Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все.
Может я опять с неправильной стороны смотрю. Но.
1. Всё же придётся иметь 100000 копий большой структуры?
2. При том, что она у всех рабочих потоков будет одинаковой?
3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро.
4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро.
Здравствуйте, Cyberax, Вы писали:
C>Gaperton wrote: >> C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, >> C>там сейчас стало можно использовать общий хип. >> Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она >> включена по дефолту в последнем релизе, или ее можно включать "в >> экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные >> модули или там еще какую-нибудь фигню, типа поддержки SMP, которая >> замедляет наши программы в 10 раз? C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен C>быть построен с --enable-shared-heap).
Я перед НГ эту тему поднимал в эрлангквесчнз (здесь), разделяемый хип замочили как неэффективный, оставили только гибридный, когда шарятся только пересылаемые данные
Здравствуйте, remark, Вы писали:
R>Может я опять с неправильной стороны смотрю. Но. R>1. Всё же придётся иметь 100000 копий большой структуры? R>2. При том, что она у всех рабочих потоков будет одинаковой?
Если структура большая, то никто ее копий в каждом процессе иметь не будет. Ее сложат в распределенную базу данных mnesia. Об остальном позаботится mnesia.
R>3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро.
Быстро — это сколько?
R>4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро.
Курилка wrote: > C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. > C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен > C>быть построен с --enable-shared-heap). > Я перед НГ эту тему поднимал в эрлангквесчнз (здесь > <http://forum.trapexit.org/viewtopic.php?t=7092>), разделяемый хип > замочили как неэффективный, оставили только гибридный, когда шарятся > только пересылаемые данные
Это, кстати, должно быть даже лучше. Shared в исходниках все еще есть —
просто его по умолчанию выключили.
Здравствуйте, Cyberax, Вы писали:
C>Курилка wrote: >> C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. >> C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен >> C>быть построен с --enable-shared-heap). >> Я перед НГ эту тему поднимал в эрлангквесчнз (здесь >> <http://forum.trapexit.org/viewtopic.php?t=7092>), разделяемый хип >> замочили как неэффективный, оставили только гибридный, когда шарятся >> только пересылаемые данные C>Это, кстати, должно быть даже лучше.
О том и речь, хотя это определяется приложением, если пересылки сообщений мало, и сообщения мелкие, то традиционный подход может быть лучше. C>Shared в исходниках все еще есть — C>просто его по умолчанию выключили.
Дак и об этом режиме в документации тоже нифига нет, какое-то секретное знание получается
)
)
На самом деле он просто удовлетворяет ряду условий:
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Если нам не помогут, то мы тоже никого не пощадим.
1.2.0 alpha rev. 655
), то почему бы не проставить везде нужные гварды, не скомпилировать hipe (хотя под Дебианом может уже) и не запустить с опцией -hybrid?
не так-то и просто использовать. Куда проще разделить на процессы, потоки и т.д. и т.п. 
и 
. Есть без картинок замеры, но, подтверждают что такая софтина как AsyncWeb совершенно нормально работает с тысячами и десятками тысяч клиентов одновременно.
