Previous Entry Share Next Entry
2016-01

over and over again


пишу датафлов движок для продакшена в третий раз.

в какой-то книжечке я читал, что после 3 частных случаев можно наконец делать либу :)

и таки да, первые две задачи различались очень сильно, да и между второй и третьей разница заметная есть.

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

наверное, адепты функциональщины смогли бы это разрисовать какими-нибудь комбинаторами/iteratees, но у меня из-за наличия обратных связей это в голове не помещается (т.е. в графе обработки есть циклы - перезапрос пакетов, фидбек по параметрам итд итп)

edit: вставил картинку, картинка уменьшена и не кликабельна, дабы не вызывать вопросов у лоеров заказчика.

This entry was originally posted at http://wizzard.dreamwidth.org/271487.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
dmytrish March 19th, 2013
в графе обработки есть циклы - перезапрос пакетов, фидбек по параметрам итд итп) — вроде бы звучит как подходящее для Functional Reactive Programming, но я не уверен.

metaclass March 19th, 2013
Разного рода итераты/кондуиты умеют обратные связи, кажется. Но от них вытекают глаза.

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

wizzard0 March 19th, 2013
есть еще три нюанса от которых вытекают глаза

1. в обработке участвуют 4 компа, и еще возможно я буду части выносить на видеокарточку
edit: 4 компа с разными ролями (транслятор, релей, админка, клиенты)

2. надо обрабатывать события обрыва сети и изменения конфигурации сети (например, переключиться с UDP на http proxy если транслятор переместился из одной сети в другую)

3. и перезапуск любой из этих машин, или креш проги, чтобы после этого можно было откатиться назад до какой-то точки и поехать дальше

Edited at 2013-03-19 09:10 am (UTC)

metaclass March 19th, 2013
О блин, я бы тут без функциональщины с иммутабельностью просто бы не совался. Но вопрос с производительностью - языки, от которых не вытекают глаза, в лучшем случае пригодны для кодогенерации, но плохо пригодны для обработки больших потоков данных в рантайме. А хаскели разные - когда их довести до производительности сравнимой с С - они начинают выглядеть как говно.

thesz March 19th, 2013
В моей практике есть случай, когда Хаскель довели до производительности, в десять раз превышающей Си, и на поверхности (для пользователя) он остался ровно таким же Хаскелем (да и внутри тоже - я просто специализировал некоторые бмблиотеки). Меньше Си в несколько раз по объёму кода.

Производительность меряли на последовательном коде, если что. На больших графах, поточная обработка.

https://docs.google.com/presentation/d/1_WCjVrcfiuP-ELInrXdHuIMqxTURYmg-kG1D7-e9WgQ/pub?start=false&loop=false&delayms=3000

wizzard0 March 19th, 2013
pointer chasing очень сильно влияет на производительность работы с графами, ага. я бы даже сказал, что это главная проблема.

но в данном случае данные обрабатываются потоково, достаточно большими кусками и локальность обеспечивается естественным образом. единственное место, где локальность важна, уже с ее учетом оптимизировано (там руками по памяти данные разложены оптимальным образом).

сейчас после того как я pipelining доделаю, главной проблемой будет избавиться от копирований и отпрофайлить ряд частей, после чего узкие места переписать на SSE или на OpenCL, если не хватит SSE - там в скорость криптоалгоритмов всё упирается.

edit: ну, конечно, еще упирается в латенси сети (секунда? легко!), но весь этот огород с пайплайнами собственно городится именно для того, чтобы от нее максимально не зависеть :)


Edited at 2013-03-19 10:00 am (UTC)

wizzard0 March 19th, 2013
презентация хорошая, жаль деталей мало))

thesz March 19th, 2013
Я рассказал то, что было в наших открытых статьях. ;)

(Anonymous) March 19th, 2013
Можете выложить в pdf?

wizzard0 March 19th, 2013
ну я человек простой, я на бумажке нарисовал и теперь это переписываю в код :)

иммутабельность очень, очень помогает. да и вообще функциональщина помогает в смысле структурирования софта, а уж как это в коде реализовывать, на каком языке - дело десятое, имхо.

к тому же, да, в итоге там придется делать всякие zero-copy и C+SSE/OpenCL, но пока что копирование буферов во все поля и тучи отладочных логов на фэйковых данных типа "AesEncrypted_KeyXXX_Block555(byte 0 to 20000)OfFile777FormatHint_x264" :)

avnik March 19th, 2013
Мне слышится слово ерланг почему-то.

sassa_nf March 19th, 2013
а как на этой диаграмме выражен параллелизм? разделение в одном месте на три ветки?

wizzard0 March 19th, 2013
в любом квадратике или стрелочке может быть много пакетов сразу, и еще некоторые нюансы которые не знаю как красиво изобразить.

