![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
От Haskell к Standard ML
Dec. 1st, 2016 11:55 amОт Haskell к Standard ML: http://by-need.blogspot.com/2016/12/haskell-standard-ml.html
Haskell: ошибка в Mio...
Nov. 29th, 2016 09:32 amКажется, в Mio ("Scalable IO Manager") есть ошибка.
Mio - это IO менеджер для threaded режима в GHC 7.8 и выше.
В сервере, при превышении определенного размера данных, происходит зависание треда.
Mio считает, что писать в сокет еще нельзя, а на самом деле можно.
Проверил на GHC 7.8.[34] и 8.0.1.
В не-threaded режиме зависания нет, все работает.
А ведь считал, что основное преимущество Haskell - это "зеленые нитки" с многопроцессорностью при высокой скорости. А тут, оказывается...
Mio - это IO менеджер для threaded режима в GHC 7.8 и выше.
В сервере, при превышении определенного размера данных, происходит зависание треда.
Mio считает, что писать в сокет еще нельзя, а на самом деле можно.
Проверил на GHC 7.8.[34] и 8.0.1.
В не-threaded режиме зависания нет, все работает.
А ведь считал, что основное преимущество Haskell - это "зеленые нитки" с многопроцессорностью при высокой скорости. А тут, оказывается...
Haskell не перестает удивлять меня!
Есть старый проект https://github.com/kni/redis-sharding-hs-strict.
В нем для определение типа команды используется поиск по списку пар:
https://github.com/kni/redis-sharding-hs-strict/blob/master/RedisSharding.hs#L59
Давном-давно![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
thesz посоветовал заменить это на дата-тип.
Заменил на:
Ожидал рост производительности, но получил ухудшение на 20-25%!
Измерял при следующих условиях, и, разумеется несколько раз и разной очередности:
Вот результат профилирования (при профилировании замедление меньше).
Старая версия:
А вот - новая с data CmdType:
Почему?!
UPDATE.
Загвоздка была, в том, что cmdType, так как много строк, поместил в другой файл, а не в тот, где case cmdType cmd of
И Haskell не смог оптимизировать. Когда все слил в один - скорость вернулась!!!
Есть старый проект https://github.com/kni/redis-sharding-hs-strict.
В нем для определение типа команды используется поиск по списку пар:
https://github.com/kni/redis-sharding-hs-strict/blob/master/RedisSharding.hs#L59
Давном-давно
thesz посоветовал заменить это на дата-тип.Заменил на:
data CmdType =
CmdToAll -- На все сервера
| CmdToOne -- На конкретные сервер
| CmdToMany -- На множество серверов. CMD key1 ... keyN
| CmdToManyValues -- На множество серверов. CMD key1 value1 ... keyN valueN
| CmdToManyTimeout -- На множество серверов. CMD key1 ... keyN timeout (блокирующие команды)
cmdType "PING" = Just CmdToAll
cmdType "AUTH" = Just CmdToAll
....
Ожидал рост производительности, но получил ухудшение на 20-25%!
Измерял при следующих условиях, и, разумеется несколько раз и разной очередности:
cpuset -l 0 ./redis_sharding --port=8090 --nodes=127.0.0.1:8081,127.0.0.1:8082,127.0.0.1:8083,127.0.0.1:8084 +RTS -s -N1 -A10M -qa redis-benchmark -p 8090 -n 10000 -c 10 -q -t set,get,mset -P 10
Вот результат профилирования (при профилировании замедление меньше).
Старая версия:
COST CENTRE MODULE %time %alloc throwSocketErrorIfMinus1RetryMayBlock Network.Socket.Internal 12.2 0.5 endOfLine Data.Attoparsec.ByteString.Internal 11.5 7.5 servers_sender RedisSharding 10.0 13.2
А вот - новая с data CmdType:
COST CENTRE MODULE %time %alloc cmdType RedisParser 12.5 12.4 throwSocketErrorIfMinus1RetryMayBlock Network.Socket.Internal 11.9 0.4 endOfLine Data.Attoparsec.ByteString.Internal 9.2 6.4
Почему?!
UPDATE.
Загвоздка была, в том, что cmdType, так как много строк, поместил в другой файл, а не в тот, где case cmdType cmd of
И Haskell не смог оптимизировать. Когда все слил в один - скорость вернулась!!!
Haskell - что-то с ленью все таки не то...
http://by-need.blogspot.com/2016/09/lazy-bytestring-haskell.html
http://by-need.blogspot.com/2016/09/lazy-bytestring-haskell.html
Есть у меня одно старое приложение в полтысячи строк реализованное на Haskell и на Perl.
На старых процессорах: "Intel(R) Xeon(TM) CPU 2.66GHz", "AMD Sempron(tm) Processor 2800+", - Haskell быстрей Perl в 4.2 раза. Но на относительно новом ноутбучном "Intel(R) Pentium(R) CPU P6200 @ 2.13GHz" разница уже составляет 5.7 раз. Это на FreeBSD 9.0 32bit. Версия Perl - 5.12, из FreeBSD package.
Далее для AMD Sempron(tm) Processor 2800+.
Если поменять 32bit архитектуру на 64bit, Perl ускоряется в 1.2 раза, что связано с использованием use64bitint под 32bit архитектурой. Для GHC 7.4.2 наоборот наблюдается небольшое снижение производительности: 1.08. Для GHC 7.0.3 скорость не зависит от разрядности архитектуры.
GHC 7.4.2 быстрей GHC 7.0.3 в 1.13 раза под 32bit и в 1.05 под 64bit.
На старых процессорах: "Intel(R) Xeon(TM) CPU 2.66GHz", "AMD Sempron(tm) Processor 2800+", - Haskell быстрей Perl в 4.2 раза. Но на относительно новом ноутбучном "Intel(R) Pentium(R) CPU P6200 @ 2.13GHz" разница уже составляет 5.7 раз. Это на FreeBSD 9.0 32bit. Версия Perl - 5.12, из FreeBSD package.
Далее для AMD Sempron(tm) Processor 2800+.
Если поменять 32bit архитектуру на 64bit, Perl ускоряется в 1.2 раза, что связано с использованием use64bitint под 32bit архитектурой. Для GHC 7.4.2 наоборот наблюдается небольшое снижение производительности: 1.08. Для GHC 7.0.3 скорость не зависит от разрядности архитектуры.
GHC 7.4.2 быстрей GHC 7.0.3 в 1.13 раза под 32bit и в 1.05 под 64bit.
Прагматизм и Haskell
Jun. 12th, 2012 11:13 amДва года назад Haskell привлек меня своей отличной поддержкой параллельных вычислений и "ну не может быть call-by-need язык настолько сложным, как о нем говорят". Erlang после OZ "не пошел".
О Haskell также говорят, что это академический язык, мало пригодный на практике.
Как не пригодный? Ведь для него так много библиотек. Я мне много и не надо: поддержка работы с kqueue (epoll), LWP аналог, DBI, JSON и HTML парсеры.
Так как поддержка kqueue (epoll) появилась в GHC 7.x, то я взял Haskell и написал свое первое приложение. Правда для подстраховки перед этим сделал Perl вариант. Perl хорош тем, что дает много свободного рабочего времени, чтобы заняться Haskell. С третьей попытки Haskell версия стала выглядеть не хуже Perl версии, и даже немного лучше, и имела производительность в два раза выше. Но из-за кривой Python библиотеки, используемой клиентом, пришлось на сервере включить буферизацию и производительность упала в эти два раза. Но зато осталось отличное использование памяти. Все стлало работать отлично, после того как разработчики GHC сообщили, что kqueue в GHC 7.0.1 по умолчанию не используется, а активируется косвенно в threaded режиме.
Но вернемся к Haskell. Haskell в первую очередь академический язык. А в академиях свои порядки: в год необходимо опубликовать не меньше столько-то статей, размер диссертации должен быть не меньше столько-то страниц, литературных источников нужно не меньше такого-то количества. А кто их все читает эти литературные источники, в большинства случаев? Так, по парочки страниц в каждом.
Такое впечатления, что те, кто пишут на Haskell, по диагонали читают статьи и о самом Haskell. Это относиться, к сожалению, и к авторам base пакета. Чувствую, что преувеличиваю, но факт остается фактом: используя совет из документации, сразу словил ситуацию гонки. Хорошо, что недавно читал статью про асинхронные исключению. Но это прошлое, написанный сервер без проблем работает полтора года, так что вернемся в настоящие.
С быстрым HTML парсером мне помог vshabanov.livejournal.com, большое спасибо ему.
Сейчас мне нужно работать с базами данных (Pg и MySql). Для работы с базами рекомендуют использовать HDBC и Takusen, но в последнем нет поддержки MySql. Недавно появились postgresql-simple и mysql-simple. Берем проверенный временем HDBC, о котором написано, что он сделан по образу и подобию Perl DBI, но лучше, так как использовался опыт Python's DB-API v2, JDBC in Java.
Ой! Где в HDBC поддержка prepared statement на стороне сервера?! Я не требую поддержки асинхронность, которая давно есть в Perl DBD::Pg и в упрошенном, но достаточном виде, 2 года как появилась в DBD::mysql и самом DBI. Я хочу лишь поддержку prepared statement на стороне сервера, баз которой быстрая работа с базами данных не возможна.
Справедливости надо сказать, что в Takusen есть поддержка prepared statement на стороне сервера и для PostgreSQL, и для Oracle.
Но как-же HDBC? Для postgresql нет вообще, а для mysql, сюрприз, есть. Но какая. После execute сразу вызывается mysql_stmt_close, что делает все prepared statement одноразовыми. Да и самом HDBC не предусмотрена поддержка этого. Чтобы ее добавить придется согласовать действия автором всех HDBC пакетов.
Если сравнивать с Perl DBI, то такое ощущение, что вернулся в прошлое.
Что делать? Какие меня ждут впереди неприятные сюрпризы от Haskell? Стоит время тратить на Haskell или использовать Perl с IPC::MPS, EV, Coro и DBI?
Ведь имея IPC::MPS, который я написал по мотивам Erlang и OZ, и при наличии MultiAgent (Multiplicative Agent поверх IPC::MPS), написанного с оглядкой на OZ, с учетом их интеграции с EV и Сoro, мой Cloud Perl не хуже, чем Cloud Haskell. :-)
Ну, что же с тобой делать, Haskell? Стоит ли твой игра свеч? Я в замешательстве и раздумьях...
P.S.
Оказывается в Python библиотеках также не используется prepared statement на стороне сервера.
Теперь понятно, почему люди говорят, что NoSQL быстрей YesSQL, а мои тесты говорят, что PgSql и MySql дают не производительность не хуже
О Haskell также говорят, что это академический язык, мало пригодный на практике.
Как не пригодный? Ведь для него так много библиотек. Я мне много и не надо: поддержка работы с kqueue (epoll), LWP аналог, DBI, JSON и HTML парсеры.
Так как поддержка kqueue (epoll) появилась в GHC 7.x, то я взял Haskell и написал свое первое приложение. Правда для подстраховки перед этим сделал Perl вариант. Perl хорош тем, что дает много свободного рабочего времени, чтобы заняться Haskell. С третьей попытки Haskell версия стала выглядеть не хуже Perl версии, и даже немного лучше, и имела производительность в два раза выше. Но из-за кривой Python библиотеки, используемой клиентом, пришлось на сервере включить буферизацию и производительность упала в эти два раза. Но зато осталось отличное использование памяти. Все стлало работать отлично, после того как разработчики GHC сообщили, что kqueue в GHC 7.0.1 по умолчанию не используется, а активируется косвенно в threaded режиме.
Но вернемся к Haskell. Haskell в первую очередь академический язык. А в академиях свои порядки: в год необходимо опубликовать не меньше столько-то статей, размер диссертации должен быть не меньше столько-то страниц, литературных источников нужно не меньше такого-то количества. А кто их все читает эти литературные источники, в большинства случаев? Так, по парочки страниц в каждом.
Такое впечатления, что те, кто пишут на Haskell, по диагонали читают статьи и о самом Haskell. Это относиться, к сожалению, и к авторам base пакета. Чувствую, что преувеличиваю, но факт остается фактом: используя совет из документации, сразу словил ситуацию гонки. Хорошо, что недавно читал статью про асинхронные исключению. Но это прошлое, написанный сервер без проблем работает полтора года, так что вернемся в настоящие.
С быстрым HTML парсером мне помог vshabanov.livejournal.com, большое спасибо ему.
Сейчас мне нужно работать с базами данных (Pg и MySql). Для работы с базами рекомендуют использовать HDBC и Takusen, но в последнем нет поддержки MySql. Недавно появились postgresql-simple и mysql-simple. Берем проверенный временем HDBC, о котором написано, что он сделан по образу и подобию Perl DBI, но лучше, так как использовался опыт Python's DB-API v2, JDBC in Java.
Ой! Где в HDBC поддержка prepared statement на стороне сервера?! Я не требую поддержки асинхронность, которая давно есть в Perl DBD::Pg и в упрошенном, но достаточном виде, 2 года как появилась в DBD::mysql и самом DBI. Я хочу лишь поддержку prepared statement на стороне сервера, баз которой быстрая работа с базами данных не возможна.
Справедливости надо сказать, что в Takusen есть поддержка prepared statement на стороне сервера и для PostgreSQL, и для Oracle.
Но как-же HDBC? Для postgresql нет вообще, а для mysql, сюрприз, есть. Но какая. После execute сразу вызывается mysql_stmt_close, что делает все prepared statement одноразовыми. Да и самом HDBC не предусмотрена поддержка этого. Чтобы ее добавить придется согласовать действия автором всех HDBC пакетов.
Если сравнивать с Perl DBI, то такое ощущение, что вернулся в прошлое.
Что делать? Какие меня ждут впереди неприятные сюрпризы от Haskell? Стоит время тратить на Haskell или использовать Perl с IPC::MPS, EV, Coro и DBI?
Ведь имея IPC::MPS, который я написал по мотивам Erlang и OZ, и при наличии MultiAgent (Multiplicative Agent поверх IPC::MPS), написанного с оглядкой на OZ, с учетом их интеграции с EV и Сoro, мой Cloud Perl не хуже, чем Cloud Haskell. :-)
Ну, что же с тобой делать, Haskell? Стоит ли твой игра свеч? Я в замешательстве и раздумьях...
P.S.
Оказывается в Python библиотеках также не используется prepared statement на стороне сервера.
Теперь понятно, почему люди говорят, что NoSQL быстрей YesSQL, а мои тесты говорят, что PgSql и MySql дают не производительность не хуже
Ищется Дед Мороз со знанием Haskell
Dec. 26th, 2011 10:37 amНе принес мне Haskell под новый год подарок :-(
После успешного проекта под названием RedisSharding, решил я сделать второй также на Haskell, а не на Perl.
Задача: как можно быстрей загрузить и распарсить множество HTML страниц - Web Shpider.
Как раз задача для Haskell, поскольку у него самые легкие потоки, а задача легко параллелиться.
( Read more... )
Наверно, придется взять Perl, Coro, и сделать просто и эффективно!
Тем более, что Marc Lehmann этим летом пофиксил один нехороший момент в связке Coro и AnyEvent.
Или может подоспеет "помощь зала"?
После успешного проекта под названием RedisSharding, решил я сделать второй также на Haskell, а не на Perl.
Задача: как можно быстрей загрузить и распарсить множество HTML страниц - Web Shpider.
Как раз задача для Haskell, поскольку у него самые легкие потоки, а задача легко параллелиться.
( Read more... )
Наверно, придется взять Perl, Coro, и сделать просто и эффективно!
Тем более, что Marc Lehmann этим летом пофиксил один нехороший момент в связке Coro и AnyEvent.
Или может подоспеет "помощь зала"?
Почему Haskell
Jun. 29th, 2011 10:03 amHaskell - простой и мощный язык, позволяющий с легкостью описывать высокоуровневые абстракции.
Простота языка, ленивость и легковесные потоки позволяют без труда использовать data flow execution стиль.
А data flow execution стиль настолько удобен по сравнению с message passing cтилем, насколько последней удобен по сравнению с голым event-driving programming.
Яркие представители стилей:
* data flow execution - Mozart-OZ
* message passing - Erlang
* event-driving programming - все, с нормальной лямбдой (без нее можно, но не совсем удобно).
Простота языка, ленивость и легковесные потоки позволяют без труда использовать data flow execution стиль.
А data flow execution стиль настолько удобен по сравнению с message passing cтилем, насколько последней удобен по сравнению с голым event-driving programming.
Яркие представители стилей:
* data flow execution - Mozart-OZ
* message passing - Erlang
* event-driving programming - все, с нормальной лямбдой (без нее можно, но не совсем удобно).
Немного о себе
--------------
Никогда не думал, что стану программистом. Я химик по образованию. Но вот уже лет 11 как профессионально занимаюcь программированием на Perl (сайты НЕ делаю).
Мотивация
---------
Как-то подумалось, если я часто использую лишь функциональное подмножество языка языка Perl, то почему бы не взять для этих задач Haskell?
Аргумента "за":
- скорость программ;
- легковесные потоки, масштабируемые на множество CPU;
- автоматическая оптимизация хвостовой рекурсии (в Perl 5 делается руками, будет в Perl 6);
- COW (будет в Perl 6);
- автоматический карринг;
- не нужно писать лишние закорючки при работе с функциями, как с сущностями высшего порядка;
- тотальная ленивость.
Да, кстати, с выходом GHC 7 мы получили интеграцию легковесных потоков в kqueue и epoll.
Аргумент против один: страшные и ужасные загадочные монады.
Пытался читать о них 3 года назад. Какие-то космонавтики в скафандриках. Корзинки и ящички с яблоками и ягодами. Мир, разделенный на два части: чистых и не-чистых. Ничего не понял.
Не так страшен черт, как его малюют
-----------------------------------
После очередной неудачной попытки разобраться с монадами, почему они так нужны для IO в Haskell, плюнул на все это.
А в голове крутилась одна мысль. Я начал использовать ленивость на Perl этак лет 8-9 назад (тогда я не знал о Haskell).
Почему у меня не возникало проблем с IO? Ведь порядок общения с внешним миром легко определятся при помощи продолжений!
Стал сам разрабатывать простой ленивый язык и компилятор для него. Да что там разрабатывал - просто все, что делал на Perl вручную, делегировалась компилятору. На удивление система получалась простая.
Почему же в Haskell все так сложно?! Спасибо умные люди подкинули ссылки на пару статей, среди них "Call-by-need and Continuation-passing Style". После прочтения которых в голове все прояснилось. В Haskell тоже все просто! Читать надо первоисточники, а не перепевы.
Проверка в реальном деле
------------------------
Есть у меня мультиплексирующий прокси-сервер "Redis Sharding" (http://github.com/kni/redis-sharding).
Написан он на Perl, с использованием замыканий. Попробую я переписать его на Haskell.
Этот код состоит из двух частей. Одна часть занимается управлением сокетами, приемом и отправкой данных. Вторая часть - это анализ и преобразование данных. Это части достаточно не зависимы и связаны между собой колбеками, вызовы которых приводят к изменению данных в замыканиях.
Сначала взялся как обычно за самую трудную часть: управление соединениями и потоками данных.
Код на Haskell показал производительность выше в 2 раза, но вот объем кода в строках был в 1.5 раза больше, а в словах в 2 раза.
Что для мене не приемлемо. Да и выглядело это вся ужасно.
После чего решил вместо изменяемых замыканий использовать легковесных потоки. Сделал такой себе маленьких Erlang на Haskell (слава Богу подобных опыт на Perl был). Клод стал чище, а количество срок стало таким как у Perl варианта, но не слов.
Но если управление дочерними потоками вынести в отдельную библиотеку, а я ведь буду часто его использовать, то объем кода можно считать одинаковым (в словах 7% не в пользу Haskell). Да, код стал чище, но появилось много потоков, я чтобы не запутаться пришлось даже написать описание взаимодействия между ними. Кстати скорость выполнения немного повысилась, так как библиотека для работы с сокетами заточена под многопоточность, что приводили в мультиплексирующем варианта к дублированию проверок на возможность читать-писать.
Теперь возьмемся за вторую часть: анализ и преобразование данных.
Мы работаем с непрерывным потоком данных, разбитым на логически завершенные куски (команды и ответы).
Поэтому, когда в распоряжении парсера нет всего необходимого объема данных для анализа текущего фрагмента, он в случае изменяемых замыканий сохраняет свое состоянии и ждет следующего своего вызова с порцией новых данных. В случай легковесных потоков, парсер засыпает на ожидании приема сообщения с новой порцией данных. Да второй вариант кажется проще, но это если не делать защиту от перегрузки данными в случае медленного чтения с сокетов на другой стороне. Надо контролировать размеры очередей с сообщениями. Не нравиться вся это. Но это пустяки по сравнением с тем, что в парсеры с новой порцией данных проникает IO.
И вот тут на помощь приходит ленивость и Network.Socket.ByteString.Lazy. Теперь парсер работает с данными, так как будто они уже все есть в наличие. Размер фрагмента второй части стал до безобразия маленьким. Даже не удобно сравнивать с энергичными языками. Разве что можно сравнивать с Mozart-OZ, в котором используется data-flow execution, но в нет пока нет поддержки ByteString.Lazy и kqueue/epoll. Благодаря этой части удалось догнать Perl вариант по выразительности и краткости кода.
Вывод
-----
Если использовать ленивый язык, то использовать ленивость по полной!
Не надо использовать изменяемые замыканий, когда есть легковесный потоки.
Не надо использовать напрямую System.Event - ведь есть легковесный потоки.
При соблюдении этих условий, на Haskell можно достигнуть выразительности и краткости кода не уступающей Perl.
Развеивая мифы и заблуждения
----------------------------
О Haskell существует множество мифов, о нем рассказывают множество небылиц. Попробуем разобраться где истина, а где заблуждения.
1. Необходимость ученой степени в области Computer science. Это не правда. Достаточно просто ученой степени. :-)
2. Сложность. Это тоже не правда. Haskell - простой и красивый язык. На столько простой, что на нем очень легко и удобно создавать высокоуровневые абстракции, простые и сложные. Последние, разумеется, затуманивают разум новичков и вводят в заблуждения о простоте и сложности самого языка.
3. Ужас монад... Даже и не хочется касаться этой темы. Скажу только одно: не читайте всякую фигню, читайте первоисточники.
Влияние же остальных мифов не так пагубно для присматривающихся к Haskell, поэтому их рассматривать не буду.
Какова же причина появления этих мифов и заблуждений? На ум приходит только одно: Haskell настолько прост, что многим трудно это осознать.
--------------
Никогда не думал, что стану программистом. Я химик по образованию. Но вот уже лет 11 как профессионально занимаюcь программированием на Perl (сайты НЕ делаю).
Мотивация
---------
Как-то подумалось, если я часто использую лишь функциональное подмножество языка языка Perl, то почему бы не взять для этих задач Haskell?
Аргумента "за":
- скорость программ;
- легковесные потоки, масштабируемые на множество CPU;
- автоматическая оптимизация хвостовой рекурсии (в Perl 5 делается руками, будет в Perl 6);
- COW (будет в Perl 6);
- автоматический карринг;
- не нужно писать лишние закорючки при работе с функциями, как с сущностями высшего порядка;
- тотальная ленивость.
Да, кстати, с выходом GHC 7 мы получили интеграцию легковесных потоков в kqueue и epoll.
Аргумент против один: страшные и ужасные загадочные монады.
Пытался читать о них 3 года назад. Какие-то космонавтики в скафандриках. Корзинки и ящички с яблоками и ягодами. Мир, разделенный на два части: чистых и не-чистых. Ничего не понял.
Не так страшен черт, как его малюют
-----------------------------------
После очередной неудачной попытки разобраться с монадами, почему они так нужны для IO в Haskell, плюнул на все это.
А в голове крутилась одна мысль. Я начал использовать ленивость на Perl этак лет 8-9 назад (тогда я не знал о Haskell).
Почему у меня не возникало проблем с IO? Ведь порядок общения с внешним миром легко определятся при помощи продолжений!
Стал сам разрабатывать простой ленивый язык и компилятор для него. Да что там разрабатывал - просто все, что делал на Perl вручную, делегировалась компилятору. На удивление система получалась простая.
Почему же в Haskell все так сложно?! Спасибо умные люди подкинули ссылки на пару статей, среди них "Call-by-need and Continuation-passing Style". После прочтения которых в голове все прояснилось. В Haskell тоже все просто! Читать надо первоисточники, а не перепевы.
Проверка в реальном деле
------------------------
Есть у меня мультиплексирующий прокси-сервер "Redis Sharding" (http://github.com/kni/redis-sharding).
Написан он на Perl, с использованием замыканий. Попробую я переписать его на Haskell.
Этот код состоит из двух частей. Одна часть занимается управлением сокетами, приемом и отправкой данных. Вторая часть - это анализ и преобразование данных. Это части достаточно не зависимы и связаны между собой колбеками, вызовы которых приводят к изменению данных в замыканиях.
Сначала взялся как обычно за самую трудную часть: управление соединениями и потоками данных.
Код на Haskell показал производительность выше в 2 раза, но вот объем кода в строках был в 1.5 раза больше, а в словах в 2 раза.
Что для мене не приемлемо. Да и выглядело это вся ужасно.
После чего решил вместо изменяемых замыканий использовать легковесных потоки. Сделал такой себе маленьких Erlang на Haskell (слава Богу подобных опыт на Perl был). Клод стал чище, а количество срок стало таким как у Perl варианта, но не слов.
Но если управление дочерними потоками вынести в отдельную библиотеку, а я ведь буду часто его использовать, то объем кода можно считать одинаковым (в словах 7% не в пользу Haskell). Да, код стал чище, но появилось много потоков, я чтобы не запутаться пришлось даже написать описание взаимодействия между ними. Кстати скорость выполнения немного повысилась, так как библиотека для работы с сокетами заточена под многопоточность, что приводили в мультиплексирующем варианта к дублированию проверок на возможность читать-писать.
Теперь возьмемся за вторую часть: анализ и преобразование данных.
Мы работаем с непрерывным потоком данных, разбитым на логически завершенные куски (команды и ответы).
Поэтому, когда в распоряжении парсера нет всего необходимого объема данных для анализа текущего фрагмента, он в случае изменяемых замыканий сохраняет свое состоянии и ждет следующего своего вызова с порцией новых данных. В случай легковесных потоков, парсер засыпает на ожидании приема сообщения с новой порцией данных. Да второй вариант кажется проще, но это если не делать защиту от перегрузки данными в случае медленного чтения с сокетов на другой стороне. Надо контролировать размеры очередей с сообщениями. Не нравиться вся это. Но это пустяки по сравнением с тем, что в парсеры с новой порцией данных проникает IO.
И вот тут на помощь приходит ленивость и Network.Socket.ByteString.Lazy. Теперь парсер работает с данными, так как будто они уже все есть в наличие. Размер фрагмента второй части стал до безобразия маленьким. Даже не удобно сравнивать с энергичными языками. Разве что можно сравнивать с Mozart-OZ, в котором используется data-flow execution, но в нет пока нет поддержки ByteString.Lazy и kqueue/epoll. Благодаря этой части удалось догнать Perl вариант по выразительности и краткости кода.
Вывод
-----
Если использовать ленивый язык, то использовать ленивость по полной!
Не надо использовать изменяемые замыканий, когда есть легковесный потоки.
Не надо использовать напрямую System.Event - ведь есть легковесный потоки.
При соблюдении этих условий, на Haskell можно достигнуть выразительности и краткости кода не уступающей Perl.
Развеивая мифы и заблуждения
----------------------------
О Haskell существует множество мифов, о нем рассказывают множество небылиц. Попробуем разобраться где истина, а где заблуждения.
1. Необходимость ученой степени в области Computer science. Это не правда. Достаточно просто ученой степени. :-)
2. Сложность. Это тоже не правда. Haskell - простой и красивый язык. На столько простой, что на нем очень легко и удобно создавать высокоуровневые абстракции, простые и сложные. Последние, разумеется, затуманивают разум новичков и вводят в заблуждения о простоте и сложности самого языка.
3. Ужас монад... Даже и не хочется касаться этой темы. Скажу только одно: не читайте всякую фигню, читайте первоисточники.
Влияние же остальных мифов не так пагубно для присматривающихся к Haskell, поэтому их рассматривать не буду.
Какова же причина появления этих мифов и заблуждений? На ум приходит только одно: Haskell настолько прост, что многим трудно это осознать.
Расправил крылья
Feb. 18th, 2011 04:04 pmРасправил крылья.
Около месяца понадобилось, чтобы разобраться с Haskell.
Львиная часть этого времени пошла чтобы расставаться с заблуждениями, полученными ранее от эпизодического чтения всякой фигни про монады.
Как это удалось сделать?
Во первых, заставил себя забыть о Haskell и монадах.
Во вторых, представил реализацию ленивого языка и способы задания порядка обмена информацией с внешним миром.
Когда вспомнил вновь о Haskell - первая мысль была: "зачем же в Haskell это сделано так сложно"? Спасибо http://nponeccop.livejournal.com за ссылки на первоисточники, которые помогли понять, что не так то и сложно это сделано, как кажется при чтении руководств, пытающихся объяснить все по простому.
Замечание. Ленивость может быть реализована при помощи санок или продолжение. В Haskell используются санки.
Санки - это функция, которая возвращается вместо результата ленивой функции.
Около месяца понадобилось, чтобы разобраться с Haskell.
Львиная часть этого времени пошла чтобы расставаться с заблуждениями, полученными ранее от эпизодического чтения всякой фигни про монады.
Как это удалось сделать?
Во первых, заставил себя забыть о Haskell и монадах.
Во вторых, представил реализацию ленивого языка и способы задания порядка обмена информацией с внешним миром.
Когда вспомнил вновь о Haskell - первая мысль была: "зачем же в Haskell это сделано так сложно"? Спасибо http://nponeccop.livejournal.com за ссылки на первоисточники, которые помогли понять, что не так то и сложно это сделано, как кажется при чтении руководств, пытающихся объяснить все по простому.
Замечание. Ленивость может быть реализована при помощи санок или продолжение. В Haskell используются санки.
Санки - это функция, которая возвращается вместо результата ленивой функции.
О чистоте и лени
Dec. 3rd, 2010 08:06 amПосле N-ной провальной попытки изучить Haskell и понять суть религии под названием "монадический фетишизм", решил изобрести свой "велосипед", то есть чистый и ленивый язык программирования.
Для любой открытой системы важным моментов является взаимодействие с внешним миром. В данном случаем - порядок обмена информацией.
У энергичных языков порядок определяется непосредственно самой последовательностью инструкций в программе. Напротив, для ленивых языков последовательность выполнения инструкций неопределена, а значения вычисляются по мере необходимости. Поэтому для осуществления взаимодействия с внешним миром в ленивые языки порядок вводиться искусственно.
Одним из способов упорядочивания вычислений является ввод дополнительных переменных-маркеров, при помощи которых указываются дополнительные зависимости между подпрограммами. Например, подпрограмма "C" зависит от переменной "b", которая определяется в подпрограмме "B", в свою очередь подпрограмма "B" зависит от переменной "a", значение которой определяется в подпрограмме "A", что приводит к выполнению сначала подпрограммы "A", затем "B" и лишь затем "C". Эти переменные маркеры в Mozart-OZ получили название свободные (unbound) переменные, а в Clean - уникальные типы.
Другим способом упорядочивание вычислений является использование стиля передачи продолжений. Однако этот стиль труден для использования им требует модификации подпрограмм. К счастью последнего можно избежать при помощи подпрограммы-обертки. В Haskell этой оберткой является оператор bind, а монады по сути не что иное, как своеобразный "концептуальный сахар" над стилем передачи продолжений. В свою очередь Haskell оператор do является "синтаксическим сахаром" вокруг монад, создающих иллюзию того, что переменные меняют свое значение.
Так что на самом деле Haskell, как и Clean, - абсолютно чистый язык, а религия "монадический фетишизм" - удел тех, кто на видеть разницы между иллюзией и реальностью.
P.S.
Во загнул! С другой стороны, что взять с простого физ-химика, волей случая написавшего несколько маленьких программ на Perl.
Для любой открытой системы важным моментов является взаимодействие с внешним миром. В данном случаем - порядок обмена информацией.
У энергичных языков порядок определяется непосредственно самой последовательностью инструкций в программе. Напротив, для ленивых языков последовательность выполнения инструкций неопределена, а значения вычисляются по мере необходимости. Поэтому для осуществления взаимодействия с внешним миром в ленивые языки порядок вводиться искусственно.
Одним из способов упорядочивания вычислений является ввод дополнительных переменных-маркеров, при помощи которых указываются дополнительные зависимости между подпрограммами. Например, подпрограмма "C" зависит от переменной "b", которая определяется в подпрограмме "B", в свою очередь подпрограмма "B" зависит от переменной "a", значение которой определяется в подпрограмме "A", что приводит к выполнению сначала подпрограммы "A", затем "B" и лишь затем "C". Эти переменные маркеры в Mozart-OZ получили название свободные (unbound) переменные, а в Clean - уникальные типы.
Другим способом упорядочивание вычислений является использование стиля передачи продолжений. Однако этот стиль труден для использования им требует модификации подпрограмм. К счастью последнего можно избежать при помощи подпрограммы-обертки. В Haskell этой оберткой является оператор bind, а монады по сути не что иное, как своеобразный "концептуальный сахар" над стилем передачи продолжений. В свою очередь Haskell оператор do является "синтаксическим сахаром" вокруг монад, создающих иллюзию того, что переменные меняют свое значение.
Так что на самом деле Haskell, как и Clean, - абсолютно чистый язык, а религия "монадический фетишизм" - удел тех, кто на видеть разницы между иллюзией и реальностью.
P.S.
Во загнул! С другой стороны, что взять с простого физ-химика, волей случая написавшего несколько маленьких программ на Perl.
