Здравствуйте, Mamut, Вы писали:
M>Это все равно приближено описание «что сделать».
Ровно через то, как это сделать. Вообще-то фибоначчи можно считать и совсем по-другому, например, экспоненцированием матрицы, что для больших n гораздо оптимальнее при эффективной реализации умножения. Но вряд ли сейчас существует среда, которая по описанию "что сделать", найдёт самый быстрый способ это сделать. Именно поэтому в любом существующем языке описывается именно "как сделать", пусть и с разной степенью детализации (в пределах догадливости компилятора) и разными допусками (например, с возможностью обрабатывать элементы контейнера в произвольном порядке).
M>Еще один Шеридан с абстрактными заявлениями про скорость.
Гм, а вот это уже переход на личности, причём третьих лиц. По существу, в чём возражения против того, что прямое отображение функциональных парадигм на современное железо часто приводит к неэффективному коду? И что с этим приходится бороться малоестественными приёмами типа переделки рекурсии в хвостовую?
Здравствуйте, Mamut, Вы писали:
M>Да. Неэффективный код может быть. Да, например у того же Erlang'а проблемы вообще с архитектурой современных машин, и Erlang VM — это, по сути, самостоятельная ОС, мало имеющая отношения к тому, что под ней.
Тут можно только ответить, что других архитектур и современных машин у меня для Вас пока нет
Кстати, возможно, что проблемы у него не столько с современными машинами, сколько с нашей физической реальностью. Чего именно ему не хватает в современных машинах, и как это можно было бы исправить, чтобы программы на Эрланге работали эффективно (не медленее, чем на существующем C++)? Не нарушая законы физики?
M>И? Дальше что? Это все равно — теоретические изыски. На практике надо смотреть реальные задачи и доатсточно ли нам этой скорости.
Конечно, всегда можно сказать, что того, что мы имеем, нам вполне достаточно, а то, чего мы не имеем, нам совершенно не нужно. Примерно так делала лисица в известной басне.
Однако, если мы с помощью примитивной императивщины имеем экспоненциально более быструю реализацию, чем с помощью функционального подхода, то возникает вопрос: ради чего мы должны отказаться от первой в пользу второго?
C>>И что с этим приходится бороться малоестественными приёмами типа переделки рекурсии в хвостовую? M>Что в этом малоестественного?
Это малоестественно в плане предлагаемой Вами математичности: естественное описание задачи, если мы хотим, чтобы она решалась быстро, оказывается похоронено под грудой костылей. Причём гораздо более сложной, чем в императивном случае. В данном случае можно предположить, что так приходится делать из-за того, что современные функциональные языки находятся в младенческом состоянии, вот-вот они научатся сами выявлять возможности переделки рекурсии в хвостовую, а ещё через чуть-чуть — понимать, как линейное вычисление можно переделать в логарифмическое, заодно сами же станут определять в каждом конкретном случае, какой вариант быстрее. Но именно это мы уже давно слышали от лисперов: функция стала полноправным членом программы, теперь компилятор может анализировать её исходный код, и уж с помощью компьютера он найдёт гораздо лучший способ перевести её в машинный код, чем человек. Но только воз и ныне там. Хорошо хоть научились хвостовую рекурсию переделывать в цикл (императивщина!), и теперь можно ему подсказывать, не выходя за рамки функционального подхода. Но помогает это не всегда.
Ещё один хороший пример — так любимый функциональщиками квиксорт. Что ему приходится вытворять с памятью из-за ограничения немодифицируемости существующих данных — это отдельная песня. Или можно вспомнить ленивость в хаскеле, с которой умеют бороться только положившие на это жизнь гуру.
Смысл есть во многом. В функциональном программировании он тоже есть. Идея использования функций как объектов и манипулирования с ними совсем не так плоха. Что плохого, скажем, в передаче функции — фильтра в некую функцию поиска или же функции — подинтегрального выражения в функцию вычисления интеграла ?
И в иммутабельности ничего плохого нет. Меньше изменений — меньше риска сделать ошибку. Разумеется там, где объекты могут быть иммутабельными по своей природе.
Пока это используется там, где по самой логике программы мы имеем работу с такими объектами и понятиями — функциональное программирование вполне неплохо.
А вот когда этот подход начинают использовать там, где он явно ни к чему — получается ерунда. Когда изо всех сил пытаются вычленить и пристроить функцию там, где ей совсем не место, когда пытаются изо всех сил устроить иммутабельность для принципиально изменяющихся объектов, придумывают для этого алгоритмы и структуры данных, которые в итоге оказываются сложнее и запутаннее — получается ерунда.
В общем, все хорошо в меру, и не сотвори себе кумира.
Здравствуйте, Mamut, Вы писали:
M>Главная проблема императивщины в том, что она убирает любую декларативность из программирования и за деревьями не видно леса. ФП предлагает возможность описать задачу в терминах «что надо сделать», а не «как это сделать».
Нет, не предлагает. Несмотря на лаконичный синтаксис, это всё равно описание "как это сделать". Например поменяв строчки в примере fac местами — получим stackoverflow.
Причём это "как" зачастую плохо отображается на современные железо. Лаконичный и "типа декларативный" fibs — тормоз
— именно потому что описывается "как", а не "что." И только потому что описывается "как" приходится знать о таких вещах "как" хвостовая рекурсия, чтобы понимать и иметь возможность переписать через дополнительный acc параметр, убивая изначальную "типа декларативность".
M>>И? Дальше что? Это все равно — теоретические изыски. На практике надо смотреть реальные задачи и доатсточно ли нам этой скорости.
C>Конечно, всегда можно сказать, что того, что мы имеем, нам вполне достаточно, а то, чего мы не имеем, нам совершенно не нужно. Примерно так делала лисица в известной басне.
Демагогия
C>Однако, если мы с помощью примитивной императивщины имеем экспоненциально более быструю реализацию, чем с помощью функционального подхода, то возникает вопрос: ради чего мы должны отказаться от первой в пользу второго?
Выразительность, скорость разработки.
C>>>И что с этим приходится бороться малоестественными приёмами типа переделки рекурсии в хвостовую? M>>Что в этом малоестественного?
C>Это малоестественно в плане
демагогии и абстрактных заявлений про абстрактную скорость для абстрактных сферовакуумных задач, которую извини, но я скипнул.
На практике ничего неестественного в хвостовой рекурсии нет. И на практике в подавляющем количестве задач все упрется в базу/сеть/скорость записи на диск быстрее, чем оно упрется в проблемы со производительностью ФП
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Тут есть разные точки зрения. Я считаю, что функциональное программирование это когда функция является объектом первого порядка (т.е. может сохраняться в переменную, передаваться в другую функцию в качестве аргумента). И это всё. На примитивном уровне даже в C поддерживается функциональное программирование (см. функцию qsort). Конечно для вящего удобства желательны не просто функции, а хотя бы вложенные функции с доступом к стеку родителя, а ещё лучше вложенные функции, захватывающие переменные и продлевающие их жизнь.
Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
Есть точка зрения, что ФП это иммутабельность как минимум, а порой и ленивость. Но я считаю, что это ортогональные понятия. Можно и иперативную программу писать с иммутабельными переменными и рекурсиями.
Иммутабельность это штука не всегда полезная. У неё есть плюсы, есть и минусы. Минусы естественно в производительности (хотя порой они от незнания, а не обусловлены объективно). Плюсы в том, что о программе проще рассуждать со всеми вытекающими. Параллельность да и в принципе удобно, когда 100% знаешь, что твой объект без всяких клонирований никто не тронет где-нибудь в коллбэке. Но всё равно я против поголовной иммутабельности. Мутабельности должно быть место и достаточно важное.
Насчёт ленивости у меня мнения чёткого нет, где-то она удобна (функциональные операции над бесконечными последовательностями), где-то не очень.
Здравствуйте, rfq, Вы писали:
D>>Любишь глобальные переменные?
rfq>Не люблю. Если можно, обхожусь без них. Но если я не использую глобальные переменные, могу я сказать, что программирую в функциональном стиле?
Нет. Я имел в виду другое:
rfq>Какой смысл программировать в условиях искусственных ограничений?
Кому-то и запрет глобальных переменных — тоже искусственные ограничения и скакание на одной ноге.
Здравствуйте, Mamut, Вы писали:
I>>На практике в любой большой системе всегда найдется значительная часть важного функционала, которая упирается именно в процессор-шину.
M>Что такое «большая система»? Что такое значительная часть?
Это тебе в толковый словарь русского языка.
M>Блин. Сплошные сферовакуумные кони, задачи, скорости Мы вообще не упираемся в процессор-шину. У нас достаточно большая система? (вычисление кредитов, посуточное вычисление процентов по кредитам, оплаты и еще вагоны и телеги всего).
Точнее, у вас около нуля вычислительных задач. С кредитами на каждый чих надо лазить в базу. Собтсвенно, всё.
I>>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд. M>Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего
Твои тезисы, если в кратце, "Боже... Подумать мозгом можно..." Увлекательно, но информации около нуля слева.
Ты недавно говорил "давайте рассматривать реальные задачи". Внезапно "Для этих задач возьмем ... C"
I>>Здесь экзотика навроде Эрланга сосёт не нагибаясь, как раз потому, что в чистом виде Эрланг нежизнеспособен, ему нужна конская платформа, которая фактически особая ОС поверх имеющейся ОС.
M>Любой современный язык в чистом виде нежизнеспособен (за исключением очень узких ниш).
Хватит врать, только Эрлангу и парочке таких же языков нужна конская платформа, фактически специальная ОС.
Здравствуйте, dimgel, Вы писали:
I>>Более того, процессор уже лет 20 или 30 невозможно описать аналитически. Даже кеш и тот не описывается аналитически.
D>А вот отсюда можно поподробнее? Что значит "описать аналитически" и почему нельзя? Вроде бы детерминированная фигня, моделируют её программно.
Моделируют программно, но невозможно написать одну большую функцию сигнала от времени для каждой из ножек.
Здравствуйте, Mamut, Вы писали:
M>На практике ничего неестественного в хвостовой рекурсии нет. И на практике в подавляющем количестве задач все упрется в базу/сеть/скорость записи на диск быстрее, чем оно упрется в проблемы со производительностью ФП
На практике в любой большой системе всегда найдется значительная часть важного функционала, которая упирается именно в процессор-шину. Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд.
Здесь экзотика навроде Эрланга сосёт не нагибаясь, как раз потому, что в чистом виде Эрланг нежизнеспособен, ему нужна конская платформа, которая фактически особая ОС поверх имеющейся ОС.
Вот в случае с сетью, всякими событийными моделями, где процессор не является узким местом ФП и Эрланг в т.ч. вполне себе неплох. Но вообще говоря и в этой области у ФП слишком много конкурентов, при чем настолько, что и здесь ФП в меньшинстве.
Здравствуйте, AlexRK, Вы писали:
I>>>Ого, и в джаварантайме наверняка есть процессы, как в эрланге, правильно тебя понимаю ? F>>давно там зелёные треды выпилили? ARK>Ой давно-о-о...
Здравствуйте, Spiceman, Вы писали:
vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП)
S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
В силу собственной неспособности вспомнить хоть какие-то пригодные для гугления подробности притчи о спорящих мудрецах, каждый из которых пытался натянуть сову на свой глобус, скажу просто: ИМХО, вы оба пытаетесь натянуть сову на глобус. "А по-моему, они одинаковые." (c) это ортогональные вещи. Да, и кстати, на этот счёт есть старое, но прекрасное: http://rsdn.ru/forum/philosophy/3149723.1
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Kernighan, Вы писали:
K>>А где тут ЯВУ, а где ассемблер? K>>Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)
EP>В ASM есть инструкция с говорящим именем loop
Ну, да. Digital в своё время даже на С долгое время не переходила,
потому что у неё был настолько хороший Макроассемблер.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я кстати не помню чтобы компилятор вставлял loop — везде был явный счётчик и условный переход.
Это потому, что она если и была когда-то эффективней отдельных декремента и условного перехода, то очень давно, во времена 8086. Кстати, с декрементом такая же фигня по сравнению с обычным вычитанием. Их даже отменили в 64-битном режиме, чтобы освободить место для новых инструкций.
Так что можете считать, что инструкции loop в ассемблере нет
Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>согласен — в асме были переходы, в С циклы, в хаскеле — формулы. какой тебе вариант понятней — асмовский, сишный или BZ>fac 0 = 1 BZ>fac n = n*fac(n-1) BZ>?
Здравствуйте, BulatZiganshin, Вы писали:
EP>>Какой вариант тебе понятней? Императивное вычисление чисел Фибоначчи? Или BZ>fib 0 = 1 BZ>fib 1 = 1 BZ>fib n = fib(n-1) + fib(n-2)
Эта наивная реализация requires O(fib n) additions В то время как в наивной итеративной версии будет линейное количество сложений.
BZ>а тебе?
Во-первых хакелисты считают каноничной другую версию.
Во-вторых итеративную версию можно объяснить ребёнку, который даже складывать не умеет — через линейку и циркуль. А вот на счёт рекурсивной версии (не говоря уже об каноничной) я так не уверен
Здравствуйте, Mamut, Вы писали:
BZ>>>fac 0 = 1 BZ>>>fac n = n*fac(n-1)
K>>Ну мне понятнее сишный.
M>При том, что это — практически прямая математическая запись? Ну-ну.
Вы так говорите, как будто математическая запись — это хорошо.
В современном мире программистов гораздо больше, чем математиков,
и программирование по большей части решает задачи с математикой
(тем более школьно-формульной математикой) никак не связанные.
K>>Получается, что функциональные языки по степени своей высокоуровневости стоят где-то рядом с процедурными, а не выше их.
M>Нет, не получается.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Kernighan, Вы писали:
K>>А где тут ЯВУ, а где ассемблер? K>>Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)
EP>В ASM есть инструкция с говорящим именем loop
Ну вот видите, даже в ассемблере есть, а в функциональных языках нет.
Какие же они после этого высокоуровневые?
M>>Еще один Шеридан с абстрактными заявлениями про скорость.
EP>"O(fib n) additions" вместо O(n) на ровном месте — это абстрактное заявление про скорость?
Да. Извини, но это даже не хочется обсуждать, если ты этого не понимаешь.
Здравствуйте, cures, Вы писали:
C>а ещё через чуть-чуть — понимать, как линейное вычисление можно переделать в логарифмическое, заодно сами же станут определять в каждом конкретном случае, какой вариант быстрее.
Кстати, императивное программирование принципиально не препятствует логарифмической оптимизации линейно-рекуррентного кода. То есть в этом аспекте не видно преимущества от использования ФП (по крайней мере в контексте современных ФП языков).
C>Ещё один хороший пример — так любимый функциональщиками квиксорт. Что ему приходится вытворять с памятью из-за ограничения немодифицируемости существующих данных — это отдельная песня.
Суть настоящего quicksort именно в перестановке элементов in-place, это даже упоминал Erik Meijer в одном из своих видео по Haskell. То есть настоящий quicksort на Haskell придётся реализовывать через императивный код на монадах. А тот пример который обычно называют quicksort — таковым не является.
Здравствуйте, BulatZiganshin, Вы писали:
EP>>>>Какой вариант тебе понятней? Императивное вычисление чисел Фибоначчи? EP>>Эта наивная реализация requires O(fib n) additions В то время как в наивной итеративной версии будет линейное количество сложений. BZ>мемоизация ненамного сложнее: BZ>fib 0 = 1 BZ>fib 1 = 1 BZ>fib n = fibs!!(n-1) + fibs!!(n-2) BZ>fibs = map fib [0..]
Всё равно до итеративной версии ещё далеко — у версии с мемоизацией линейная сложность по памяти, вместо положенной константой — и это всё ещё простейший пример.
И кстати, как видно нет тут никакой хвалёной декларативности/math-like. А по понятности на мой вкус хуже итеративной версии.
BZ>а теперь попробуй добавить мемоизацию в сишную функцию. только без глоб. переменных, будь ласка
Здравствуйте, Mamut, Вы писали:
M>>>Блин. Сплошные сферовакуумные кони, задачи, скорости Мы вообще не упираемся в процессор-шину. У нас достаточно большая система? (вычисление кредитов, посуточное вычисление процентов по кредитам, оплаты и еще вагоны и телеги всего).
I>>Точнее, у вас около нуля вычислительных задач. С кредитами на каждый чих надо лазить в базу. Собтсвенно, всё.
M>Ой, ты не поверишь. Это описывает примерно 99% всех «больших систем».
В вашей конторе вполне возможно. Сейчас сложный, тяжелый софт появляется даже на планшетах и мобилах. Много ты Эрланге под мобилы написал ?
I>>>>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд. M>>>Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего I>>Твои тезисы, если в кратце, "Боже... Подумать мозгом можно..." Увлекательно, но информации около нуля слева.
M>Мои тезисы, если в кратце: перестаньте считать сферовакуумных коней.
Сферовакуумный конь это твои 99% Сильно думаю, ты эту статистику только что придумал. Игровой софт, скажем, уже не вписывается в твою стройную картину.
I>>Ты недавно говорил "давайте рассматривать реальные задачи". Внезапно "Для этих задач возьмем ... C"
M>Вот моя полная цитата:
M>
M>И на практике в подавляющем количестве задач все упрется в базу/сеть/скорость записи на диск быстрее, чем оно упрется в проблемы со производительностью ФП
Откуда ты взял это "подавляющее количество задач" ?
M>Там, где упрется в ФП, выбирайте другие языки
Так и происходит. И как видишь, доля ФП на рынке ничтожно мала
I>>Хватит врать, только Эрлангу и парочке таких же языков нужна конская платформа, фактически специальная ОС.
M>Ну-ну. Попробуй что-то из свой «большой системы» что-то реализовать на чистом языке программирования. Любом.
При чем здесь чистый язык ? Толщина прослойки между языком и ОС стремится к нулю практически везде, кроме Эрланга.
Здравствуйте, Ikemefula, Вы писали:
I>Сначала в архитектуре. У него своя особенная платформа, проблемы которой никаким дизайном в принципе не исправить.
я вас всех тут читаю-читаю и так и не понял, что у него не так с платформой.
не портанули? ну да, но ведь и другие виртуалки не все портанули на мобилки, к примеру.
Здравствуйте, Ikemefula, Вы писали:
I>То есть, ты утверждаешь, что код игропрома составляет не более 1% ? Или игровые движки уже начали на Эрланге писать ?
я утверждаю, что ты гонишь, и эрланк тут совсем ни при чём.
F>>на haskell можно писать игры хоть используя чистый opengl, хоть цепляясь к существующим движкам. I>Покажи хотя бы одну прибыльную игру, которая написана на Хаскеле.
ну начались верчения...
сначала "хоть одну игру", потом "хоть одну коммерческую", потом "успешную", потом "из десятки лучших", а потом будет "всё равно WoW не переплюнуть ахахах))0)"
я, по-моему, видел это уже в линакс-срачах.
F>>на erlang же графику вообще имхо бессмысленно делать I>Опаньки ! I>И что же у тебя куда вписывается ?
настолько тянет ответить, пока не прочитаешь всё сообщение?
так сильно печёт?
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Сколько удивительных открытий порою можно сделать! В Haskell есть даже глобальные переменные (unsafePerformIO + NOINLINE), но это не комильфо.
ФП — это просто другой взгляд на программирование, где запуск программы есть вычисление функции против идеи пошагового исполнения по инструкции в императивном программировании. У каждого подхода есть свою плюсы, есть минусы. Многие недопонимают ФП, но это нормально. Вообще, когда недопонимают, то это абсолютно нормально. Такая селяви.
Здравствуйте, neFormal, Вы писали:
I>>Ого, и в джаварантайме наверняка есть процессы, как в эрланге, правильно тебя понимаю ? F>давно там зелёные треды выпилили?
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
Здравствуйте, neFormal, Вы писали:
rfq>>Какой смысл программировать в условиях искусственных ограничений?
F>меньше шансов облажаться с изменением состояния.
+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
Здравствуйте, vsb, Вы писали:
vsb>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
Здравствуйте, Spiceman, Вы писали:
rfq>>Какой смысл программировать в условиях искусственных ограничений? S>О каких ограничениях идет речь?
например, в некоторых языках нельзя держать вспомогательную переменную за пределами ф-ции.
приходится носить её с собой по итерациям в fold'ах или гонять через рекурсию.
и рекурсия тоже не самый любимый подход в императивщине. под неё надо подстраиваться. это тоже ограничение.
а ещё во многих языках нет банального наследования. нельзя взять и расширить существующий тип(данные+ф-ции), либо приходится это делать крайне ректально.
Здравствуйте, neFormal, Вы писали:
F>а ещё во многих языках нет банального наследования.
Ну это уже проблемы отдельных языков, а не сабжа как такового.
UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
ФП подразумевает явное описание зависимостей выходных данных от входных. Конечно, это справедливо и для любых промежуточных результатов. Это сильно облегчает работу компилятора. В теории это даёт ему возможность применять очень крутые оптимизации, в том числе автоматическое распараллеливание. В императивных языках бывает сложно определить зависимости между данными, что ограничивает возможности автоматической оптимизации. Иногда функциональное представление алгоритма понятнее и для человека, особенно если у него математический бэкграунд.
На практике же, компиляторы ФЯ пока не достаточно хороши, а для невычислительных алгоритмов обычно удобнее императивное представление.
Здравствуйте, dimgel, Вы писали:
D>Ну это уже проблемы отдельных языков, а не сабжа как такового.
да, но это распространено.
D>UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).
да пофиг на ООП. мне же реюз написанного кода нужен.
я не хочу раскидывать это по куче разных мест или в каждом новом типе указывать весь список используемых "родителей" и обкладываться ф-циями для использования всех этих возможностей.
Здравствуйте, Mazay, Вы писали:
M>ФП подразумевает явное описание зависимостей выходных данных от входных. Конечно, это справедливо и для любых промежуточных результатов. Это сильно облегчает работу компилятора.
rfq>Какой смысл программировать в условиях искусственных ограничений?
Пилат!
Есть пространство, а есть дуальное пространство.
Пространство -- сами объекты.
Дуальное пространство -- операции над объектами.
Чем больше ограничений, тем уже пространство, но тем (обычно) интереснее дуальное пространство.
Это разве не очевидно??
vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений?
Грамотные ограничения полезны.
Вот законы в государстве, например — типичные ограничения. Не дают разгуляться фантазиям.
rfq>Может, это просто детская забава, типа скакать на одной ноге?
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Не знаю что за ограничения и на каком языке вы пишете... но все современные гибридные языки поддерживают ФП в достаточной мере, чтобы использовать его потрясающие возможности и не думать про ограничения. Можно использовать ФП вместе с ООП и обычным процедурным программированием, просто используя в конкретном месте именно то, что там нужно по смыслу.
Вот есть у вас структура данных — какой-то контейнер (на базе списка, дерева и т.п.). И нужно для каждого (или не каждого) элемента выполнить какое-то действие, причем действия могут быть разные и их может быть много. До лямбда-функций приходилось или писать метод на каждое действие (с обходом контейнера) — код обхода дублировался; или придумывать интерфейс визитора, от него наследовать классы, в классе делать метод типа Visit и все это куча кода. С появлением лямбда-функций все упростилось, просто передаешь код в метод ForEach контейнера и все, никакой лишней писанины.
Нет такого преступления, на которое не пошло бы суверенное родоплеменное быдло ради продления своего бессмысленного рода и распространения своего бессмысленного генома.
Здравствуйте, anonymouse2, Вы писали:
A>До лямбда-функций приходилось или писать метод на каждое действие (с обходом контейнера) — код обхода дублировался; или придумывать интерфейс визитора, от него наследовать классы, в классе делать метод типа Visit и все это куча кода.
Тем не менее, сила лямбд не в том что не нужно создавать класс — это всё константные синтаксические расходы, а в том что для захвата N переменных из контекста, не нужно писать Θ(N) кода.
A>С появлением лямбда-функций все упростилось, просто передаешь код в метод ForEach контейнера и все, никакой лишней писанины.
Да, но всё же стоит отметить, что ForEach (и другие ФВП) не всегда целесообразно использовать с лямбдами. Например если лямбда сильно увеличивает количество строк в функции, или код внутри неё используется в разных местах.
P.S. AFAIK, в ФП считается хорошем тоном НЕ использовать лямбды:
https://wiki.haskell.org/Pointfree
It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.
Здравствуйте, Spiceman, Вы писали:
vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.
S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.
Странное мнение. Если начать осваивать программирование с процессора, то окажется, что никакого ФП и близко нет, всё насквозь мутабельное. Чуть выше снова нет никакого ФП и здесь уже работает операционная система и тд. ФП появляется только в языках сильно высокого уровня.
А если посмотреть, что куча софта была написана в тупом фортране, императивнейшем Си, а строчек на Коболе по сей день больше, чем на любом другом языке, то вообще странно выходит.
Здравствуйте, dimgel, Вы писали:
F>>меньше шансов облажаться с изменением состояния.
D>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.
Здравствуйте, dimgel, Вы писали:
F>>а ещё во многих языках нет банального наследования.
D>Ну это уже проблемы отдельных языков, а не сабжа как такового. D>UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).
Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру
Здравствуйте, neFormal, Вы писали:
F>например, в некоторых языках нельзя держать вспомогательную переменную за пределами ф-ции. F>приходится носить её с собой по итерациям в fold'ах или гонять через рекурсию. F>и рекурсия тоже не самый любимый подход в императивщине. под неё надо подстраиваться. это тоже ограничение. F>а ещё во многих языках нет банального наследования. нельзя взять и расширить существующий тип(данные+ф-ции), либо приходится это делать крайне ректально.
Ну так в любом подходе есть свои ограничения. Если говорить о чистом ФП, там одни ограничения, если говорить о чистом ООП, там другие ограничения. И я сильно сомневаюсь, что если писать на чистом ООП, радость будет больше. Не зря же в C# есть анонимные функции и классы. Это уже уход от ООП и мне бы сильно не хотелось бы к нему возвращаться. Таким образом, изначальный вопрос можно переформулировать: "Смысл функционального программирования программирования в ограничениях любого подхода?"
Я не знаю, какой подход более ограничивает, ФП или императивный, но ООП точно ограничивает сильнее.
Здравствуйте, Ikemefula, Вы писали:
D>>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
I>Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.
Я написал не про обработку видео и звука и не про работу с железом. А про entities, и даже в скобках указал, что речь про работу с базой.
Здравствуйте, Ikemefula, Вы писали:
I>Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру
Я тут где-то рядом давал ссылку на старый пост IT, где тот говорит, что ООП работает вне метода, а ФП — внутри. При этом IT всегда рассуждает как сугубо практик. А читать всяких левых теоретиков и жонглёров баззвордами — только грузиться и запутываться.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, neFormal, Вы писали:
rfq>>>Какой смысл программировать в условиях искусственных ограничений?
F>>меньше шансов облажаться с изменением состояния.
D>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Если лабать формы для отчетов, может и не нужно.
Но если строить серьёзное ПО, например, такое http://www.reactivemanifesto.org/, то речь идёт о правильном проектировании программных систем.
Но в целом ФП — сплошный возможности.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>P.S. AFAIK, в ФП считается хорошем тоном НЕ использовать лямбды:
WAT
а как без них?
EP>
EP>https://wiki.haskell.org/Pointfree
EP>It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.
pointfree вообще не об этом. даже не рядом.
это скорее "старайтесь не указывать лишних аргументов, если у вас есть частичное применение".
Здравствуйте, Farsight, Вы писали:
D>>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!
F>А где?
Что где? Где прочитал — не помню. Где юзаю — да во всех проектах, где есть база.
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?
Ограничения мешают прострелить себе ногу. Это относится не только к ФП, это про вообще.
Здравствуйте, Ikemefula, Вы писали:
I>Странное мнение. Если начать осваивать программирование с процессора, то окажется, что никакого ФП и близко нет, всё насквозь мутабельное.
а если изучить как физически устроены процессоры то окажется что это чистое ФП, которое протянули через угольное ушко императивности. в результате монстр с миллиардами транзисторов может выполнять от силы несколько тыщ операций одновременно, да и то с кучей ограничений. или изучить как работает человеческая псизхика и окажется что там есть императивная часть в виде мускулов и желех и ФП-часть которая занимается чисто обработкой информации. и даже если заглянуть в глубюины физики, то окажется что они давно представляют мир в виде формул, где время представляет собой всего лишь одну из многих переменных
Здравствуйте, Ikemefula, Вы писали:
I>Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.
делают при соответствующей оптимизации/библиотеках. даже для gpu библиотеки есть. но большая часть кода не требует оптимизации вообще. я лично хочу иметь ФП язык, совместимый с С++ по структурам данных и исключениям
K>ФП — это комбинирование комбинаторов как основной способ решения задач программирования, а не "я тут как-то раз фильтр использовал вместо цикла".
F>а как без них?
Комбинирование комбинаторов полно по Тьюрингу. Смотри например SKI, Unlambda:
http://en.wikipedia.org/wiki/Unlambda
Unlambda is a minimal, "nearly pure"[1] functional programming language invented by David Madore. It is based on combinatory logic, a version of the lambda calculus that omits the lambda operator. It relies mainly on two built-in functions (s and k) and an "apply" operator (written `, the backquote character). These alone make it Turing-complete, but there are also some I/O functions to make it possible to interact with the user, some shortcut functions and a function for lazy evaluation. There are no variables in the language.
EP>>
EP>>https://wiki.haskell.org/Pointfree
EP>>It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.
F>pointfree вообще не об этом. даже не рядом. F>это скорее "старайтесь не указывать лишних аргументов, если у вас есть частичное применение".
Pointfree в том числе именно об этом — лямбды либо принимают какие-то параметры, либо захватывают. Pointfree же о том, чтобы вообще не использовать никакие параметры.
Здравствуйте, dimgel, Вы писали:
I>>Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру D>Я тут где-то рядом давал ссылку на старый пост IT, где тот говорит, что ООП работает вне метода,
Вне метода — то есть в интерфейсе — ФП или его элементы прекрасно работают. Все эти pure, иммутабельные структуры данных, или например ФВП — в том числе и про интерфейс.
D>а ФП — внутри.
Внутри функции как раз удобнее всего использовать ИП с элементами ФП, при этом снаружи функция может оставаться полностью чистой.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, rfq, Вы писали:
rfq>>Какой смысл программировать в условиях искусственных ограничений?
BZ>использование ЯВУ вместо ассемблера — как сказывается на производительнсоти, надёжности и твоём лично впечатлении от процесса програмирования?
А где тут ЯВУ, а где ассемблер?
Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>согласен — в асме были переходы, в С циклы, в хаскеле — формулы. какой тебе вариант понятней — асмовский, сишный или
BZ>fac 0 = 1 BZ>fac n = n*fac(n-1)
BZ>?
Смотря что считать понятностью. Если задавать вопросы "как это работает?", "насколько это эффективно?", "а что такое хвостовя рекурсия?" — то циклы таки-попонятнее будут.
K>>ФП — это комбинирование комбинаторов как основной способ решения задач программирования, а не "я тут как-то раз фильтр использовал вместо цикла".
не смотри на хакселистов. они ещё и не такое скажут.
F>>а как без них? EP>Комбинирование комбинаторов полно по Тьюрингу. Смотри например SKI, Unlambda:
это если они есть в языке.
EP>Pointfree в том числе именно об этом — лямбды либо принимают какие-то параметры, либо захватывают. Pointfree же о том, чтобы вообще не использовать никакие параметры.
и там же автор пишет "не превращайте код в нечитабельное говно своим pointfree-фаназизмом".
это не серебрянная пуля. это скорее маленьках синтаксическая хитрость, которая позволяет сделать код в некоторых случаях читабельней.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
K>>А где тут ЯВУ, а где ассемблер? K>>Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)
EP>В ASM есть инструкция с говорящим именем loop
Она как, это что же теперь получается, асм в яву записали?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В ASM есть инструкция с говорящим именем loop
А ещё есть (были?) loadsb, stosb. Но это не настоящий ассемблер
Они теперь всё это на лету переделывают в настоящий ассемблер, на чём наверняка что-то теряют.
А у остальных (RISC) такого никогда и не было.
K>>>ФП — это комбинирование комбинаторов как основной способ решения задач программирования, а не "я тут как-то раз фильтр использовал вместо цикла".
F>не смотри на хакселистов. они ещё и не такое скажут.
Они давно распробовали и комбинаторы и лямбды, и в результате отдают предпочтение комбинаторам. Почему бы не принять во внимание их мнение?
F>>>а как без них? EP>>Комбинирование комбинаторов полно по Тьюрингу. Смотри например SKI, Unlambda: F>это если они есть в языке.
А в каком ФП языке их нет?
Я даже на C++ реализовывал
gentoo fibs # tail -n 6 main.cpp && clang++ main.cpp -std=c++1y -stdlib=libc++ && echo _____ && ./a.out
int main()
{
auto fibs = fix(cons(0) * cons(1) * (zipWith(sum) <ap> tail));
auto x = fibs <at> 101;
cout << x << endl;
}
_____
573147844013817084101
EP>>Pointfree в том числе именно об этом — лямбды либо принимают какие-то параметры, либо захватывают. Pointfree же о том, чтобы вообще не использовать никакие параметры. F>и там же автор пишет "не превращайте код в нечитабельное говно своим pointfree-фаназизмом". F>это не серебрянная пуля. это скорее маленьках синтаксическая хитрость, которая позволяет сделать код в некоторых случаях читабельней.
Я же сказал что pointfree это "хороший тон", а не руководство к действию.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Они давно распробовали и комбинаторы и лямбды, и в результате отдают предпочтение комбинаторам. Почему бы не принять во внимание их мнение?
потому что они хакселисты. этого уже достаточно, чтобы относиться с подозрением к их вкусам.
тем более, если они создают новые определения для старых вещей. что дальше будет? для ФП-языка потребуется поддержка линз или монад?
F>>это если они есть в языке. EP>А в каком ФП языке их нет?
EP>Я же сказал что pointfree это "хороший тон", а не руководство к действию.
хороший тон в ФП? нет, это хороший тон в х-е, потому что не все языки поддерживают ЧП.
Здравствуйте, cures, Вы писали:
EP>>В ASM есть инструкция с говорящим именем loop C>А ещё есть (были?) loadsb, stosb. Но это не настоящий ассемблер C>Они теперь всё это на лету переделывают в настоящий ассемблер, на чём наверняка что-то теряют.
Я кстати не помню чтобы компилятор вставлял loop — везде был явный счётчик и условный переход.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Kernighan, Вы писали:
K>>Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)
BZ>согласен — в асме были переходы, в С циклы, в хаскеле — формулы. какой тебе вариант понятней — асмовский, сишный или
BZ>fac 0 = 1 BZ>fac n = n*fac(n-1)
Ну мне понятнее сишный.
Получается, что функциональные языки по степени своей высокоуровневости стоят где-то рядом с процедурными, а не выше их.
Кстати, факториал на С тоже пишется в две строчки (можно даже в одну).
BZ>>fac 0 = 1 BZ>>fac n = n*fac(n-1)
K>Ну мне понятнее сишный.
При том, что это — практически прямая математическая запись? Ну-ну.
K>Получается, что функциональные языки по степени своей высокоуровневости стоят где-то рядом с процедурными, а не выше их.
M>>При том, что это — практически прямая математическая запись? Ну-ну.
K>Вы так говорите, как будто математическая запись — это хорошо.
Вообще-то — это очень хорошо.
K>В современном мире программистов гораздо больше, чем математиков,
И подавляющее боьшинство программистов учило математику не только в школе, но и в университете.
K>и программирование по большей части решает задачи с математикой K>(тем более школьно-формульной математикой) никак не связанные.
А я и не говорил, что они этим занимаются Главная проблема императивщины в том, что она убирает любую декларативность из программирования и за деревьями не видно леса. ФП предлагает возможность описать задачу в терминах «что надо сделать», а не «как это сделать».
И все эти определения функций, иммутабельные переменные и прочее прекрасно ложатся на даже те базовые мат. знания, которыми по идее должен обладать каждый программист.
K>>>Получается, что функциональные языки по степени своей высокоуровневости стоят где-то рядом с процедурными, а не выше их.
M>>Нет, не получается.
K><сарказм>Аргументированно.</сарказм>
Здравствуйте, BulatZiganshin, Вы писали:
I>> Если начать осваивать программирование с процессора, то окажется, что никакого ФП и близко нет, всё насквозь мутабельное.
BZ>а если изучить как физически устроены процессоры то окажется что это чистое ФП, которое протянули через угольное ушко императивности.
Это как??
> в результате монстр с миллиардами транзисторов может выполнять от силы несколько тыщ операций одновременно, да и то с кучей ограничений.
да, у императивной парадигмы такие требования. а что меняет функциональная?
> или изучить как работает человеческая психика и окажется что там есть императивная часть в виде мускулов и желех и ФП-часть > которая занимается чисто обработкой информации.
мне более понятно представление где вычисляющая система это экспертная система как CLIPS, а не символическая система как Lisp
(об этом хорошо написал Питер Джексон, Введение в экспертные системы в Главе 4; п.4.4. "Почему LISP не является языком представления знаний" )
> и даже если заглянуть в глубины физики, то окажется что они давно представляют мир в виде формул, где время представляет > собой всего лишь одну из многих переменных
в смысле если где-то в физике есть формула то это формула почему-то на лиспе? И почему эта формула не на ФорТране?? ("языке формул"). хотелось бы знать, при чем тут время вообще.
M>>Главная проблема императивщины в том, что она убирает любую декларативность из программирования и за деревьями не видно леса. ФП предлагает возможность описать задачу в терминах «что надо сделать», а не «как это сделать».
EP>Нет, не предлагает. Несмотря на лаконичный синтаксис, это всё равно описание "как это сделать". Например поменяв строчки в примере fac местами — получим stackoverflow.
Это все равно приближено описание «что сделать».
EP>Причём это "как" зачастую плохо отображается на современные железо. Лаконичный и "типа декларативный" fibs — тормоз
— именно потому что описывается "как", а не "что." И только потому что описывается "как" приходится знать о таких вещах "как" хвостовая рекурсия, чтобы понимать и иметь возможность переписать через дополнительный acc параметр, убивая изначальную "типа декларативность".
Еще один Шеридан с абстрактными заявлениями про скорость.
Здравствуйте, Mamut, Вы писали:
M>>>Главная проблема императивщины в том, что она убирает любую декларативность из программирования и за деревьями не видно леса. ФП предлагает возможность описать задачу в терминах «что надо сделать», а не «как это сделать». EP>>Нет, не предлагает. Несмотря на лаконичный синтаксис, это всё равно описание "как это сделать". Например поменяв строчки в примере fac местами — получим stackoverflow. M>Это все равно приближено описание «что сделать».
Несмотря на то что по форме есть некоторые сходства с математическим декларативным описанием, это всё же описание "как это сделать"
EP>>Причём это "как" зачастую плохо отображается на современные железо. Лаконичный и "типа декларативный" fibs — тормоз
— именно потому что описывается "как", а не "что." И только потому что описывается "как" приходится знать о таких вещах "как" хвостовая рекурсия, чтобы понимать и иметь возможность переписать через дополнительный acc параметр, убивая изначальную "типа декларативность". M>Еще один Шеридан с абстрактными заявлениями про скорость.
"O(fib n) additions" вместо O(n) на ровном месте — это абстрактное заявление про скорость?
M>>Еще один Шеридан с абстрактными заявлениями про скорость.
C>Гм, а вот это уже переход на личности, причём третьих лиц. По существу, в чём возражения против того, что прямое отображение функциональных парадигм на современное железо часто приводит к неэффективному коду?
Да. Неэффективный код может быть. Да, например у того же Erlang'а проблемы вообще с архитектурой современных машин, и Erlang VM — это, по сути, самостоятельная ОС, мало имеющая отношения к тому, что под ней.
И? Дальше что? Это все равно — теоретические изыски. На практике надо смотреть реальные задачи и доатсточно ли нам этой скорости.
C>И что с этим приходится бороться малоестественными приёмами типа переделки рекурсии в хвостовую?
Здравствуйте, BulatZiganshin, Вы писали:
I>>Странное мнение. Если начать осваивать программирование с процессора, то окажется, что никакого ФП и близко нет, всё насквозь мутабельное.
BZ>а если изучить как физически устроены процессоры то окажется что это чистое ФП, которое протянули через угольное ушко императивности.
Процессор весь насквозь мутабельный и императивный. Более того, процессор уже лет 20 или 30 невозможно описать аналитически. Даже кеш и тот не описывается аналитически.
Здравствуйте, Ikemefula, Вы писали:
I>Более того, процессор уже лет 20 или 30 невозможно описать аналитически. Даже кеш и тот не описывается аналитически.
А вот отсюда можно поподробнее? Что значит "описать аналитически" и почему нельзя? Вроде бы детерминированная фигня, моделируют её програмно.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Суть настоящего quicksort именно в перестановке элементов in-place, это даже упоминал Erik Meijer в одном из своих видео по Haskell.
Это ещё Вирт в "Алгоритмах и структурах данных" упоминал, что-то типа "логично, что усовершенствованный вариант 'прямого обмена', как самого тормозного из трёх базовых алгоритмов, дал самый большой прирост производительности, но чтобы настолько..."
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BZ>>fib 0 = 1 BZ>>fib 1 = 1 BZ>>fib n = fib(n-1) + fib(n-2)
EP>Эта наивная реализация requires O(fib n) additions В то время как в наивной итеративной версии будет линейное количество сложений.
Здравствуйте, cures, Вы писали:
EP>>Я кстати не помню чтобы компилятор вставлял loop — везде был явный счётчик и условный переход.
C>Это потому, что она если и была когда-то эффективней отдельных декремента и условного перехода, то очень давно, во времена 8086. Кстати, с декрементом такая же фигня по сравнению с обычным вычитанием. Их даже отменили в 64-битном режиме, чтобы освободить место для новых инструкций. C>Так что можете считать, что инструкции loop в ассемблере нет
Скажу по секрету — ее никогда не было по большому счету
Даже во времена 8086 ее мало кто использовал
Здравствуйте, Privalov, Вы писали:
I>>Даже во времена 8086 ее мало кто использовал
P>Причем в том коде, который я видел, loop использовали практически исключительно для организации пустых циклов — задержать выполнение.
Собственно дело в том, что loop гвоздями прибит к регистру CX. Из за этого тело цикла, как правило, удлинняется на две команды — push cx и pop cx, если, скажем, нужно вызвать хоть какую нибудь процедуру. Т.е. на ровном месте два дополнительных обращения к памяти.
Здравствуйте, Mamut, Вы писали:
M>Да. Неэффективный код может быть. Да, например у того же Erlang'а проблемы вообще с архитектурой современных машин, и Erlang VM — это, по сути, самостоятельная ОС, мало имеющая отношения к тому, что под ней.
M>И? Дальше что? Это все равно — теоретические изыски. На практике надо смотреть реальные задачи и доатсточно ли нам этой скорости.
Ну вот ты сам себе ответил, почему у Эрланга очень и очень узкая ниша — "у того же Erlang'а проблемы вообще с архитектурой современных машин"
Здравствуйте, Ikemefula, Вы писали:
I>Собственно дело в том, что loop гвоздями прибит к регистру CX. Из за этого тело цикла, как правило, удлинняется на две команды — push cx и pop cx, если, скажем, нужно вызвать хоть какую нибудь процедуру. Т.е. на ровном месте два дополнительных обращения к памяти.
Я знаю. Практически весь ассемблерный код с loop, который я видел, выглядел так:
mov cx, 1000
a: loop a
Нормальные циклы делались всякими je/jne/jc — в одну сторону и jmp — в другую.
Здравствуйте, rfq, Вы писали:
rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге? rfq>Я еще помню, как заклеивать дырки на перфокартах, но еще многого в программировании не понимаю.
Чтобы разные творчески одаренные личности не писали полную хрень.
Здравствуйте, Ikemefula, Вы писали:
I>Собственно дело в том, что loop гвоздями прибит к регистру CX. Из за этого тело цикла, как правило, удлинняется на две команды — push cx и pop cx, если, скажем, нужно вызвать хоть какую нибудь процедуру.
В архитектуре 8086 практически все регистры были к чему-то прибиты гвоздями: DS, SS — индексы в приёмнике и источнике, AX — аккумулятор, DX — расширение аккумулятора для инструкций типа умножения с делением, BX пожалуй единственный вспомогательный регистр общего назначения. А к CX прибит не только loop, но и lodsb, stosb, rep.
Здравствуйте, Ikemefula, Вы писали:
I>Ну вот ты сам себе ответил, почему у Эрланга очень и очень узкая ниша — "у того же Erlang'а проблемы вообще с архитектурой современных машин"
не, он просто подходит для довольно узкого круга задач.
для всего остального лучше подходят иные инструменты.
M>>На практике ничего неестественного в хвостовой рекурсии нет. И на практике в подавляющем количестве задач все упрется в базу/сеть/скорость записи на диск быстрее, чем оно упрется в проблемы со производительностью ФП
I>На практике в любой большой системе всегда найдется значительная часть важного функционала, которая упирается именно в процессор-шину.
Что такое «большая система»? Что такое значительная часть?
Блин. Сплошные сферовакуумные кони, задачи, скорости Мы вообще не упираемся в процессор-шину. У нас достаточно большая система? (вычисление кредитов, посуточное вычисление процентов по кредитам, оплаты и еще вагоны и телеги всего).
I>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд.
Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего
I>Здесь экзотика навроде Эрланга сосёт не нагибаясь, как раз потому, что в чистом виде Эрланг нежизнеспособен, ему нужна конская платформа, которая фактически особая ОС поверх имеющейся ОС.
Любой современный язык в чистом виде нежизнеспособен (за исключением очень узких ниш).
C>В архитектуре 8086 практически все регистры были к чему-то прибиты гвоздями: DS, SS — индексы в приёмнике и источнике, AX — аккумулятор, DX — расширение аккумулятора для инструкций типа умножения с делением, BX пожалуй единственный вспомогательный регистр общего назначения.
Это одновременню большой плюс и большая проблема. С одной стороны легко писать, с другой стороны приходится на ровном месте приседать со стеком.
>А к CX прибит не только loop, но и lodsb, stosb, rep.
Собственно этими командами тоже не шибко пользовались.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
I>>Ну вот ты сам себе ответил, почему у Эрланга очень и очень узкая ниша — "у того же Erlang'а проблемы вообще с архитектурой современных машин"
F>не, он просто подходит для довольно узкого круга задач.
"подходит" это не с потолка берется. Причина как раз в его архитектуре.
I>>>На практике в любой большой системе всегда найдется значительная часть важного функционала, которая упирается именно в процессор-шину. M>>Что такое «большая система»? Что такое значительная часть? I>Это тебе в толковый словарь русского языка.
Демагогия
M>>Блин. Сплошные сферовакуумные кони, задачи, скорости Мы вообще не упираемся в процессор-шину. У нас достаточно большая система? (вычисление кредитов, посуточное вычисление процентов по кредитам, оплаты и еще вагоны и телеги всего).
I>Точнее, у вас около нуля вычислительных задач. С кредитами на каждый чих надо лазить в базу. Собтсвенно, всё.
Ой, ты не поверишь. Это описывает примерно 99% всех «больших систем».
I>>>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд. M>>Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего I>Твои тезисы, если в кратце, "Боже... Подумать мозгом можно..." Увлекательно, но информации около нуля слева.
Мои тезисы, если в кратце: перестаньте считать сферовакуумных коней.
I>Ты недавно говорил "давайте рассматривать реальные задачи". Внезапно "Для этих задач возьмем ... C"
Вот моя полная цитата:
И на практике в подавляющем количестве задач все упрется в базу/сеть/скорость записи на диск быстрее, чем оно упрется в проблемы со производительностью ФП
Там, где упрется в ФП, выбирайте другие языки
Я понимаю, что эта прописная истина настолько недосягаема для господ теоретиков, что это нужно разжевывать и в рот класть.
I>>>Здесь экзотика навроде Эрланга сосёт не нагибаясь, как раз потому, что в чистом виде Эрланг нежизнеспособен, ему нужна конская платформа, которая фактически особая ОС поверх имеющейся ОС.
M>>Любой современный язык в чистом виде нежизнеспособен (за исключением очень узких ниш).
I>Хватит врать, только Эрлангу и парочке таких же языков нужна конская платформа, фактически специальная ОС.
Ну-ну. Попробуй что-то из свой «большой системы» что-то реализовать на чистом языке программирования. Любом.
I>>>На практике в любой большой системе всегда найдется значительная часть важного функционала, которая упирается именно в процессор-шину.
I>Точнее, у вас около нуля вычислительных задач. С кредитами на каждый чих надо лазить в базу. Собтсвенно, всё.
Ты уже определись. В любой большой системе, или только в тех, которые подходят под выдумываемые тобой на лету определения?
Здравствуйте, Ikemefula, Вы писали:
I>>>Ну вот ты сам себе ответил, почему у Эрланга очень и очень узкая ниша — "у того же Erlang'а проблемы вообще с архитектурой современных машин" F>>не, он просто подходит для довольно узкого круга задач. I>"подходит" это не с потолка берется. Причина как раз в его архитектуре.
Здравствуйте, neFormal, Вы писали:
I>>>>Ну вот ты сам себе ответил, почему у Эрланга очень и очень узкая ниша — "у того же Erlang'а проблемы вообще с архитектурой современных машин" F>>>не, он просто подходит для довольно узкого круга задач. I>>"подходит" это не с потолка берется. Причина как раз в его архитектуре.
F>в дизайне.
Сначала в архитектуре. У него своя особенная платформа, проблемы которой никаким дизайном в принципе не исправить.
Здравствуйте, Ikemefula, Вы писали:
I>>>>>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд. M>>>>Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего I>>>Твои тезисы, если в кратце, "Боже... Подумать мозгом можно..." Увлекательно, но информации около нуля слева. M>>Мои тезисы, если в кратце: перестаньте считать сферовакуумных коней. I>Сферовакуумный конь это твои 99% Сильно думаю, ты эту статистику только что придумал. Игровой софт, скажем, уже не вписывается в твою стройную картину.
да нормально вписывается.
но везде есть нюансы, потому что разные технологии имеют разные проблемы.
например, на scala можно спокойно писать игры под мобилки. libgdx этому даже способствует, но язык не самый удобный.
на haskell можно писать игры хоть используя чистый opengl, хоть цепляясь к существующим движкам. это тоже не без проблем, но всяко легче проблем с желанием реюза кода через наследование. а приходится лепить компоненты а ля Unity3D
на erlang же графику вообще имхо бессмысленно делать, но он хорошо подходит для бэкендов. та роль, которую часто берут python/ruby. да, у энларга не самая удобная работа с БД, но зато питонораби не могут дать прозрачности между несколькими нодами в кластере. ну и надёжность достаточная, чтобы спокойно спать по ночам. а то меня немного огорчает, что саппорт может и разбудить.
Здравствуйте, Ops, Вы писали:
D>>Кому-то и запрет глобальных переменных — тоже искусственные ограничения и скакание на одной ноге.
Ops>А кто-то на эти ограничения молится, и даже в генерируемом коде, вместо goto использует многоэтажные конструкции.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
I>>>>>>Часть задач вообще требуют исключительно процессор-шину, например обработка звука-видео-сигналов, вычисления и тд. M>>>>>Для этих задач возьмем на ФП, а C. И? Что-то изменилось в моих тезисах? Ничего I>>>>Твои тезисы, если в кратце, "Боже... Подумать мозгом можно..." Увлекательно, но информации около нуля слева. M>>>Мои тезисы, если в кратце: перестаньте считать сферовакуумных коней. I>>Сферовакуумный конь это твои 99% Сильно думаю, ты эту статистику только что придумал. Игровой софт, скажем, уже не вписывается в твою стройную картину.
F>да нормально вписывается.
То есть, ты утверждаешь, что код игропрома составляет не более 1% ? Или игровые движки уже начали на Эрланге писать ?
F>на haskell можно писать игры хоть используя чистый opengl, хоть цепляясь к существующим движкам.
Покажи хотя бы одну прибыльную игру, которая написана на Хаскеле.
F>на erlang же графику вообще имхо бессмысленно делать
Здравствуйте, neFormal, Вы писали:
F>я вас всех тут читаю-читаю и так и не понял, что у него не так с платформой. F>не портанули? ну да, но ведь и другие виртуалки не все портанули на мобилки, к примеру.
Рантайм Эрланга это считай полноценная ОС со своей многозадачностью и вытекающими последствиями. Т.е. тупо оверхед над любой ОС где ты хочешь запустить Эрланг.
Здравствуйте, Ikemefula, Вы писали:
I>Рантайм Эрланга это считай полноценная ОС со своей многозадачностью и вытекающими последствиями. Т.е. тупо оверхед над любой ОС где ты хочешь запустить Эрланг.
жаву-то запустили на мобилках.
и не просто жаву, а интерпретируемую сперва.
разрешаю начинать паниковать.
Здравствуйте, neFormal, Вы писали:
I>>То есть, ты утверждаешь, что код игропрома составляет не более 1% ? Или игровые движки уже начали на Эрланге писать ?
F>я утверждаю, что ты гонишь, и эрланк тут совсем ни при чём.
Серьезный аргумент.
F>ну начались верчения... F>сначала "хоть одну игру", потом "хоть одну коммерческую", потом "успешную", потом "из десятки лучших", а потом будет "всё равно WoW не переплюнуть ахахах))0)" F>я, по-моему, видел это уже в линакс-срачах.
Комедию пока что ты сам ломаешь. На хаскеле пока что каменный век в играх — как в 80х
Здравствуйте, neFormal, Вы писали:
I>>Рантайм Эрланга это считай полноценная ОС со своей многозадачностью и вытекающими последствиями. Т.е. тупо оверхед над любой ОС где ты хочешь запустить Эрланг.
F>жаву-то запустили на мобилках. F>и не просто жаву, а интерпретируемую сперва.
Здравствуйте, Ikemefula, Вы писали:
I>Комедию пока что ты сам ломаешь.
не я же бросаюсь громкими заявлениями без пруфов.
I>На хаскеле пока что каменный век в играх — как в 80х
они этим даже не занимаются.
на х-е очень мало чего близкого к гейдеву. но это не значит, что там нельзя ничего сделать.
я копался в этом, но я не смог найти удобных способов сделать то, что мне нужно. без зависимых типов там появляется блоатваря, но мб можно сделать то же самое через компоненты.
в остальном никто и не пытался там сделать какое-нибудь маленькое 2д.
там есть какой-то платный биндинг к огру, и можно самому нагенерить биндинг к любому плюсовому движку.
только биндинг может споткнуться о детали реализации. у меня получилось отрисовать террейн огром через х-ь, но это кучеряво.
Здравствуйте, neFormal, Вы писали:
I>>На хаскеле пока что каменный век в играх — как в 80х
F>они этим даже не занимаются. F>на х-е очень мало чего близкого к гейдеву. но это не значит, что там нельзя ничего сделать.
Да, полнота по тьюрингу и черчу творит чудеса.
F>я копался в этом, но я не смог найти удобных способов сделать то, что мне нужно.
Вот она, мощь Хаскеля !
F>в остальном никто и не пытался там сделать какое-нибудь маленькое 2д.
Вообще то пробовали и есть примеры даже 3D движка. Дальше примеров пока дело не пошло.
Здравствуйте, Ikemefula, Вы писали:
I>>>И давно джава рантайм стал осью ? F>>с тех пор, как эрланго-рантайм стал I>Ого, и в джаварантайме наверняка есть процессы, как в эрланге, правильно тебя понимаю ?
Здравствуйте, Ikemefula, Вы писали:
F>>я копался в этом, но я не смог найти удобных способов сделать то, что мне нужно. I> Вот она, мощь Хаскеля !
и чо?
то, что он не поддерживает практики из других языков, не значит, что там ничего нельзя сделать.
так что этот вопрос ещё открыт.
F>>в остальном никто и не пытался там сделать какое-нибудь маленькое 2д. I>Вообще то пробовали и есть примеры даже 3D движка. Дальше примеров пока дело не пошло.
ну это и я пробовал. толку то?
всё упрётся в логику и переобучение людей. вот тут будет проблема.
Здравствуйте, neFormal, Вы писали:
I>>>>И давно джава рантайм стал осью ? F>>>с тех пор, как эрланго-рантайм стал I>>Ого, и в джаварантайме наверняка есть процессы, как в эрланге, правильно тебя понимаю ?
F>давно там зелёные треды выпилили?
Ты правильно заметил — выпилили. А перед тем, как выпилить, они долго тухли и вместо них использовали нативные.
В эрланге, что характерно, это основное направление развития.
Здравствуйте, Mamut, Вы писали:
I>>В эрланге, что характерно, это основное направление развития.
M>Ахахахахахаха. Извините. Просто по-другому это прокомментировать нельзя никак.
Здравствуйте, neFormal, Вы писали:
I>>В эрланге, что характерно, это основное направление развития.
F>в эрланге мапят внутренние треды на нативные. там довольно забавно всё это происходит. F>неужели это плохо?
Это нормально. Но эрланговские процессы не разделяют никаких данных, то есть все взаимодействие делается через посылку сообщений. Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется. Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
Эту мульку быстро поняли в джаве и отказались. В эрланге это основа платформы, рантайм берет на себя все мыслимы и немыслимые оптимизации
Скажем, если делать все по простому, то на такой модели в винде той же могут быть конские задержки из за переключения потоков. Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер. А без этого задержки из за шедулера могут достигать до 15 сек, если винда скаже в другом процессе на диск жостко пишет или с каким девайсом работает всерьез
I>>>В эрланге, что характерно, это основное направление развития. M>>Ахахахахахаха. Извините. Просто по-другому это прокомментировать нельзя никак.
I>Еще один оргумент от тебя
Это именно аргумент. Потому что по иному никак это прокомментировать нельзя. Ты разбираешься в Эрланге в частности и в ФП в целом, как свинья в апельсинах, но пафоса и гонору в заявлениях у тебя — ого-го-го (ну то есть ровно то, за что Шеридана в КСВ гоняют ссаными тряпками).
Нативные потоки ОСи, доступные из Эрланга — это не приоритетное направление. Это одна их возможностей, которые добавят к языку. Года через два. А то и три. Это у них в roadmap long term: https://twitter.com/ruerlang/status/476397497863405569
Здравствуйте, Mamut, Вы писали:
M>Нативные потоки ОСи, доступные из Эрланга — это не приоритетное направление. Это одна их возможностей, которые добавят к языку. Года через два. А то и три. Это у них в roadmap long term: https://twitter.com/ruerlang/status/476397497863405569
Чисто между прочим — я вообще ничего не говорил про "нативные потоки доступные из Эрланга".
Здравствуйте, Ikemefula, Вы писали:
I>Но эрланговские процессы не разделяют никаких данных, то есть все взаимодействие делается через посылку сообщений.
ets
I>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется.
ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
I>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои.
даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
I>Эту мульку быстро поняли в джаве и отказались.
как будто это кого-то спасло...
всё равно дедлоки остались проблемой при создании жава-приложений.
I>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
Здравствуйте, neFormal, Вы писали:
I>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется. F>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного.
Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
I>>Но и эти гарантии сильно условные, дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга
F>очевидно, что конфликт у них будет по умолчанию. у системных потоков свои оценки потребности переключения, у виртуалок свои. F>даже питон действует похожим образом. он теперь тоже не подходит под современные оси?
Не любой, а Stackless Python. Я про него не сильно знаю.
F>всё равно дедлоки остались проблемой при создании жава-приложений.
На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
I>>Нет способа сказать той же винде что вот эти процессы в среднем всегда готовы выполняться и что де пусть она использует для них специальный шедулер.
F>серьёзно? Ненужноус не умеет расставлять здраво приоритеты?
И да и нет. Она заточена под пропускную способность, а не гарантии времени отклика. Есть простой пример — 'нагружаешь' один поток с помощью Sleep(1000) и замеряешь время ожидания. При 'правильной' диспетчеризации ОС, время задержки может быть ненамного больше. В винде у меня получались отклонения ажно до 15 секунд.
Если ОС даёт гарантии реального времени, то приоритет потока к моменту пробуждения будет максимальным в системе, дополнительно решается проблема инверсии приоритетов, что в сумме дает небольшую задержку.
С т.з. времени отклика переключения должны происходить как можно чаще. С т.з. пропускной способности переключений вообще не должно быть. Эта кухня должны быть реализована начиная с низкого уровня, железа, до самого верхнего + отдельно гарантии длительности выполнения системных вызовов.
В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай. Обработка аппаратных прерываний так же делается довольно варварским методом — глупый дривер или кривое устройство спокойно заблокирует тот же UI и даже мышь и тд и тд. При наличии жостких гарантий времени отклика, такое в принципе невозможно и есть ОС которые такие гарантии обеспечивают.
Здравствуйте, cures, Вы писали:
C>В архитектуре 8086 практически все регистры были к чему-то прибиты гвоздями: DS, SS — индексы в приёмнике и источнике, AX — аккумулятор, DX — расширение аккумулятора для инструкций типа умножения с делением, BX пожалуй единственный вспомогательный регистр общего назначения. А к CX прибит не только loop, но и lodsb, stosb, rep.
<offtopic>
DS и SS — сегментные регистры данных и стека соответственно. Индекс источника и приемника — SI и DI.
В принципе регистры можно было использовать, как угодно (кроме SP), учитывая факт прибития каждого из них гвоздями к чему-нибудь. И речь не о сегментных регистрах, конечно.
</offtopic>
Здравствуйте, Ikemefula, Вы писали:
I>>>Как то так выходит, что пропускная способность падает, хотя время отклика худо бедно гарантируется. F>>ничем оно не гарантируется. там же с другой стороны зашли: гарантируется, что время ожидания не превысит указанного. I>Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
нет, я про то, что эрланговские процессы могут не ждать окончания ожидания.
F>>даже питон действует похожим образом. он теперь тоже не подходит под современные оси? I>Не любой, а Stackless Python. Я про него не сильно знаю.
я про подсчёт "тиков" интерпретатора. у питона оно тоже есть.
F>>всё равно дедлоки остались проблемой при создании жава-приложений. I>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить.
I>В винде ничего этого нет, а та же инверсия приорититов 'решается' варварским методом — ос пингует все спящие потоки, просто на всякий случай.
Здравствуйте, neFormal, Вы писали:
I>>Это одно и то же, что время отклика, что время ожидания. При этом гарантии даёт в основном хостовая ось.
F>нет, я про то, что эрланговские процессы могут не ждать окончания ожидания.
Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
I>>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной.
F>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить.
При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
M>>Нативные потоки ОСи, доступные из Эрланга — это не приоритетное направление. Это одна их возможностей, которые добавят к языку. Года через два. А то и три. Это у них в roadmap long term: https://twitter.com/ruerlang/status/476397497863405569
I>Чисто между прочим — я вообще ничего не говорил про "нативные потоки доступные из Эрланга".
Да-да. Ты писал следующую бредятину:
В эрланге, что характерно, это (нативные треды — М.) основное направление развития.
Единственное, что есть в якобы приоритетном направлении — это нативные процессы в дальнем роадмапе, среди прочих пунктов. Завязывай нести чушь о вещах, в которых ты не разбираешься.
I>дать больше, чем хостовая ось эрланг не сможет, а нынешние оси писали без учета потребностей эрланга I>Эту мульку быстро поняли в джаве и отказались. В эрланге это основа платформы, рантайм берет на себя все мыслимы и немыслимые оптимизации
Практически единственное, что нужно Эрлангу от хостовой ОСи — это то, как быстро хостовая ОСь может отдавать/получать данные по сокету (так как Эрланг — в основном для распределенных приложений).
VM достаточно умна, чтобы минимизировать по максимуму переключения даже контекстов ядер, не то что потоков в системе (и это вдобавок еще и настраивается кучей параметров).
Поэтому Erlang вполне может именно что гарантировать soft realtime практически на любой хостовой ОСи. Вне зависимости от того, что думают об этом ничего не знающие про Эрланг люди.
Здравствуйте, Mamut, Вы писали:
I>>Чисто между прочим — я вообще ничего не говорил про "нативные потоки доступные из Эрланга".
M>Да-да. Ты писал следующую бредятину: M>
M>В эрланге, что характерно, это (нативные треды — М.) основное направление развития.
Ты пойми простую вещи — я не слежу за Эрлангом и про "нативные потоки доступные из Эрланга" узнал от тебя в этом треде.
Так понятно ?
M>Единственное, что есть в якобы приоритетном направлении — это нативные процессы в дальнем роадмапе, среди прочих пунктов. Завязывай нести чушь о вещах, в которых ты не разбираешься.
Ты наверное любой текст понимаешь только так, как тебе хочется.
Здравствуйте, Mamut, Вы писали:
M>Практически единственное, что нужно Эрлангу от хостовой ОСи — это то, как быстро хостовая ОСь может отдавать/получать данные по сокету (так как Эрланг — в основном для распределенных приложений).
Это безграмотное утверждение. Любой процесс искаропки использует целую кучу системных возможностей. Например нужно выделять память. Хочешь или нет, но это вызов ядра. Далее, у тебя нет никакого контроля над оперативной памятью — винда даёт тебе виртуальную и ты не знаешь, что это, файл или чипы. Отсюда ясно, что дисковый ввод-вывод практически неизбежен.
M>VM достаточно умна, чтобы минимизировать по максимуму переключения даже контекстов ядер, не то что потоков в системе (и это вдобавок еще и настраивается кучей параметров).
Если хостовая ОС не даёт гарантий, то VM в самом идеальном случае даст ровно тот же результат — отсутствие гарантий. Самый простой пример — ОС не переключает контекст и эрланговый поток не выполняется.
Вопрос — как VM эрланга заборет такую проблему ?
M>Поэтому Erlang вполне может именно что гарантировать soft realtime практически на любой хостовой ОСи. Вне зависимости от того, что думают об этом ничего не знающие про Эрланг люди.
Ты в курсе, что винда вообще не гарантирует, когда же контекст переключит и еще меньше гарантирует, когда нативный поток вернет управлени ? Ты в курсе, что у ней вытесняющая многозадачность ?
Для того, что бы изменить хоть как то такой расклад, VM эрланга должна в обязательном порядке вмешитьвася в работу виндовского ядра, драйверов и шедулера. Вот скажем те же сокеты требуют работу с сетью, а значит задействую чуть не всё ядро винды.
Все что ты можешь сделать на винде —
1. отключить вообще всё — приложения, сервисы, драйверы
2. увеличить по максимуму память, запретить использование свопа
3. вырубить на материнке вообще всё железо, кроме сетевого, а то железо может пользоваться шиной само по себе, даже без драйверов.
4. повысить приоритет потока эрланга до realtime(теоретически, предположим, никаких проблем это не повлечет)
Самое смешное, что даже с такими приседаниями винда принципиально не даёт никаких гарантий !
P.S. soft realtime это для тех кастомеров, которые позволяют себе лапшу на уши вешать.
P.P.S. Для тех, кто плохо умеет под винду
while(TRUE)
{
::Sleep(100);
}
Внимание — реальное время выполнения каждой итерации может варьироваться от 100мс до бесконечности.
Никакой эрланг здесь ничего принципиально не изменит и изменить не может.
Здравствуйте, Ikemefula, Вы писали:
I>Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям.
я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень.
I>>>На агентах/событиях есть ровно та же проблема, только её не называют дедлоком. Потоки необязательно останавливаются, просто часть входных запросов окажется необработаной. F>>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить. I>При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
дедлоки на блокирующих вызовах? да, они действительно бывают.
но их несложно отловить. отвалится вызов по таймауту, а в стектрейсе будет причина.
там хотя бы сразу ясно, что нужно сделать для разруливания проблемы.
с мутехами, которые захватываются в разных местах, куда сложнее понять, как распутать узел желаний кодеров.
мы далековато ушли в сторону от темы, поэтому напомню:
1. на фп можно геймдевить
2. бэкэнды писать на фп проще, чем морду
3. сложнее выработать методики разработки и научить людей
Здравствуйте, neFormal, Вы писали:
I>>Это не важно, ожидают они, или сообщениями обмениваются. Принципиальной разницы нет, только форма многозадачности разная.
F>неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям. F>я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень.
С акторами все тоже, только в профиль и отловить почти невозможно.
F>>>несколько странно сравнивать дедлоки с переполнением буфера. последний-то можно легко в рантайме почистить. I>>При чем здесь переполнение буфера ? На акторах точно так же возникат проблемаа аналогичная дедлокам. При чем в отличие от дедлоков её гораздо сложнее изловить.
F>дедлоки на блокирующих вызовах? да, они действительно бывают.
Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты.
Почему именно так — вопрос не ко мне, не я это дизайнил.
Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
Если у нас модель акторов, то в зависимости от сложности(квалификации девелопера) можно получить целую кучу проблем. Аналог дедлока в этом случае такой — два актора шлют сообщения друг другу. Даже если вызовы неблокирующие, мы получаем проблему как с дедлоками, только вариаций больше
1 потоки спят — как с дедлоком, потому что ктото 'забыл' инициировать продолжение
2 потоки вовсю кочегарят — сообщения бегают по кругу
3 потоки работают, только некоторые логически цепочки "повисают"
4 и тд
Здравствуйте, Ikemefula, Вы писали:
F>>неконтролируемых захват разделяемых ресурсов приводит к печальным последствиям. F>>я просто был свидетелем подобного пару раз. на ровном месте. от того что дизайн был не очень. I>С акторами все тоже, только в профиль и отловить почти невозможно.
ну, это кому как. по мне, так локи на акторах отловить проще.
I>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>Почему именно так — вопрос не ко мне, не я это дизайнил. I>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
Здравствуйте, neFormal, Вы писали:
I>>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>>Почему именно так — вопрос не ко мне, не я это дизайнил. I>>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
F>захватывать весь процесс писателя?
А что значит "захватывать весь процесс писателя" с тз того же Эрланга ?
Здравствуйте, Ikemefula, Вы писали:
F>>захватывать весь процесс писателя? I>А что значит "захватывать весь процесс писателя" с тз того же Эрланга ?
эм, ну, можно сделать пул процессов-писателей(ПП), который будет возвращать pid и блокировать его от других желающих.
или просто послать в ПП сообщеньку begin, после получения которой он будет отпинывать сообщения от всех процессов, кроме текущего владельца.
те, кто не смог получить доступ, попробуют повторить попытку через некий таймаут.
Здравствуйте, neFormal, Вы писали:
F>эм, ну, можно сделать пул процессов-писателей(ПП), который будет возвращать pid и блокировать его от других желающих. F>или просто послать в ПП сообщеньку begin, после получения которой он будет отпинывать сообщения от всех процессов, кроме текущего владельца.
F>те, кто не смог получить доступ, попробуют повторить попытку через некий таймаут.
Здесь, в кратце, вместо простого мутекса вырастает или пул, или сложная логика пинания-отпинывания-блокирования. Собственно такой пул превращается фактически в асинхронный вариант того же мутекса, только он становится размазаным по коду. Как именно это облегчит отслеживание ошибки до конца не ясно.
Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
Здравствуйте, Ikemefula, Вы писали:
I>Здесь, в кратце, вместо простого мутекса вырастает или пул, или сложная логика пинания-отпинывания-блокирования. Собственно такой пул превращается фактически в асинхронный вариант того же мутекса, только он становится размазаным по коду.
ничего там не размазано
но я понимаю, что у вас там одна дырка, и ради неё делать пул смысла нет(хотя это ещё надо подумать).
сравнивать же два различных подхода применительно к одной частной проблеме, как минимум, странно.
да, там нет таких примитивов синхронизации, потому что они там не нужны. а в жаве нет ф-ции main и нужно писать целый класс, чтобы вывести `hello world`
I>Как именно это облегчит отслеживание ошибки до конца не ясно.
а ты не примешивай поиск дедлока к этой задаче.
I>Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
я не знаю нюансов вашей системы, поэтому могу говорить лишь сферически.
например, мне не нравится, что в случае с мутехами непонятно поведение, если мутех не освободят. а что, если ваш сторадж сетевой и отваливается периодически?
вопросов много, по ним принимается решение. вы для себя выбрали.
Здравствуйте, Ikemefula, Вы писали:
I>Я про другое, задача доступа к общему ресурсу есть вне зависимости от того, какая форма многозадачности используется. Вот у нас есть некоторый сторадж, в который запись строго упорядочена. Протокол такой — писатель начинает c begin, свой id, кучку данных, end. Мулька в том, что в этот сторадж пишут разные процессы. Читать можно тольков том случае, если все begin закрыты. I>Почему именно так — вопрос не ко мне, не я это дизайнил.
I>Вопрос — каким образом им всем синхронизироваться ? В С++ мы тупо захватываем мутекс и пишем/читаем до посинения, потом отпускаем мутекс.
I>Если у нас модель акторов, то в зависимости от сложности(квалификации девелопера) можно получить целую кучу проблем. Аналог дедлока в этом случае такой — два актора шлют сообщения друг другу. Даже если вызовы неблокирующие, мы получаем проблему как с дедлоками, только вариаций больше I>1 потоки спят — как с дедлоком, потому что ктото 'забыл' инициировать продолжение I>2 потоки вовсю кочегарят — сообщения бегают по кругу I>3 потоки работают, только некоторые логически цепочки "повисают" I>4 и тд
Почему просто не поставить очередь перед писателем? Так эту проблему решает CSP, так же можно решить эту проблему и здесь.
Более того, обычно в эрланге дизайн приложения строится немного по-другому: у нас есть супервайзер, который смотрит за рабочими процессами, если рабочий процесс за указанное время не осилил транзакцию, то он будет запущен снова, если это предусматривается. Сообщение наверх имеет смысл отправлять только в случае успешного завершения или смерти по таймауту.
Здравствуйте, neFormal, Вы писали:
F>а ты не примешивай поиск дедлока к этой задаче.
В этой задаче нет именно дедлока, потому ничего подмешать не получится Есть просто другая проекция той же проблемы — работа с общим ресурсом.
I>>Вообще вариантов внятной реализации много и все они, фактически, есть небольшая СМО с кучей индивидуальных свойств.
F>я не знаю нюансов вашей системы, поэтому могу говорить лишь сферически. F>например, мне не нравится, что в случае с мутехами непонятно поведение, если мутех не освободят.
Поведение как раз понятно — если не освободят, значит все потоки будут зависать на нём. Юзер-реквесты будут повисать или отваливаться по таймауту. Что касается юзер-реквестов то тоже самое будет скажем в эрланге если накосячить с пулом.
Если тот же сторадж будет отваливаться по разным причинам, то это добавляет пикантности в обоих случаях.
У акторов есть одно большое преимущество — они масштабируются. Тупо потому, что не прибиты гвоздями к кусочку памяти, как мутекс. Кроме того, акторы хорошо подстраиваются под формальные модели, то есть, человеку с должной квалификацией будет гораздо комфортнее.
Здравствуйте, m.aksenov, Вы писали:
MA>Почему просто не поставить очередь перед писателем? Так эту проблему решает CSP, так же можно решить эту проблему и здесь.
Мы говоли не про то, как надо писать, а сравнивали возможные проблемы из за некорректного кода.
Дедлок == некорректный код. Я привел его аналог, т.е. некорректное решения в модели акторов.
Здравствуйте, 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<#)
