| 1 2 3 4 5 6 7 8 |
| Re[4]: Erlang avalanche | |
| От: | Курилка | ||
| Дата: | 20.12.06 07:01 |
| Здравствуйте, zinid, Вы писали: Z>Здравствуйте, Gaperton, Вы писали: G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем. Z>Зачем вы дезинформируете людей? Z>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596). Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать? |
| Re[5]: Erlang avalanche | |
| От: | Константин | ||
| Дата: | 20.12.06 09:51 | ||
| Оценка: | 1 (1) | ||
| Здравствуйте, Курилка, Вы писали: Z>>На самом деле основная проблема Erlang'а на 32-битной системе — ограничение на размер кучи в 1699221830 байт (OTP-5596). К>Это куча, из которой стэки под все процессы выделяются? Не подскажешь, где о таких подробностях почитать? Что-то есть в документации |
| Re[33]: Erlang avalanche | |
| От: | netch80 | ||
| Дата: | 20.12.06 10:45 |
| Здравствуйте, Cyberax, Вы писали: >> б) насколько я понимаю, банальный бесконечный цикл, полученный по >> ошибке, приведет в kernel mode к катастрофическим последствиям. C>Нет, к таким же как и в пользовательском — ядерный поток просто C>зависнет. Процессор будет занят на 100%, но при желании поток можно C>будет убить. Это в каком ядре? Ни штатный linux ни например freebsd не допускают силовой preemption потоками из top half, а только обработчиками прерываний. Если "при желании" включает в себя вмешательство через DDB или аналог через локальную консоль — да. Но сделать например kill зайдя ssh'ем — не получится. >> Можно обратиться к экспертам по режиму ядра за комментариями. Насколько >> я понял, в настоящее время программирование в этом режиме — это путь >> настоящих самураев. C>Ну это если на чистом С без всего. А на других средствах ресурсов больше не будет. Меньше диверсий — да, будет. И если изложить код на каком-то промежуточном языке который будет компилироваться в то что нужно и при этом ещё и следить за аккуратным потреблением всех ресурсов — ok. Но это надо специально конструировать именно под кодирование в режим ядра. >> Если окажется, что Erlang обеспечивает как раз те >> гарантии, которые нужны этому режиму для безопасного исполнения софта, >> то это даст эрлангу огромные преимущества. C>Собственно говоря, Erlang работает на vxWorks с кучей девяток C>стабильности, так что вполне реально. так он же не в ядре работает? |
| Re[34]: Erlang avalanche | |
| От: | Cyberax | ||
| Дата: | 20.12.06 15:01 |
| netch80 wrote: > Это в каком ядре? Ни штатный linux ни например freebsd не допускают > силовой preemption потоками из top half, а только обработчиками > прерываний. Linux 2.6 с CONFIG_PREEMPT. > Если "при желании" включает в себя вмешательство через DDB > или аналог через локальную консоль — да. Но сделать например kill зайдя > ssh'ем — не получится. Ну да, только через ядерные интерфейсы. Можно и kkill, при желании, сделать. > C>Собственно говоря, Erlang работает на vxWorks с кучей девяток > C>стабильности, так что вполне реально. > так он же не в ядре работает? Но с кучей девяток. А от системы особо много ему и не надо. Posted via RSDN NNTP Server 2.1 beta Sapienti sat! |
| Re[4]: Erlang avalanche | |
| От: | Gaperton | ||
| Дата: | 22.12.06 16:08 |
| Здравствуйте, zinid, Вы писали: Z>Здравствуйте, Gaperton, Вы писали: G>>Найн. Не все так радужно. В системе Эрланг (на 32-х разрядной машине) не может крутится более примерно 262ххх. Я бы при дизайне системы ограничил количество одновременно живущих процессов раумным числом в десятки тысяч — до примерно одной сотни тысяч. На практике — это создает не много проблем. Z>Зачем вы дезинформируете людей? Ну забыл несколько ноликов Правда, с файберами все еще хуже. Они адресное пространство сожрут быстро, их даже десятки тыщ завести сложно. На 32-х битной машине, конечно. |
| Re[2]: В чём подвох? | |
| От: | remark | ||
| Дата: | 01.01.07 11:04 |
| Здравствуйте, eao197, Вы писали: E>
Не верю, что может быть всё так просто и хорошо Тут где-то подвох! В чём он? Сразу в глаза бросается, что все входные данные мы копируем. А если там большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, что про Erlang знаю только по наслышке, поэтому может я какие вопросы задаю неправильные А если надо ещё после завершения такого потока модифицировать разделяемые данные, то как быть? Вобщем, что-то тут нечисто |
| Re[3]: В чём подвох? | |
| От: | Cyberax | ||
| Дата: | 02.01.07 03:33 |
| remark wrote: > Сразу в глаза бросается, что все входные данные мы копируем. А если там > большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, > что про Erlang знаю только по наслышке, поэтому может я какие вопросы > задаю неправильные Можно не копировать массив, а просто передать на него ссылку. Для Erlang'а это будет одно и то же. > А если надо ещё после завершения такого потока модифицировать > разделяемые данные, то как быть? А у тебя НЕТ разделяемых данных свои процессы. Posted via RSDN NNTP Server 2.1 beta Sapienti sat! |
| Re[4]: В чём подвох? | |
| От: | Gaperton | ||
| Дата: | 04.01.07 10:10 | ||
| Оценка: | 1 (1) | ||
| Здравствуйте, Cyberax, Вы писали: C>remark wrote: >> Сразу в глаза бросается, что все входные данные мы копируем. А если там >> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >> задаю неправильные C>Можно не копировать массив, а просто передать на него ссылку. Для C>Erlang'а это будет одно и то же. При посылке сообщений это не так. Stop-and-copy — это, в частности, означает, что хип всегда занимает в два раза больше памяти, чем необходимо для хранения данных. А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных. В рамках нескольких виртуальных машин, понятное дело, копируется все и всегда. Через сокет передается. Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо. |
| Re[5]: В чём подвох? | |
| От: | Andrei N.Sobchuck | ||
| Дата: | 04.01.07 10:24 |
| Здравствуйте, Gaperton, Вы писали: G>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных. Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут. Я ненавижу Hibernate! |
| Re[5]: В чём подвох? | |
| От: | Cyberax | ||
| Дата: | 04.01.07 14:09 |
| Gaperton wrote: > C>Можно не копировать массив, а просто передать на него ссылку. Для > C>Erlang'а это будет одно и то же. > При посылке сообщений это не так. Даже в рамках одной виртуальной машины > при передаче сообщений (ведь об этом речь, так?) копируется все, кроме > длинных binaries, которые живут в разделяемом процессами хипе, и > управляются подсчетом ссылок. Происходит так потому, что у каждого > процесса свой собственный хип, который подбирается, кстати, методом > stop-and-copy, а не mark-and-sweep, о чем где-то тут рядом писали. > Возможно, в будущем, когда в список стабильных фич попадет shared heap — > это изменится. Это уже изменилось там сейчас стало можно использовать общий хип. Posted via RSDN NNTP Server 2.0 Sapienti sat! |
| Re[6]: В чём подвох? | |
| От: | Gaperton | ||
| Дата: | 04.01.07 19:02 |
| Здравствуйте, Cyberax, Вы писали: >> Возможно, в будущем, когда в список стабильных фич попадет shared heap — >> это изменится. C>Это уже изменилось C>там сейчас стало можно использовать общий хип. Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она включена по дефолту в последнем релизе, или ее можно включать "в экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные модули или там еще какую-нибудь фигню, типа поддержки SMP, которая замедляет наши программы в 10 раз? |
| Re[6]: В чём подвох? | |
| От: | Gaperton | ||
| Дата: | 04.01.07 19:18 |
| Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Здравствуйте, Gaperton, Вы писали: G>>А также, это означает тормоза при большом объеме аллокированных данных. Особливо — большого объема короткоживущих данных. ANS>Это почему? Время сборки во многом зависит от объёма живых. Короткоживущие же быстро помрут. Из-за разницы в алгоритмах stop-and-copy и mark-and-sweep. Разница здесь — memorymanagement.org Суть stop-and-copy в переливании живых из одного хипа в другой, и обратно. Мертвые убиваются одним махом вместе с одним из двух хипов... Мое соображение было основано на том, что в ситуации, когда выделения памяти нет, stop-and-copy все равно занят постоянным копированием из одного хипа в другой. Следовательно, у тебя на ровном месте появляются тормоза, пропорциональные размеру выделенной памяти. Далее. В Эрланге сборщик мусора с двумя поколениями. Понятное дело — долгоживущих и короткоживущих. Следовательно, если у нас будет много часто меняющихся данных в одном процессе — это для нас плохо. Знаешь, я тут подумал — а все фигня, на самом деле все не так. В худшем случае получим только перерасход памяти, но тормозов получить не должны. Сборщик-то инкрементальный, следовательно он будет просто реже пробегаться по хипу при его росте. Отсюда и потенциальный перерасход. Гхм, а перерасход памяти — это у нас увеличенный свопфайл, и опять тормоза |
| Re[7]: В чём подвох? | |
| От: | Cyberax | ||
| Дата: | 04.01.07 19:24 |
| Gaperton wrote: > C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, > C>там сейчас стало можно использовать общий хип. > Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она > включена по дефолту в последнем релизе, или ее можно включать "в > экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные > модули или там еще какую-нибудь фигню, типа поддержки SMP, которая > замедляет наши программы в 10 раз? Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен быть построен с --enable-shared-heap). Posted via RSDN NNTP Server 2.0 Sapienti sat! |
| Re[5]: В чём подвох? | |
| От: | remark | ||
| Дата: | 04.01.07 19:46 |
| Здравствуйте, Gaperton, Вы писали: G>Здравствуйте, Cyberax, Вы писали: C>>remark wrote: >>> Сразу в глаза бросается, что все входные данные мы копируем. А если там >>> большой массив, я буду должен его 100000 раз раскопировать? Сразу скажу, >>> что про Erlang знаю только по наслышке, поэтому может я какие вопросы >>> задаю неправильные C>>Можно не копировать массив, а просто передать на него ссылку. Для C>>Erlang'а это будет одно и то же. G>При посылке сообщений это не так. Показания расходятся Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. Как это будет выглядеть и что будет копироваться? G>Все эти вещи (особенности технологии) надо знать, и учитывать при проектировании систем. Пугаться их не надо. Я не пугаюсь |
| Re[6]: В чём подвох? | |
| От: | Gaperton | ||
| Дата: | 05.01.07 12:54 |
| Здравствуйте, remark, Вы писали: R>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>Как это будет выглядеть и что будет копироваться? Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все. На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии. |
| Re[7]: В чём подвох? | |
| От: | remark | ||
| Дата: | 08.01.07 10:55 |
| Здравствуйте, Gaperton, Вы писали: G>Здравствуйте, remark, Вы писали: R>>Можно на примере: Допустим та же система рассылки почты, о которой писал eao197. Есть некие глобальные настройки программы (типа адрес почтового сервера, там могут содержаться и некие очень большие списки). Эти настройки необходимы для процесса отправки почты как входные данные, и эти же настройки могут одновременно меняться из GUI. И допустим после успешной/неуспешной отправки надо некоторые "разделяемые" данные обновить (типа статистики). Вобщем типичное серверное приложение. R>>Как это будет выглядеть и что будет копироваться? G>На самом деле, это другая модель программирования. Она не специфична для Эрланга — она называется actor model. Прочитать про нее можно в википедии. А как бы такая задача решалась на Erlang и в стиле Erlang? Ну так в двух словах. G>Это слишком простой пример, чтобы словить на нем проблемы производительности. Обрати внимание, что в твоем примере данные меняются в одном месте (один источник) а используются в разных. Соотвественно, процесс, в котором данные изменились (а меняются они редко — через гуи) просто рассылает изменения процессам-потребителям, которые данные используют. И все. Может я опять с неправильной стороны смотрю. Но. 1. Всё же придётся иметь 100000 копий большой структуры? 2. При том, что она у всех рабочих потоков будет одинаковой? 3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро. 4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро. |
| Re[8]: В чём подвох? | |
| От: | Курилка | ||
| Дата: | 09.01.07 10:37 |
| Здравствуйте, Cyberax, Вы писали: C>Gaperton wrote: >> C>Это уже изменилось Я тут кидал ссылку на новый дизайн GC для Эрланга, >> C>там сейчас стало можно использовать общий хип. >> Круто. На самом деле круто. Тока вопрос. Это стабильная фича? Она >> включена по дефолту в последнем релизе, или ее можно включать "в >> экспериментальных целях на свой страх и риск?" Ну, типа, как виртуальные >> модули или там еще какую-нибудь фигню, типа поддержки SMP, которая >> замедляет наши программы в 10 раз? C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен C>быть построен с --enable-shared-heap). Я перед НГ эту тему поднимал в эрлангквесчнз (здесь), разделяемый хип замочили как неэффективный, оставили только гибридный, когда шарятся только пересылаемые данные |
| Re[8]: В чём подвох? | |
| От: | Gaperton | ||
| Дата: | 09.01.07 11:32 |
| Здравствуйте, remark, Вы писали: R>Может я опять с неправильной стороны смотрю. Но. R>1. Всё же придётся иметь 100000 копий большой структуры? R>2. При том, что она у всех рабочих потоков будет одинаковой? Если структура большая, то никто ее копий в каждом процессе иметь не будет. Ее сложат в распределенную базу данных mnesia. Об остальном позаботится mnesia. R>3. Придётся отсылать и обрабатывать 100000 сообщений? Не верю, что это может быть быстро. Быстро — это сколько? R>4. Заменить разом большую, сложную иерархическую структуру легко, а вот написать механизм вычленения из неё изменений и применения отдельных изменений в новой структуре... не хотелось бы этим заниматься. И по любому это тоже будет не особо быстро. А мне не надо очень быстро. Мне надо вот так: http://www.sics.se/~joe/apachevsyaws.html |
| Re[9]: В чём подвох? | |
| От: | Cyberax | ||
| Дата: | 09.01.07 16:01 |
| Курилка wrote: > C>Сейчас лень смотреть. В исходниках эмулятора в R11B-2 уже он есть (см. > C>файл ggc.c), запускается опцией -shared у интерпретатора erl (он должен > C>быть построен с --enable-shared-heap). > Я перед НГ эту тему поднимал в эрлангквесчнз (здесь > <http://forum.trapexit.org/viewtopic.php?t=7092>), разделяемый хип > замочили как неэффективный, оставили только гибридный, когда шарятся > только пересылаемые данные Это, кстати, должно быть даже лучше. Shared в исходниках все еще есть — просто его по умолчанию выключили. Posted via RSDN NNTP Server 2.0 Sapienti sat! |
| Re[10]: В чём подвох? | |
| От: | Курилка | ||
| Дата: | 10.01.07 06:49 |
| Здравствуйте, 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>просто его по умолчанию выключили. Дак и об этом режиме в документации тоже нифига нет, какое-то секретное знание получается |
| 1 2 3 4 5 6 7 8 |