а три стрелки это разные типы пакетов (в рамках одной стрелки один тип)

sassa_nf March 19th, 2013
Ну если в квадратик входит только одна стрелка, то особого параллелизма нет.

Параллелизм появляется там, где у вас non-temporal зависимости - т.е. где порядок следования квадратиков не важен.

wizzard0 March 19th, 2013
??? а где тут сказано что-то про порядок?

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

wizzard0 March 19th, 2013
т.е. если например брать классический мапредьюс, то он тут нарисуется как вход->мап->редьюс->выход, без допстрелок

sassa_nf March 19th, 2013
а, понятно. В таком случае нужно квадратики заменить на стрелки, а стрелки на квадратики.

Тогда если стрелки могут из одного пакета рожать несколько, так и подписывай f :: a -> [b] :) ну и чтобы типы соответствовали, то concatMap f и fold f.

wizzard0 March 19th, 2013
а, и еще один пакет входящий в квадратик может привести к выходу нескольких, и наоборот, есть места где несколько агрегируются.

zyxman March 21st, 2013
Если куски настолько большие, что их можно спокойно бросать по сетке и не бояться латентности, то я бы использовал Erlang как инфрастуктуру передачи, а обработку можно делать в эрланг-портах (это внешние процессы, связь с которыми через классические файловые пайпы).

wizzard0 March 21st, 2013
интересно есть ли где-нить гайд по тому как ему обрезать рантайм чтобы он не занимал стопицот метров на диске у пользователя. а, и еще не оч понятно как гуи делать :)

avnik March 21st, 2013
Гуй -- web? (ajax)
Или наимплементить x11 на самом ерланге.

А с рантаймом надо думать. Можно и урезать наверное, может где-то в механизме релизова есть отрезание лищнего?

wizzard0 March 21st, 2013
OS X, iOS, Windows. На серверах там логики немного совсем.

Мне кажется, поскольку эрланг в основном на серверах живет, то по идее комьюнити обрезка не очень интересна.

zyxman March 21st, 2013
У Эрланга корни в телекоме, поэтому там действительно упор всю жизнь был на другом -масштабируемость, отказоустойчивость и много девяток аптайма.
Гуи конечно никто не делал (у цисок тоже кстати гуи нет просто принципиально), но в принципе кое-какое гуи у эрланга есть- реально там часть тулзей с гуями и честно говоря гуи вполне энтерпрайзного уровня.

Эмбедить его думаю несложно - там ведь система довольно прозрачная - ЕМНИП, буквально бинарчик виртмашины, сетевой хаб (несколько виртмашин на одной машине могут работать одновременно и видят друг-друга и будут видны внаружу через хаб), собственно компилятор (его можно выкинуть) и дерево скомпиленного в код вирмашины кода (можно все модули в одну папку закинуть).
То есть если брать стандартную поставку, там будет пару бинарчиков, конфиги и папка скомпиленных модулей.
Я лично еще не пробовал, но уже знаю много людей, кто прикомпиливал к виртмашине эрланга какой-то сишный код, то есть не вижу непреодолимой проблемы и папку с модулями вкомпилить прямо в бинарчик виртмашины если нужно.

В любом случае, у меня есть у кого прямо спросить на эту тему и я постараюсь в самое ближайшее время всё разузнать ;)

PS кстати, раскрою страшную тайну - насколько я понял, огромный объем _крайних_ версий эрланга вызван тем, что каждая последующая версия включает в себя рунтайм и модули _нескольких_предыдущих_ версий, что позволяет простым ключиком командной строки включать режим бинарной совместимости с какими-то из предыдущих версий.
То есть если совместимость не нужна, то можно тоже хорошо порезать.

wizzard0 March 21st, 2013
О, это офигенно. В этом проекте переходить уже поздно, а вот "через один" попробую.

maxim March 22nd, 2013
Можно, ты можешь себе выбрать минимум для деплоя только тех прилжение которые тебе нужны.
Обязательная только рантайм система (исполняемый файл beam.smp) 12МБ.
И приложения:
312K erts-5.9.2
1.5M kernel-2.15.2
Все это штатными средствами управления релизами эрланг.

Edited at 2013-03-22 08:50 am (UTC)

wizzard0 March 22nd, 2013
12 - это тоже как-то дофига. Хотя уже лучше, чем 60.

А до 1М его никак урезать нельзя?) Вот дотнет - можно.

maxim March 22nd, 2013
strip beam.smp -> 2.5MB :-) можно и дальше резать, но это надо С-шные куски выключать конфигурируя сборки ВМ, до 1МБ думаю можно дотянуть. Я незнаю сколько ling занимает, можно ее взять если, что. Но Советов пока исходини не открыл.

Edited at 2013-03-22 01:34 pm (UTC)

  • 1
?

Log in

No account? Create an account