Вы читаете iamjaph

   Journal    Friends    Archive    Profile    Memories
 

iamjaph

фев. 8, 2015 05:54 am Путин признал Россию агрессором

Путин в очередной раз признал Россию агрессором. Обратите внимание, как он говорит: "не позволим СДЕРЖИВАТЬ геополитические интересы России". Именно сдерживать, а не ущемлять.

Оставить комментарий

дек. 20, 2013 10:49 am Договор с Европой, - это колониальный договор. Украина одумайся!!!

1 комментарий - Оставить комментарий

авг. 22, 2012 10:29 am GHC и Perl benchmark в свете CPU и разрядности OS

Есть у меня одно старое приложение в полтысячи строк реализованное на 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.

Метки: ,

Оставить комментарий

июн. 12, 2012 11:13 am Прагматизм и Haskell

Два года назад 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 дают не производительность не хуже

Метки: ,

7 комментариев - Оставить комментарий

дек. 26, 2011 10:37 am Ищется Дед Мороз со знанием Haskell

Не принес мне Haskell под новый год подарок :-(

После успешного проекта под названием RedisSharding, решил я сделать второй также на Haskell, а не на Perl.

Задача: как можно быстрей загрузить и распарсить множество HTML страниц - Web Shpider.

Как раз задача для Haskell, поскольку у него самые легкие потоки, а задача легко параллелиться.
Читать дальше...Свернуть )

Наверно, придется взять Perl, Coro, и сделать просто и эффективно!
Тем более, что Marc Lehmann этим летом пофиксил один нехороший момент в связке Coro и AnyEvent.

Или может подоспеет "помощь зала"?

Метки: ,

38 комментариев - Оставить комментарий

июн. 29, 2011 10:03 am Почему Haskell

Haskell - простой и мощный язык, позволяющий с легкостью описывать высокоуровневые абстракции.

Простота языка, ленивость и легковесные потоки позволяют без труда использовать data flow execution стиль.

А data flow execution стиль настолько удобен по сравнению с message passing cтилем, насколько последней удобен по сравнению с голым event-driving programming.

Яркие представители стилей:
* data flow execution - Mozart-OZ
* message passing - Erlang
* event-driving programming - все, с нормальной лямбдой (без нее можно, но не совсем удобно).

Метки: , ,

Оставить комментарий

июн. 1, 2011 11:08 am Как говориться, с почином

Можете поздравить меня с почином. Даже с двойным.
1. Написал свое первое приложение на haskell.
2. Оно (приложение-сервер) уже 3 дня работает на боевых серверах.

P.S.
Тьфу, тьфу, тьфу, чтобы не сглазить.

Метки:

1 комментарий - Оставить комментарий

май. 13, 2011 12:00 pm Знакомство с 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 настолько прост, что многим трудно это осознать.

Метки: , ,

1 комментарий - Оставить комментарий

фев. 18, 2011 04:04 pm Расправил крылья

Расправил крылья.
Около месяца понадобилось, чтобы разобраться с Haskell.
Львиная часть этого времени пошла чтобы расставаться с заблуждениями, полученными ранее от эпизодического чтения всякой фигни про монады.

Как это удалось сделать?
Во первых, заставил себя забыть о Haskell и монадах.
Во вторых, представил реализацию ленивого языка и способы задания порядка обмена информацией с внешним миром.

Когда вспомнил вновь о Haskell - первая мысль была: "зачем же в Haskell это сделано так сложно"? Спасибо http://nponeccop.livejournal.com за ссылки на первоисточники, которые помогли понять, что не так то и сложно это сделано, как кажется при чтении руководств, пытающихся объяснить все по простому.

Замечание. Ленивость может быть реализована при помощи санок или продолжение. В Haskell используются санки.
Санки - это функция, которая возвращается вместо результата ленивой функции.

Метки:

Оставить комментарий

янв. 12, 2011 09:36 am Redis Sharding

Redis Sharding is a multiplexed proxy-server, designed to work with the database divided to several servers. It's a temporary substitution of Redis Cluster (http://redis.io) that is under development.

https://github.com/kni/redis-sharding

Оставить комментарий

Back a Page