Здравствуйте, thesz, Вы писали:
T>>>А упало из-за чего? Ошибка-то была out of memory, и поэтому тупой ботлнек ничем не отличается от утечки памяти. К>>Сергей, ну прям как-то изредка, но "удивляюсь" твоим некоторым репликам (несмотря на всё остальное, что ты пишешь). К>>Неужто сложно отличить причину и следствие? К>>Есть источники вызовов, они событий генерят больше, чем может обработать получающая сторона. Естественно это приводит к переполнению мейлбокса и как следствие out of memory.
T>Haskell: "Есть создатель ленивого списка, получающая сторона вычисляет его не весь и не всегда. Естественно, это приводит к накоплению отложенных вычислений и, как следствие, out of memory."
T>C++: тысячи сценариев, поэтому я не могу выбрать, "...и, как следствие — out of memory."
T>Java/C#: "Вместо отбрасывания уже обработанных препятствий, мы добавляли их в список — а вдруг они встретятся ещё раз. Естественно, это приводило к накоплению препятствий в списке и, как следствие, к out of memory."
T>Теперь мы знаем сценарий для Эрланга. Я не вижу, чем принципиально он отличается от сценариев для других ЯП.
Отличие очень простое — в Haskell, Java/C# и даже, поверь, в C++ OOM не зависит от машины, на которой выполняем программу. Т.е. OOM происходит либо всегда и сразу, либо всегда после некоторого время работы, либо всегда на некоторых данных/нагрузках, но НЕ на этой машине происходит, а на этой — нет.
Я думаю, что все согласятся, что такая ошибка — это так скажем не самая тривиальная и прозрачная ошибка. Ну т.е. если я, например, периодически добавляю элементы в список, и никогда из него не удаляю, то понятно, что рано или поздно память кончится (это более-менее очевидно большинству вменяемых разработчиков). Ошибка с логгером не такая тривиальная.
Вообще очень интересный момент. Фактически такие асинхронные системы вносят дополнительный вид портируемости — портируемость между разным кол-вом ядер/процессоров. Т.е. раньше мы грубо говоря имели — работает на x86, не работает на Alpha; потом — работает под Windows, не работает под Linux; тут же — работает на 2 ядрах, не работает на 8 ядрах. Т.е. будьте добры тестировать на различных кол-вах ядер, автоматической портируемости между различным кол-вом ядер Эрланг не предоставляет (пока не будет автоматического контроля загрузки).
Fine granular parallelism (Erlang threads or fibers)
Чем сегодняшние процессы не "threads or fibers"? Что принципиального они хотят добавить сверх процессов?
Фактически, насколько я понимаю, Эрланговский процесс тривиально использовать как future/task/thread.
Здравствуйте, thesz, Вы писали:
T>>>Как ты собираешься их преодолевать, если собираешься? На что можно напороться при их преодолении? Связаны ли эти трудности с наличием id процесса и его жесткой привязкой к id машины? M>>Не все сразу. В Roadmap'е они обещают к этом прийти
T>Это не распараллеливание одного процесса Эрланга на несколько процессоров, а миграция.
T>Или я чего-то пропустил?
Здравствуйте, thesz, Вы писали:
MK>>Ну и вообще Erlang конечно не идеал. Но со многими проблемами которые в нем уже решены или решаются, разработчикам других систем еще только предстоит столкнуться.
T>Либо не столкнуться вообще.
T>С тем же, что Эрланг не идеал, я согласиться не могу. По-моему, Эрланг — это нечто большее.
Мне вот интересно, Сергей, откуда столько неприязни к Erlang.
Вроде как неплохой вариант продвижения идей функционального программирования в массы.
Это какие-то личные счеты или ты считаешь его вредной технологией, грязным прыщом на чистом и ленивом теле ФП
Я еще понимаю было бы противостояние какое-то между ними.
Но ведь выбор совсем не между Erlang и Haskell в большинстве проектов, к сожалению.
MK>>>Ну и вообще Erlang конечно не идеал. Но со многими проблемами которые в нем уже решены или решаются, разработчикам других систем еще только предстоит столкнуться. T>>Либо не столкнуться вообще. T>>С тем же, что Эрланг не идеал, я согласиться не могу. По-моему, Эрланг — это нечто большее. MK>Мне вот интересно, Сергей, откуда столько неприязни к Erlang.
(бурчит про себя) С шутками при температуре стоит завязывать, всё равно никто не понимает.
MK>Вроде как неплохой вариант продвижения идей функционального программирования в массы. MK>Это какие-то личные счеты или ты считаешь его вредной технологией, грязным прыщом на чистом и ленивом теле ФП
Это утверждение, или вопрос? Составлено, как вопрос, а вопросительного знака нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Mikl Kurkov, Вы писали:
MK>>По-моему обычный рабочий момент. Подсистема SMP находится в активной разработке и разработчики и не скрывают что там есть узкие места и имеют четкий план по их оптимизации.
R>А что будет не на SMP подсистеме, а в обычном режиме? Как будет решаться перегрузка?
Это задача разработчика так спроектировать систему, чтобы в ней не было узких мест в виде единственного процесса на который все остальные шлют сообщения. Все средства в Erlang для этого есть. С тем же логгером можно завести несколько логов для разных подсистем. В принципе можно менять приоритет процессов, но не думаю что это правильный ход.
...
MK>>Собственно один из вариантов решения проблемы описывает сам автор в своем блоге — использовать синхронный режим логгирования, регулируя нагрузку на процесс логгера.
R>Как затычка пойдёт, как решение — наврядли. Фактически мы просто сравняли скорость работы самых быстрых процессов со скоростью работы самых медленных процессов, т.е. свели нашу 8-ми ядерную систему к одноядерной (и на этом одном ядре работает логгер). R>Вообще хорошего решения тут и нет, т.к. проблема в пользовательском приложении, которое имеет несбалансированную централизованную обработку; вопрос только насколько хорошо или плохо мы сможем это заткнуть. Вариант вообще ничего не делать будет приводить к периодическим падениям системы; вариант с синхронным взаимодействием будет приводить к излишней пессимизации производительности системы. Наилучшей затычкой мне кажется нечно среднее, т.е. в обычном режиме идёт асинхронная работа (т.о. быстрые процессы могут работать с наибольшей скоростью), и *только* при возникновении серьёзных перегрузок *выборочные* процессы, которые участвуют в перегрузке переходят в полу-синхронный режим (и не так жестко, что разрешается только одно сообщение от данного процесса, а балансирование между high watermark и low watermark).
Cинхронный режим disk_log и реализует похожий подход. Т.е. в общем случае сообщения обрабатываются мгновенно, просто добавляясь в очередь
и потом сбрасываются на диск. Можно реализовать и более сложные подходы на прикладном уровне.
MK>>Ну и вообще Erlang конечно не идеал. Но со многими проблемами которые в нем уже решены или решаются, разработчикам других систем еще только предстоит столкнуться.
R>Не знаю, о каких ещё вещах идёт речь, но то, что описано в статье уже как более 15 лет решено в системах, которые целелись на SMP сразу (Cilk 1994 год, libasync-smp 2003 год и др.).
R>...
R>Т.е. фактически пока они просто пытаются догнать мировой опыт накопленный в SMP мире. Никаких передовых вещей я тут пока не вижу. R>Передовыми вещами я как раз бы назвал решение проблемы с перегрузками в системе, cohort-scheduling, cache-awareness scheduling, NUMA-awareness scheduling, system structure awareness scheduling и т.д.
R>В частности, например, проблему перегрузок мы с eao197 решаем в вялотекущем режиме уже как полтора года, т.ч. это Эрлангу придётся нас доганять R>http://www.rsdn.ru/forum/message/2624991.aspx
Ну что ж я искренне рад за индустрию, раз все проблемы с разработкой приложений под многоядерные процессоры решены аж 15 лет назад.
А Erlang я думаю догонит в конце концов.
27-01-2009, remark <38267@users.rsdn.ru> пишет: > Отличие очень простое — в Haskell, Java/C# и даже, поверь, в C++ OOM > не зависит от машины, на которой выполняем программу. Т.е. OOM > происходит либо всегда и сразу, либо всегда после некоторого время > работы, либо всегда на некоторых данных/нагрузках, но НЕ на этой > машине происходит, а на этой — нет.
А мне почему то кажется что если 10 потоков набивают очередь, и только 1
ее разгребает, то точно такая же проблема возникнет в программе любом
языке.
При увеличении кол-во ядер 10 потоков расходятся по ним и начинают
набивать очередь быстрее. Конечно и разгребающий поток получает больше
процессорного времени, но по-моему ситуация совершенно общая для всех
языков...
Здравствуйте, thesz, Вы писали:
MK>>>>Ну и вообще Erlang конечно не идеал. Но со многими проблемами которые в нем уже решены или решаются, разработчикам других систем еще только предстоит столкнуться. T>>>Либо не столкнуться вообще. T>>>С тем же, что Эрланг не идеал, я согласиться не могу. По-моему, Эрланг — это нечто большее. MK>>Мне вот интересно, Сергей, откуда столько неприязни к Erlang.
T>(бурчит про себя) С шутками при температуре стоит завязывать, всё равно никто не понимает.
Ну я рад, что ошибся. Скорейшего выздоровления тебе!
MK>>Вроде как неплохой вариант продвижения идей функционального программирования в массы. MK>>Это какие-то личные счеты или ты считаешь его вредной технологией, грязным прыщом на чистом и ленивом теле ФП
T>Это утверждение, или вопрос? Составлено, как вопрос, а вопросительного знака нет.
Похоже это проблема отсутствия строгой типизации с выводом в естественном языке.
MK>>>Мне вот интересно, Сергей, откуда столько неприязни к Erlang. T>>(бурчит про себя) С шутками при температуре стоит завязывать, всё равно никто не понимает. MK>Ну я рад, что ошибся. Скорейшего выздоровления тебе!
MK>>>Вроде как неплохой вариант продвижения идей функционального программирования в массы. MK>>>Это какие-то личные счеты или ты считаешь его вредной технологией, грязным прыщом на чистом и ленивом теле ФП T>>Это утверждение, или вопрос? Составлено, как вопрос, а вопросительного знака нет. MK>Похоже это проблема отсутствия строгой типизации с выводом в естественном языке.
Здравствуйте, remark, Вы писали:
R>Отличие очень простое — в Haskell, Java/C# и даже, поверь, в C++ OOM не зависит от машины, на которой выполняем программу. Т.е. OOM происходит либо всегда и сразу, либо всегда после некоторого время работы, либо всегда на некоторых данных/нагрузках, но НЕ на этой машине происходит, а на этой — нет. R>Я думаю, что все согласятся, что такая ошибка — это так скажем не самая тривиальная и прозрачная ошибка. Ну т.е. если я, например, периодически добавляю элементы в список, и никогда из него не удаляю, то понятно, что рано или поздно память кончится (это более-менее очевидно большинству вменяемых разработчиков). Ошибка с логгером не такая тривиальная. R>Вообще очень интересный момент. Фактически такие асинхронные системы вносят дополнительный вид портируемости — портируемость между разным кол-вом ядер/процессоров. Т.е. раньше мы грубо говоря имели — работает на x86, не работает на Alpha; потом — работает под Windows, не работает под Linux; тут же — работает на 2 ядрах, не работает на 8 ядрах. Т.е. будьте добры тестировать на различных кол-вах ядер, автоматической портируемости между различным кол-вом ядер Эрланг не предоставляет (пока не будет автоматического контроля загрузки).
правильно сказано, что такая проблема может в любой языка возникнуть и Erlang тут наравне с остальными.
Бо'льшая проблема здесь в том, что в Erlang-е (поправьте если я не прав) нет возможности определить количество сообщений в канале, т.е. фактически нельзя каким-либо надежным способом предотвратить описанную ситуация, опеределить что идет переполнение очереди.
R>
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, remark, Вы писали:
R>>Отличие очень простое — в Haskell, Java/C# и даже, поверь, в C++ OOM не зависит от машины, на которой выполняем программу. Т.е. OOM происходит либо всегда и сразу, либо всегда после некоторого время работы, либо всегда на некоторых данных/нагрузках, но НЕ на этой машине происходит, а на этой — нет. R>>Я думаю, что все согласятся, что такая ошибка — это так скажем не самая тривиальная и прозрачная ошибка. Ну т.е. если я, например, периодически добавляю элементы в список, и никогда из него не удаляю, то понятно, что рано или поздно память кончится (это более-менее очевидно большинству вменяемых разработчиков). Ошибка с логгером не такая тривиальная. R>>Вообще очень интересный момент. Фактически такие асинхронные системы вносят дополнительный вид портируемости — портируемость между разным кол-вом ядер/процессоров. Т.е. раньше мы грубо говоря имели — работает на x86, не работает на Alpha; потом — работает под Windows, не работает под Linux; тут же — работает на 2 ядрах, не работает на 8 ядрах. Т.е. будьте добры тестировать на различных кол-вах ядер, автоматической портируемости между различным кол-вом ядер Эрланг не предоставляет (пока не будет автоматического контроля загрузки).
RRM>здесь
правильно сказано, что такая проблема может в любой языка возникнуть и Erlang тут наравне с остальными.
Да, правильно. Но тут есть 2 момента. Во-первых, я (как видимо и thesz судя по примерам) имел в виду "традиционное" примернение языка (в противном случае можно сказать, что любой язык общего назначения подвержен всем проблемам). Во-вторых, если я в С реализую агентную систему, то не составляет труда и прикрутить предотвращение перегрузок (в Эрланге же такой возможности нет).
RRM>Бо'льшая проблема здесь в том, что в Erlang-е (поправьте если я не прав) нет возможности определить количество сообщений в канале, т.е. фактически нельзя каким-либо надежным способом предотвратить описанную ситуация, опеределить что идет переполнение очереди.
Здравствуйте, Mikl Kurkov, Вы писали:
MK>>>По-моему обычный рабочий момент. Подсистема SMP находится в активной разработке и разработчики и не скрывают что там есть узкие места и имеют четкий план по их оптимизации.
R>>А что будет не на SMP подсистеме, а в обычном режиме? Как будет решаться перегрузка?
MK>Это задача разработчика так спроектировать систему, чтобы в ней не было узких мест в виде единственного процесса на который все остальные шлют сообщения.
К сожалению, это не возможно сделать эффективно, если нет соотв. ран-тайм поддержки от среды выполнения.
MK>Все средства в Erlang для этого есть.
Какие?
MK>С тем же логгером можно завести несколько логов для разных подсистем.
Что назвать системой, что подсистемой, а что надсистемой — вопрос исключительно терминологии. Создаём логгер для подсистемы, теперь переходим на уровень подсистем и возвращаемся к разбитому корыту — по логгеру на систему.
MK>В принципе можно менять приоритет процессов, но не думаю что это правильный ход.
Я не думаю, что на основании приоритетов рантайм будет пессимизировать производительность, т.е. тормозить процессы на других процессорах.
MK>>>Собственно один из вариантов решения проблемы описывает сам автор в своем блоге — использовать синхронный режим логгирования, регулируя нагрузку на процесс логгера.
R>>Как затычка пойдёт, как решение — наврядли. Фактически мы просто сравняли скорость работы самых быстрых процессов со скоростью работы самых медленных процессов, т.е. свели нашу 8-ми ядерную систему к одноядерной (и на этом одном ядре работает логгер). R>>Вообще хорошего решения тут и нет, т.к. проблема в пользовательском приложении, которое имеет несбалансированную централизованную обработку; вопрос только насколько хорошо или плохо мы сможем это заткнуть. Вариант вообще ничего не делать будет приводить к периодическим падениям системы; вариант с синхронным взаимодействием будет приводить к излишней пессимизации производительности системы. Наилучшей затычкой мне кажется нечно среднее, т.е. в обычном режиме идёт асинхронная работа (т.о. быстрые процессы могут работать с наибольшей скоростью), и *только* при возникновении серьёзных перегрузок *выборочные* процессы, которые участвуют в перегрузке переходят в полу-синхронный режим (и не так жестко, что разрешается только одно сообщение от данного процесса, а балансирование между high watermark и low watermark).
MK>Cинхронный режим disk_log и реализует похожий подход. Т.е. в общем случае сообщения обрабатываются мгновенно, просто добавляясь в очередь MK>и потом сбрасываются на диск. MK>Можно реализовать и более сложные подходы на прикладном уровне.
Я не считаю синхронную обработку особо хорошей для производительности/масштабируемости.
А какие ещё варианты можно реализовать?
MK>>>Ну и вообще Erlang конечно не идеал. Но со многими проблемами которые в нем уже решены или решаются, разработчикам других систем еще только предстоит столкнуться.
R>>Не знаю, о каких ещё вещах идёт речь, но то, что описано в статье уже как более 15 лет решено в системах, которые целелись на SMP сразу (Cilk 1994 год, libasync-smp 2003 год и др.).
R>>...
R>>Т.е. фактически пока они просто пытаются догнать мировой опыт накопленный в SMP мире. Никаких передовых вещей я тут пока не вижу. R>>Передовыми вещами я как раз бы назвал решение проблемы с перегрузками в системе, cohort-scheduling, cache-awareness scheduling, NUMA-awareness scheduling, system structure awareness scheduling и т.д.
R>>В частности, например, проблему перегрузок мы с eao197 решаем в вялотекущем режиме уже как полтора года, т.ч. это Эрлангу придётся нас доганять R>>http://www.rsdn.ru/forum/message/2624991.aspx
MK>Ну что ж я искренне рад за индустрию, раз все проблемы с разработкой приложений под многоядерные процессоры решены аж 15 лет назад. MK>А Erlang я думаю догонит в конце концов.
Конечно же, нет. Далеко не все проблемы решены. Решены только некоторые базовые. Именно их и догоняет Эрланг.
Более сложные проблемы — это как раз предотвращение перегрузок, более умные алгоритма шедулинга (принимающие во внимание аппаратную платформу, но в то же время не нагружающие этим конечного пользователя), ран-тайм позволяющий значительно более мелкую гранулярность (порядка десятков тактов) и т.д.
правильно сказано, что такая проблема может в любой языка возникнуть и Erlang тут наравне с остальными.
R>Да, правильно. Но тут есть 2 момента. Во-первых, я (как видимо и thesz судя по примерам) имел в виду "традиционное" примернение языка (в противном случае можно сказать, что любой язык общего назначения подвержен всем проблемам). Во-вторых, если я в С реализую агентную систему, то не составляет труда и прикрутить предотвращение перегрузок (в Эрланге же такой возможности нет).
Поклёп
RRM>>Бо'льшая проблема здесь в том, что в Erlang-е (поправьте если я не прав) нет возможности определить количество сообщений в канале, т.е. фактически нельзя каким-либо надежным способом предотвратить описанную ситуация, опеределить что идет переполнение очереди.
R>Именно.
Ну сколько ни говори "халва" во рту слаще не станет.
А если ближе к делу — рядом
приведена ссылка, где как раз делается проверка длины очереди.
Может всёж стоит сначала проверить прежде чем делать голословные заявления?
А то как-то уж очень некрасиво выходит и очень смахивает на разжигание флейма.
Здравствуйте, remark, Вы писали:
R>Более сложные проблемы — это как раз предотвращение перегрузок, более умные алгоритма шедулинга (принимающие во внимание аппаратную платформу, но в то же время не нагружающие этим конечного пользователя), ран-тайм позволяющий значительно более мелкую гранулярность (порядка десятков тактов) и т.д.
Позволю заметить, что как раз с гранулярностью у Эрланга всё довольно неплохо, т.к. в нём она базируется на редукциях. Насчёт числа тактов оценки не дам, ну и, конечно, "убить" ВМ тоже можно (некоторое время тут был пост про паттерн-матчинг для нереально больших строк, хотя его тоже можно побить на редукции, но практического смысла мало).
правильно сказано, что такая проблема может в любой языка возникнуть и Erlang тут наравне с остальными.
R>>Да, правильно. Но тут есть 2 момента. Во-первых, я (как видимо и thesz судя по примерам) имел в виду "традиционное" примернение языка (в противном случае можно сказать, что любой язык общего назначения подвержен всем проблемам). Во-вторых, если я в С реализую агентную систему, то не составляет труда и прикрутить предотвращение перегрузок (в Эрланге же такой возможности нет).
К>Поклёп
Что именно?
RRM>>>Бо'льшая проблема здесь в том, что в Erlang-е (поправьте если я не прав) нет возможности определить количество сообщений в канале, т.е. фактически нельзя каким-либо надежным способом предотвратить описанную ситуация, опеределить что идет переполнение очереди.
R>>Именно.
К>Ну сколько ни говори "халва" во рту слаще не станет. К>А если ближе к делу — рядом
приведена ссылка, где как раз делается проверка длины очереди. К>Может всёж стоит сначала проверить прежде чем делать голословные заявления? К>А то как-то уж очень некрасиво выходит и очень смахивает на разжигание флейма.
По ссылке — мой пост и ничего про проверку длины очереди в Эрланге...
По поводу проверки длины очереди в Эрланг:
RRM>>...в Erlang-е ... нет возможности определить количество сообщений в канале
Здравствуйте, Курилка, Вы писали:
R>>Более сложные проблемы — это как раз предотвращение перегрузок, более умные алгоритма шедулинга (принимающие во внимание аппаратную платформу, но в то же время не нагружающие этим конечного пользователя), ран-тайм позволяющий значительно более мелкую гранулярность (порядка десятков тактов) и т.д.
К>Позволю заметить, что как раз с гранулярностью у Эрланга всё довольно неплохо, т.к. в нём она базируется на редукциях.
Если исходить из маркетинговых материалов, то сейчас у любой системы хорошо с мелкой гранулярностью
Однако, как показывает практика, это не так. У многих систем, которые "поддерживают" и даже "призывают" к мелкой гранулярности в реальности размер элемента работы должен быть не меньше ~10'000 тактов. Поэтому при попытке использовать натуральную мелкую гранулярность во многих задачах производительность убивается в #Q$@%#%.
Хотя про редукции я в них не слышал... Редукции чего?.. Вообще звучит интересно... есть какие-нибудь ссылки?..
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, remark, Вы писали:
R>>>Здравствуйте, RailRoadMan, Вы писали:
RRM>>>>здесь
правильно сказано, что такая проблема может в любой языка возникнуть и Erlang тут наравне с остальными.
R>>>Да, правильно. Но тут есть 2 момента. Во-первых, я (как видимо и thesz судя по примерам) имел в виду "традиционное" примернение языка (в противном случае можно сказать, что любой язык общего назначения подвержен всем проблемам). Во-вторых, если я в С реализую агентную систему, то не составляет труда и прикрутить предотвращение перегрузок (в Эрланге же такой возможности нет).
К>>Поклёп
R>Что именно?
Ниже
RRM>>>>Бо'льшая проблема здесь в том, что в Erlang-е (поправьте если я не прав) нет возможности определить количество сообщений в канале, т.е. фактически нельзя каким-либо надежным способом предотвратить описанную ситуация, опеределить что идет переполнение очереди.
R>>>Именно.
К>>Ну сколько ни говори "халва" во рту слаще не станет. К>>А если ближе к делу — рядом
приведена ссылка, где как раз делается проверка длины очереди. К>>Может всёж стоит сначала проверить прежде чем делать голословные заявления? К>>А то как-то уж очень некрасиво выходит и очень смахивает на разжигание флейма.
R>По ссылке — мой пост и ничего про проверку длины очереди в Эрланге... R>По поводу проверки длины очереди в Эрланг: R>
RRM>>>...в Erlang-е ... нет возможности определить количество сообщений в канале
R>Обратных утверждений я тут пока не видел.
Блин, свои посты тоже проверять надо
Ссылка была дана давно здесь
приведена ссылка, где как раз делается проверка длины очереди. К>>>Может всёж стоит сначала проверить прежде чем делать голословные заявления? К>>>А то как-то уж очень некрасиво выходит и очень смахивает на разжигание флейма.
R>>По ссылке — мой пост и ничего про проверку длины очереди в Эрланге... R>>По поводу проверки длины очереди в Эрланг: R>>
RRM>>>>...в Erlang-е ... нет возможности определить количество сообщений в канале
R>>Обратных утверждений я тут пока не видел.
К>Блин, свои посты тоже проверять надо К>Ссылка была дана давно здесь
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>>>Более сложные проблемы — это как раз предотвращение перегрузок, более умные алгоритма шедулинга (принимающие во внимание аппаратную платформу, но в то же время не нагружающие этим конечного пользователя), ран-тайм позволяющий значительно более мелкую гранулярность (порядка десятков тактов) и т.д.
К>>Позволю заметить, что как раз с гранулярностью у Эрланга всё довольно неплохо, т.к. в нём она базируется на редукциях.
R>Если исходить из маркетинговых материалов, то сейчас у любой системы хорошо с мелкой гранулярностью
Давай попробуем без "левых" замечаний? Марткетинг булшит всем известен, но мы ведь не о нём? R>Однако, как показывает практика, это не так. У многих систем, которые "поддерживают" и даже "призывают" к мелкой гранулярности в реальности размер элемента работы должен быть не меньше ~10'000 тактов. Поэтому при попытке использовать натуральную мелкую гранулярность во многих задачах производительность убивается в #Q$@%#%. R>Хотя про редукции я в них не слышал... Редукции чего?.. Вообще звучит интересно... есть какие-нибудь ссылки?..
Ссылки искать надо, стопудово в доках на эрланг.ком описано.
Суть там проста: язык функциональный, поэтому всё вычисление сводится к редукциям вызовов функций (если это правильно по-русски, конечно) плюс ещё немного "ерунды" аля арифметические действия, паттерн-матчинг (ну и BIFы тоже). Естественно что до 1 редукции сводить глупо, поэтому по дефолту стоит "интервал" в 100 редукций (и по-моему опциями можно задать своё значение этого параметра).
. К>>Ты её не читал я так понимаю?
R>По какой именно ссылке? В Pdf'ке там вроде только про оптимизации ран-тайма. А в блоге так вроде только про полностью синхронный режим...
Толку от синхронного режима, если мы в диск и функции форматирования уткнёмся? Ссылка:
logger_mqlen(undefined) -> 0;
logger_mqlen(Pid) ->
case process_info(Pid, message_queue_len) of
{message_queue_len, Val} when is_integer(Val) -> Val;
_ -> 0
end.
