Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, m.aksenov, Вы писали:
I>Мы говоли не про то, как надо писать, а сравнивали возможные проблемы из за некорректного кода. I>Дедлок == некорректный код. Я привел его аналог, т.е. некорректное решения в модели акторов.
Это, конечно, понятно. Просто именно для эрланга концептуальный дизайн систем прописан очень четко в OTP Design Principles
(http://www.erlang.org/documentation/doc-5.6/pdf/design_principles.pdf) и такой проблемы быть не должно.
Конечно, если она возникнет, то геморроя будет не меньше, но концептуально акторы проще нативной многопоточности
с разделяемым состоянием, а это большой плюс для быстрой разработки, результат которой, вероятно, будет более прожорливым, но будет.
И чтобы два раза не вставать, так как в топике были замечания про ВМ эрланга — ее можно запускать напрямую на Xen: http://erlangonxen.org/
Здравствуйте, Ikemefula, Вы писали:
F>>а ты не примешивай поиск дедлока к этой задаче. I>В этой задаче нет именно дедлока, потому ничего подмешать не получится
а коммент про поиск проблемы как раз о дедлоках. так шта не подмешивай.
I>Поведение как раз понятно — если не освободят, значит все потоки будут зависать на нём. Юзер-реквесты будут повисать или отваливаться по таймауту. Что касается юзер-реквестов то тоже самое будет скажем в эрланге если накосячить с пулом.
не знаю, как там можно накосячить, но отваливаться они должны и так. by design.
I>У акторов есть одно большое преимущество — они масштабируются. Тупо потому, что не прибиты гвоздями к кусочку памяти, как мутекс.
как ты их вообще сравниваешь? они же принципиально разные. это как сравнивать variadic templates с циклом while.
да, они масштабируются. но они и работают по-другому принципу.
подобие их mailbox'а я делал и на плюсах. и это проще, чем строить в голове схему взаимодействия через мутехи.
Здравствуйте, neFormal, Вы писали:
I>>У акторов есть одно большое преимущество — они масштабируются. Тупо потому, что не прибиты гвоздями к кусочку памяти, как мутекс.
F>как ты их вообще сравниваешь? они же принципиально разные. это как сравнивать variadic templates с циклом while.
Очень просто. Одну и то же можно сделать и так и так. Соответсвенно проблема, например, общий ресурс, проявит себя в обоих случаях и можно сравнить издержки и тд.
Здравствуйте, Ikemefula, Вы писали:
I>>>У акторов есть одно большое преимущество — они масштабируются. Тупо потому, что не прибиты гвоздями к кусочку памяти, как мутекс. F>>как ты их вообще сравниваешь? они же принципиально разные. это как сравнивать variadic templates с циклом while. I>Очень просто. Одну и то же можно сделать и так и так. Соответсвенно проблема, например, общий ресурс, проявит себя в обоих случаях и можно сравнить издержки и тд.
так решение таких масштабов, как введение акторов, принимается на основе того, что находится вокруг проблемы.
оно более комплексное, чем использование примитивов синхронизации.
В среднем решения на эрланге достаточно хороши. Прична достаточно простая — в эрланг переходят уже после того, как получен внятный опыт работы на каком либо стеке, а то и двух-трёх да в разных областях.
Налиие гайдлайнов не означет следование этим гайдлайнам. Новички в программировании, если берутся за модель акторов, воротят такое, что в страшном сне не приснится.
"проблемы быть не должно" — любой проблемы быть не должно. А факты говорят о том, что способности некоторых людей создавать проблемы на ровном месте всегда сильно недооценены.
Здравствуйте, Ikemefula, Вы писали:
I>В среднем решения на эрланге достаточно хороши. Прична достаточно простая — в эрланг переходят уже после того, как получен внятный опыт работы на каком либо стеке, а то и двух-трёх да в разных областях. I>Налиие гайдлайнов не означет следование этим гайдлайнам. Новички в программировании, если берутся за модель акторов, воротят такое, что в страшном сне не приснится.
Разумеется, но есть люди, которые и без многопоточности ухитряются в одном методе делать четыре вложенных цикла и из внутреннего манипулировать счетчиком наружного. От этого не спасает
ни один язык программирования, только желание сделать лучше и опыт (и верхний мозг, пожалуй). Впрочем, об этом вы и писали. В таких ситуациях я вижу выход только в постоянном обучении
новых людей в команде, и пока соответствующую компетенцию не покажет — к продакшен коду, использующему этот набор концепций, не подпускать. Мечты-мечты...
Ikemefula,
F>>на haskell можно писать игры хоть используя чистый opengl, хоть цепляясь к существующим движкам.
I>Покажи хотя бы одну прибыльную игру, которая написана на Хаскеле.
Ну вот, начало уже положено, неплохо. Судя по репу, такой подход мало кто сможет юзать, FRP всё таки не самая простая в освоении вещь даже для людей с опытом.
Ikemefula,
I>Ну вот, начало уже положено, неплохо. Судя по репу, такой подход мало кто сможет юзать, FRP всё таки не самая простая в освоении вещь даже для людей с опытом.
Да, FRP требует некоторого времени и усилий, чтобы его грокнуть. Это, считай, константные вложения, которые окупаются со временем, и чем сложнее и больше проект, тем больше профит. Например, в js разработке до народа довольно быстро дошло то, что управлять неявным состоянием в асинхронном контексте самоубийство, даже термин появился Callback Hell. Такая же ситуация под мобилками и на бэкенде, если мы пользуемся например Play framework или библиотеками типа RX.
Потому, на мой взгляд, основная движуха в сторону FRP идет из js (как фронтенд, так и нода), мобилок и scala/java/c# (асинхронные бэкенды).
У меня, кстати, есть вопрос к знатокам ФП:
Как в ФП-стиле грамотно (в смысле — красиво и эффективно) решить задачу вычисления трансцендентной функции разложением в ряд Тейлора (или иной бесконечный ряд) с заданной точностью? В императивном стиле алгогитм решения этой задачи сводится к одному циклу while — красиво, понятно, легко верифицируемо и эффективно с точки зрения расхода процессорного времени и памяти. А в функциональном стиле как?
Функции высшего порядка типа foldl тут не подходят, так как они представляют собой примитивно-рекурсивные функции (аналог цикла for в ), а вычисление ряда с заданной точностью — это уже частично рекурсивная функция!
Здравствуйте, alexis_ch, Вы писали:
_>У меня, кстати, есть вопрос к знатокам ФП: _>Как в ФП-стиле грамотно (в смысле — красиво и эффективно) решить задачу вычисления трансцендентной функции разложением в ряд Тейлора (или иной бесконечный ряд) с заданной точностью? В императивном стиле алгогитм решения этой задачи сводится к одному циклу while — красиво, понятно, легко верифицируемо и эффективно с точки зрения расхода процессорного времени и памяти. А в функциональном стиле как?
_>Функции высшего порядка типа foldl тут не подходят, так как они представляют собой примитивно-рекурсивные функции (аналог цикла for в ), а вычисление ряда с заданной точностью — это уже частично рекурсивная функция!
Можно же просто сделать функцию с хвостовой рекурсией. Она дополнительно стек есть не будет. Вот, например на Clojure:
(defn sint
[x eps]
(loop [term 1.0
sum 0.0
i 1]
(if-not (< term eps)
(let [t (* term (/ x i))]
(recur
t
(cond
(= (mod i 4) 1) (+ sum t)
(= (mod i 4) 3) (- sum t)
:else sum)
(inc i)))
sum)))
Т.к. JVM оптимизировать хвостовые вызовы не умеет, то используется конструкция loop. Ее можно считать функцией, потому что recur вызывает loop с новыми значениями аргументов. Возможно, есть более красивое решение, но такое вполне в функциональном стиле.
Здравствуйте, alexis_ch, Вы писали:
_>Как в ФП-стиле грамотно (в смысле — красиво и эффективно) решить задачу вычисления трансцендентной функции разложением в ряд Тейлора (или иной бесконечный ряд) с заданной точностью? В императивном стиле алгогитм решения этой задачи сводится к одному циклу while — красиво, понятно, легко верифицируемо и эффективно с точки зрения расхода процессорного времени и памяти. А в функциональном стиле как?
_>Функции высшего порядка типа foldl тут не подходят, так как они представляют собой примитивно-рекурсивные функции (аналог цикла for в ), а вычисление ряда с заданной точностью — это уже частично рекурсивная функция!
Как уже ответили, хвостовая рекурсия с аккумулятором, особенно для энергичных языков типа F#. В случае ленивого Haskell есть свои нюансы.
I>P.S. soft realtime это для тех кастомеров, которые позволяют себе лапшу на уши вешать.
У Erlang'а есть гарантии soft-realtime и мы это наблюдаем в реальности, что бы нам не говорили теоретики, не знающие нифига ни про ФП в целом, ни про Erlang в частности.
M>>В эрланге, что характерно, это (нативные треды — М.) основное направление развития.
I>Ты пойми простую вещи — я не слежу за Эрлангом и про "нативные потоки доступные из Эрланга" узнал от тебя в этом треде.
Я понял простую вещь: ты нифига не знаешь про Erlang, но несешь про него тонны чуши с умным видом.
M>>Единственное, что есть в якобы приоритетном направлении — это нативные процессы в дальнем роадмапе, среди прочих пунктов. Завязывай нести чушь о вещах, в которых ты не разбираешься.
I>Ты наверное любой текст понимаешь только так, как тебе хочется.
Вот твой текст: «В эрланге, что характерно, это (нативные треды — М.) основное направление развития.» Как его понимать иначе, кроме как то, что в нем написано: бредятина про то, что в Erlang'е нативные треды — приоритетное направление развития.
Здравствуйте, Mamut, Вы писали:
M>У Erlang'а есть гарантии soft-realtime и мы это наблюдаем в реальности, что бы нам не говорили теоретики, не знающие нифига ни про ФП в целом, ни про Erlang в частности.
Вобщем, как обычно, от тебя ни одного внятного ответа.
Ни один рантайм в принципе не способен дать гарантий больше, чем может выдать ядро ОС.
В качестве упражнения можешь подумать на тему, как именно эрланг обеспечит отклик если ОС его не гарантирует.
Здравствуйте, Mamut, Вы писали:
I>>Ты наверное любой текст понимаешь только так, как тебе хочется.
M>Вот твой текст: «В эрланге, что характерно, это (нативные треды — М.) основное направление развития.» Как его понимать иначе, кроме как то, что в нем написано: бредятина про то, что в Erlang'е нативные треды — приоритетное направление развития.
Правильно. Судя по всему, для тебя это новость. Проснись, Эрланг уже сто лет как перестал быть однопоточным. Если ты расскажешь, как без нативных потоков внятно загрузить многоядерные процессоры, особенно для приложений с интенсивным IO, я отдам тебе свою ЗП
Ты наверное не в курсе, что большая часть вызовов у ОС в основном блокирующие. Внятно с ними можно работать только одним способом — создавать нативные потоки. Более того, если ты хочешь использовать IOCP, унутре снова надо создавать всякие потоки. Хочешь загрузить внятно все ядра — нужно снова создавать нативные потоки.
Собственно, рантайм Эрланга именно это и делает, при чем много лет — создаёт унутре нативные потоки по требованию. Скажем, простейший случай — N ядер у проца. Эрланг создаст, условно, N потоков, в каждом запустит шедулер, через который будут выполняться его процессы, которых, кстати может быть больше числа ядер. Далее, если ктото делает IOCP или блокирующий вызов — будет использоваться пул нативных потоков для таких дел.
В своё время в Джаве этой кухни не осилили и им пришлось выбросить зеленые потоки на помойку. А вот в Эрланге это стало основным приоритетом. Собтсвенно, Эрланг взлетел во многом благодаря многоядерным процессорам и вот этой своей архитектуре.
Одно из двух — или ты слишком долго общался с Шериданом, или хронически не читаешь, ибо "умнее всех"
Здравствуйте, Ikemefula, Вы писали:
M>>У Erlang'а есть гарантии soft-realtime и мы это наблюдаем в реальности, что бы нам не говорили теоретики, не знающие нифига ни про ФП в целом, ни про Erlang в частности.
I>Вобщем, как обычно, от тебя ни одного внятного ответа. I>Ни один рантайм в принципе не способен дать гарантий больше, чем может выдать ядро ОС. I>В качестве упражнения можешь подумать на тему, как именно эрланг обеспечит отклик если ОС его не гарантирует.
Так у Эрланга все по-честному: soft realtime — это когда говорят "мы постараемся как можно больше запросов обработать быстро, но никаких гарантий не даем, дедлайны будут нарушаться, и это нормально". И вот именно это отсутствие жестких гарантий Эрланг успешно гарантирует.
Здравствуйте, D. Mon, Вы писали:
I>>Вобщем, как обычно, от тебя ни одного внятного ответа. I>>Ни один рантайм в принципе не способен дать гарантий больше, чем может выдать ядро ОС. I>>В качестве упражнения можешь подумать на тему, как именно эрланг обеспечит отклик если ОС его не гарантирует.
DM>Так у Эрланга все по-честному: soft realtime — это когда говорят "мы постараемся как можно больше запросов обработать быстро, но никаких гарантий не даем, дедлайны будут нарушаться, и это нормально". И вот именно это отсутствие жестких гарантий Эрланг успешно гарантирует.
То что ты сказал, на гарантии вообще не похоже Мамут утверждает наличие некоторых гарантии. Эрланг скорее гарантирует не сам софт-реалтайм, а гарантирует, что не ухудшит гарантии ОС, которая пригодна для этого софт-реалтайма.
Отсюда ясно, что если среднего времени отклика ОС достаточно для нашей задачи, а цена ошибки из за сбоя невелика, то Эрланг гарантирует корректную работу при внятной реализации софта.
Нужно разделять систему реального времени и ОС реального времени. Когда говорят про софт-реалтайм, это первое. А гарантии — второе. Если цена ошибки невелика, то вместо ОС РВ можно взять даже винду и это взлетит.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
