| Playdar: C++ → Erlang |
[Dec. 26th, 2009|08:42 pm] |
http://www.metabrew.com/article/rewriting-playdar-c-to-erlang-massive-savings/
Ричард Джонс переписал десктопное приложение Playdar с C++: Boost+ASIO на Erlang. Получил 75..92% сокращение кода. Смог создать дистрибутив для распространения приложения на десктопы: виндовый дистрибут занимал 2.5 метра, эрланговый — 10 метров.
Playdar is the future, and the future is written in Erlang :)
Справедливости ради надо отметить, что приложение у них малюсенькое — всего под десять тысяч строк [сиплюсплюсного] кода. Один RabbitMQ на эрланге занимает примерно столько.
Пока я здесь, замечу, что моя статья о проектировании эрланговского клиента к memcached сервису была опубликована в третьем выпуске fprog.ru. |
|
|
| Erlang, Yaws, and the deadly Tornado |
[Sep. 19th, 2009|12:42 am] |
Good things sometimes happen to the open source community. Since Facebook acquisition of FriendFeed, a bunch of technologies were released to the wild, including, most notably, a Tornado web server written in Python. The Tornado is touted as a «a scalable, non-blocking web server and web framework». See Wikipedia article http://en.wikipedia.org/wiki/Tornado_HTTP_Server on some details on the performance of that server, as well as some comparison with other web servers.
Here's the chart, taken from Wikipedia:
Performance on AMD Opteron, 2.4GHz, 4 Cores
| Server |
Setup |
Requests per Second |
| Tornado |
nginx, 4 frontends |
8213 |
| Tornado |
1 single threaded frontend |
3353 |
| Django |
Apache/mod_wsgi |
2223 |
| web.py |
Apache/mod_wsgi |
2066 |
| CherryPy |
standalone |
785 |
The numbers looked interesting, so I decided to benchmark Tornado myself to check out how it fares against some Erlang tools. ( Erlang, Yaws, Tornado benchmark follows ) |
|
|
| За Erlang могут задержать ФБР. |
[Jul. 5th, 2009|11:42 pm] |
http://zerohedge.blogspot.com/2009/07/is-case-of-quant-trading-industrial.html
Сергей Алейников был арестован ФБР в аэропорту за то, что креативно использовал Erlang/OTP для поддержки высокоскоростного автоматического трейдинга, и не смог с ним расстаться при увольнении. Или примерно за это. Вот кусок из его LinkedIn профиля:
Implemented a real-time monitoring solution for the distributed trading system using a combination of technologies (SNMP, Erlang/OTP, boost, ACE, TibcoRV, real-time distributed replicated database, etc) to monitor load and health of trading processes in the mother-ship and co-located sites so that trading decisions can be prioritized based on congestion and queuing delays.
А пока Goldman Sachs исчез из репортинга биржи NYSE. Был на первом месте, а теперь исчез, почти в связи с этим.
Russian immigrant living in New Jersey was being held on federal charges of stealing top-secret computer trading codes from a major New York-based financial institution—that sources say is none other than Goldman Sachs. http://blogs.reuters.com/commentaries/2009/07/05/a-goldman-trading-scandal/
The job he took in Chicago, according to the criminal complaint, paid nearly three times more than his $400,000 salary at Goldman.
400k$/y за Эрланг, anyone?
UPD: http://www.puppetmastertrading.com/blog/2009/07/08/the-other-interesting-thing-about-the-serge-aleynikov-story/
One angle that I haven’t seen highlighted in all of the commentary is Mr Aleynikov’s choice of weapon. Seems that he was an erlang guy with an interest in ocaml. Choosing functional programming for algo trading systems is an interesting but not unique choice.
A few months back I’d seen Jane St’s Yaron Minsky give an interesting talk on OCAML in which he describes the virtues of ocaml as applied to the algo trading domain. You should watch it as he’s entertaining and clearly a “true believer.” The key argument he makes is that algo trading requires correctness, agility and performance and that ocaml provides a great set of tools for addressing these needs. Correctness and agility are supported by the rich type system while performance is just a happy feature of the language. |
|
|
| Erlang ports |
[Jun. 15th, 2009|01:42 pm] |
Тем, кому интересна была скорость работы с портами в эрланге. Вот простейший пинг порта, реализованного на окамле. Порт занимается десериализацией Erlang External Term Format и возвращает ответ. Впрочем, в этом случае там с гулькин нос десериализовывать, ибо {ping} он и есть {ping}. Зато видна базовая производительность работы с портами.
4> perftest:comprehensive(1000, fun() -> portserver:ping(comments_diff) end).
Sequential 100 cycles in ~0 seconds (12337 cycles/s)
Sequential 200 cycles in ~0 seconds (2456 cycles/s)
Sequential 1000 cycles in ~0 seconds (8602 cycles/s)
Parallel 2 1000 cycles in ~0 seconds (4304 cycles/s)
Parallel 4 1000 cycles in ~0 seconds (25219 cycles/s)
Parallel 10 1000 cycles in ~0 seconds (5513 cycles/s)
Parallel 100 1000 cycles in ~0 seconds (26553 cycles/s)
[8602,4304,25219,5513,26553]
5> perftest:sequential(100000, fun() -> portserver:ping(comments_diff) end).
Sequential 100000 cycles in ~11 seconds (9132 cycles/s)
9132
6>
8-25 тысяч раунд-трипов в секунду, устойчиво 9k/s на одном потоке.
Если бы CPU занималось по полной, я бы не удивился — нормальные цифры. Но так как CPU было загружено далеко не полностью, понятно что где-то в районе евент-менеджмента собака зарыта. beam и ocaml грузят проц примерно поровну: 4-6% на каждого. Копать не буду, меня такие цифры устраивают. |
|
|
| Amazon EC2 Large vs. Small instances |
[Apr. 22nd, 2009|08:42 pm] |
Измерил разницу производительности "large" и "small" инстансов, используя Ant тест.
Small — это один виртуальный процессор AMD, 2.6 GHz (похоже, из двух процессоров в системе) Large — это два виртуальных процессора AMD, 2.0 GHz (похоже, из четырёх процессоров в системе)
| Test name | Large, SMP, bytecode | Large, single, bytecode | Small, bytecode | Производительность small от large |
|---|
| Sequential ant | 589 | 590 | 342 | ~58% | | Parallel ant | 88 | 47 | 28 | ~31% если Large в SMP режиме, иначе ~59% |
В Native режиме цифры small instance, соответственно, 365 и 28, а SMP эрланг на small смысла не имеет, поэтому на нём ничего не замерялось.
- К вопросу о быстродействии Erlang (2007-10-31)
- Обновил табличку (2007-11-15)
- JS-Kit, Erlang, Amazon EC2 (2009-03-10)
|
|
|
| (no subject) |
[Apr. 8th, 2009|08:42 am] |
Сингулярность наступает! Уже близко! Стоило послать баг репорт в RabbitMQ мейл-лист, как в соседнем листе предложили вечером встретиться в Сан Франциско по поводу этого самого RabbitMQ. А не послал — так и пропустил бы, так как читаю этот фолдер нерегулярно.
Это знак, не иначе. Надо поспать хотя бы несколько часов, потому что обязательно надо посетить.
 |
|
|
| JS-Kit, Erlang, Amazon EC2 |
[Mar. 10th, 2009|06:42 pm] |
JS-Kit расширяется вширь, требуя новых боксов, новых колокейшнов, новых процессоров в топку его ненасытной пасти. Решили колокейшн больше не насиловать (в рэках недостаточно питания) а пойти в Amazon EC2.
Так как основной лошадкой у нас является Эрланг, то нужно было протестировать что нам за наши деньги даёт Amazon в терминах производительности Эрланговских программ.
Основой для теста был принят так называемый EC2 "Large instance". Заодно удалось обновить результаты предыдущей серии тестов [1, 2], ибо старая лошадка имела версию R11B-5, а новая — R12B-5. Плюс к тому, добавил более-менее стандартный тест Quad Ant, который решает задачу коммивояжёра прогоном через города стада муравьёв.
Для начала, вот весь файл результатов в CSV.
Для начала я задался перепроверкой результатов предыдущих тестов [1, 2] с использованием более новой версии Erlang VM: R12B-5.

Напомню в чём суть Lock теста: один (в случае Lock Sequential) либо одновременно N (в случае Lock Parallel) клиентских процессов пытаются залочить какой-то ресурс, общаясь с централизованным локером, который имеет пару таблиц ETS для запоминания того кто именно лочит какие именно ресурсы. Естественно, сам локер-процесс — это узкое место, а значит этот тест тестирует, по сути, одно ядро в системе (при non-SMP VM), либо поведение системы при lock contention за единственный ресурс (в случае SMP). Второе тоже важно, ибо показывает насколько просаживается перформанс на локах внутри Эрланга.
Вот результаты этого теста в графике:

Видим, как замечательно работает виртуализованная сущность Amazon EC2 Large Instance, причём на двух виртуальных ядрах. Все четыре варианта запуска Locker теста EC2 показал результатами в первой пятёрке.
Обратим внимание насколько несущественна просадка перформанса если мы на не-SMP системе упёрлись в узкое место, представляющее собой один процесс (зелёная полоска ненамного меньше синей для single, то есть для не-SMP виртуальных машин (erlang -smp disable)). Это касается всех машин, а не только виртуализованной EC2 сущности, так что тут плюс один не-SMP Эрлангу.
С другой стороны, на том же EC2 эксплуатация узкого горла на SMP VM ведёт к серьёзной деградации производительности. Сравните зелёную линию у третьей сверху системы, которая EC2 Native SMP. Практически в два раза хуже чем базовая производительность. Вывод: там, где нужно драться за ресурсы, Эрланг лучше использовать в не-SMP режиме, ибо иначе в два раза хуже будут результаты. А там, где драться не нужно (просто какая-то передача сообщений по цепочке, сравним для одной и той же системы byte/single с byte/SMP) — там всё равно заметная на глаз просадка (процентов 20-30).
Для тех кто в теме, данный график представляет наглядный пример почему я в ближайшее время не слезу со своего старенького лэптопа PowerBook G4 1.5 GHz. Вон он, в первой трети списка, выше серверного Xeon'а, Core2 Quad, Pentium D и всякой остальной чепухи.
Но всё-же, несмотря на то что Locker не является искусственным тестовым кодом (он используется в продакшне!), тест локера в отдельности не представляет слишком большого интереса, потому что, как правило, именно на локере наши процессы не дерутся, тормоза у них в других местах. Так что попробуем посмотреть на другой способ оценки производительности, на Quad Ant. Он-то явно искусственный, но зато хоть какое-то разнообразие в оценке будет.
Вот табличка, отсортированная по результатам последовательного кода Quad Ant:

А вот её графическое представление:

Вах, EC2 и тут на высоте! Все четыре первых места, как бы мы их не повернули, показывают на превосходство Large Instance EC2 над всеми физическими боксами (не самыми дешёвыми, кстати), которые есть у нас под рукой. И это, кстати, результат прогона одного процесса (Ant Sequential, ant:main/0). Места под ним немного перетасовались, и табличка теперь выглядит как будто это соревнование систем, а не отдельных режимов работы эрланга на разных микроархитектурах процессоров. Напоминаю: Ant Sequential — это прогон одного тяжёлого эрланговского потока, без message passing, без lock contention: сплошная математика и сборка мусора.
А вот теперь самое интересное. В первом тесте, Locker Sequential/Parallel, мы увидели как эрланг справляется с узким местом в виде центрального процесса с ETS-таблицами. Во втором тесте, Ant Sequential, мы увидели как Эрланг мучает машину тяжёлой однопроцессной математикой. Осталось теперь посмотреть на "чистый" параллелизм: что делает Эрланг если у него есть несколько абсолютно несвязанных друг с другом заданий.
Табличка, отсортированная по результатам параллельного (4 процесса) кода Quad Ant:

А вот её графическое представление:

И вот тут-то наступает небольшой кирдык, потому что наш двухкорный EC2 уходит со сцены довольно резво. Как и следовало предположить, на сцену выходят четырёхъядерные кнопки, естественно в SMP режиме. Здесь Core2 Quad рвёт серверный Xeon, обладая на 50% большей масштабируемостью. Сравнение не полностью корректно, ибо FreeBSD 7.x получше масштабируется чем FreeBSD 6.x. Но выяснять кто виноват — процессор или планировщик — в данном случае пока не буду. Впрочем, двухъядерный инстанс EC2 вполне адекватен, ибо его два камня дают практически ровно пятьдесят процентов от перформанса топового четырёхъядерного процессора в этом списке, Core2 Quad, и очень опасно приближаются к Xeon'у по абсолютным цифрам.
По батарее тестов есть один вывод: Xeon — не самый подходящий процессор для Эрланга. Леонид Егошин это подтверждает в приватном письме:
Во-первых, lmbench. Он показал, среди кучи другого, что xeon-ы хуже C2D по целочисленной арифметике и по переключению процессов в Linux. Integer — раза в 2 (ДВА!).
Я сварганил тест по переключению, он подтвердил проблему, и я увидел такой интересный эффект — 2 процесса, обменивающиеся сигналами идут 80-85 сек, а 4 копии этих же процессов на 4core идут 51 сек. Затем, если повязать 2 процесса одних на одно ядро, то они тоже начинают работать 42 сек.
И ещё, TCP/IP идёт хуже чем C2D, но тут я думаю виноват эффект переключения (TCP идёт в отдельном kernel процессе.
Всё, естественно, для сравнимых частот (2GHz-2.16GHz).
P.S. Core i7 ЕЩЁ хуже по переключению, чем Xeon'ы, тест 2 процесса * 4 копии идёт 5 (ПЯТЬ!) минут, а 8 копий одного — 45 сек.
Ну и, конечно, главный вывод: EC2 рулит, использовать для Эрланга можно и нужно.
- К вопросу о быстродействии Erlang (2007-10-31)
- Обновил табличку (2007-11-15)
UPD: Amazon EC2 Large vs. Small instances (2009-03-10) |
|
|
| (no subject) |
[Sep. 2nd, 2008|04:42 am] |
— You overflowed a "long"? And they don't appreciate Lisp?? — задал здесь (via squadette) риторический вопрос ко-дизайнер коммон-лиспа Dan Weinreb.
Очевидно, это означает что в динамических языках числовые типы тоже динамические и апгрейдятся "куда надо" автоматом: в отличие от жёсткого барьера Int → Integer в Haskell, целочисленные типы в правильных динамических языках автоматом перетекают из примитивных представлений в BigNum при переполнении.
Ещё вчера бы я только головой покачал, поддакивая, мол, да, очень удобно, голова не болит про разрядность представления. Ан нет, читал эту статью сегодня, в тот самый день когда Денис с Владимиром доковыряли наконец проблему с Эрлангом, который отчего-то выполнял string:to_integer("134217728"), скажем так, не совсем всегда.
Вот сегодняшний баг-тред:
http://www.erlang.org/pipermail/erlang-bugs/2008-September/000966.html
Вот вердикт Erlang team:
> When the result became a bignum, a second allocation of heap
> space was made - the first for the result container and the
> second for the bignum; and these were in the wrong order
> temporal vs pointerwise violating an essential garbage
> collector assumption.
>
> So, when the second allocation happened to allocate
> a temporary heap buffer aka "heap fragment", a
> subsequent garbage collect messed up ending with
> the result pointing to invalid data in freed memory...
>
> This could have lead to almost anything including
> emulator crash. А всего-то хотелось time_t распарсить! Так что читаю теперь эту фразу Дэна и нервно подёргиваюсь. |
|
|
| (no subject) |
[Dec. 12th, 2007|04:42 am] |
Смотрел Махоткина. Смотрел "О высокой производительности". Смотрел Scaling Twitter. Наткнулся на RabbitMQ. Наткнулся на следующий вывод Моторолы:
A case study by Motorola comparing the use of C++ and Erlang for telecoms software, circa 2006. Чистый Erlang примерно в два-три раза более производителен чем C++ на их задаче, при этом имея фиксированную стоимость по памяти.
По моим же данным, в JS-Kit использование Erlang позволило сократить код в 8-16 раз (в зависимости от подсистемы) и позволило поднять capacity системы в ~5 раз за две недели, построив масштабируемый KV-storage кластер a-la Amazon Dynamo. Про Dynamo я прочитал уже постфактум и был удивлён тем, насколько у нас совпадают требования к сервисам и методы решения проблем с масштабируемостью.
У меня в итоге получилось 2240 строк кода на Erlang, на всё про всё. Этот код делает следующее:
- Динамическое кеширование
- Replication with differential updates to Key-Value pairs
- Multi-node fault-tolerance
- Обслуживает четыре порта, в том числе висит на порту 80 (HTTP), на двух других TCP портах для статистики и общения с C и Perl, а также на UDP для мелких запросов
- Ведёт exponential moving average статистику по куче параметров для каждого клиента
- Умеет ходит к memcached за данными, но смысл в этом исчезает
Короче, я доволен. После опыта с Erlang слайды со scalability-конференций типа "используйте memcached!", "денормализуйте таблицы!", "сегментируйте базу!" и т.п. смотрятся как призывы заточить шуруп об асфальт, ибо в арсенале только молоток. |
|
|
| К вопросу о быстродействии Erlang |
[Oct. 31st, 2007|06:42 pm] |
Было интересно помассировать наш эрланговский код в нескольких измерениях.
1. Машины: — Sun UltraSPARC IIi 650 MHz (PC133) (Sun Fire V120) — PowerPC 1.5 GHz (166 MHz bus), (PowerBook G4) — AMD 2x2 (два двухкорных) 2.2 GHz (серверное исполнение) — Xeon 1x4 (четырёхъядерный) 2.66 GHz 2. Компилирование в нативный код (erlc +native) или в байт-код 3. Компилирование для SMP VM (erlc -smp) 4. Использование SMP VM (erl -smp enable/disable)
Задачи:
5. Lock: код на gen_server, исползующий ets[set, private] и порождающий процесс на каждый запрос. 6. TCP I/O: код, общающийся с memcached -m64 (для простоты) по единственному долгоиграющему соединению, и доступный через gen_server примитивы (rpc); также использует ets[set].
Варианты нагрузки задач: — Sequential - последовательный вызов 10000 микротестов. — Parallel - параллельный вызов 10000/N микротестов в N порожденных процессах, где N из {2,4,10,100}. Выбирались лучшие времена. Время порождения процессов не отбрасывалось.
Цифры в столбиках — вычисленное количество транзакций в секунду. На каждую цифру тест работал несколько секунд, и было произведено несколько прогонов чтобы выбрать лучший результат.

Выводы:
1. Поддержка SMP систем в Эрланге оставляет желать лучшего. 2. HiPE в Эрланге пораждает нативный код, который в итоге медленнее байткода. 3. В долларах на TPS лидирует Intel Xeon (четыре ядра по 2.66 GHz) 4. В TPS на мегагерц лидирует Sun UltraSparc (1 процессор на 650 MHz)
Вопросы:
1. Где я что-то недопонял, недочитал, недооптимизировал?
UPD: Обновил табличку, далее JS-Kit, Erlang, Amazon EC2 |
|
|
| (no subject) |
[Sep. 14th, 2007|05:42 am] |
Был вчера на первом собрании Bay Area Functional Programmers group (http://bayfp.org/).
Из интересного — Алан из SleepyCat (уже Oracle), рассказывающий про то, что они начали писать интерфейс между BerkeleyDB и Эрлангом, Дэвид Поллак (автор lift фреймворка на Scala), прямо сказавший, что "you're fucked" на вопрос о масштабируемости Скала-решений на несколько машин (по сравнению с Эрлангом, вестимо), а также Keith Fahlgren из O'Reilly, обещающий бесплатные книжки в следующий раз. Кейта я спросил "а бесплатно книжки только от О'Рейли, или от любого издательства?", на что чуть не получил фингал.
Под конец появился Ярив Садан (http://erlyweb.org/), я с ним еще пересекусь на Bay Area Erlangers Group meeting, через неделю.
Всего было человек двадцать. Для большинства FP — хобби. Но всё же некоторые делают на этом деньги, типа того же Поллака. Была одна единственная женщина, бизнес менеджер, для неё Haskell это хобби. Говорит, всего занимается им несколько недель и всё идёт по плану, кроме монад, на которых она пока запнулась. А кто на них не запинался, судя по объёму вводного материала? |
|
|
| В чём сила, брат?.. |
[Sep. 11th, 2007|05:42 pm] |
как спекулянты продают книжки на Амазоне... пару дней назад смотрел — ещё баксов стописят стоила, а теперь — четверть жигулей %-O

Ну и естественно, что в этой книге circa 1996 есть то, чего нет в Июльской (2007) новейшей книжке за девятнадцать баксов :( |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|