?

Log in

No account? Create an account
Он всегда был не прочь подкрепиться. Кроме того, он был поэт. [SPL] [home page] Below are the 10 most recent journal entries recorded in the "inv2004" journal:

[<< Previous 10 entries]

September 16th, 2018
05:15 pm

[Link]

coinbase-pro-rs
Запилил API на расте для работы с coinbase: https://crates.io/crates/coinbase-pro-rs

поддерживает в том числе futures и websocket.
Ордербук пока положил отдельно - в связке он мне пока не нужен - но как только, так сразу его затащу внутрь.

Молча ненавижу питон - банально сделать moving-window на 100 x 2000значений и компьютер превращается в калькулятор, под pypy не собирается.

(5 comments | Leave a comment)

August 3rd, 2018
10:51 pm

[Link]

Rust. The Computer Language Benchmarks Game
Что-то где-то обновилось, пересчиталось, и я, неожиданно для себя вылез на первое место по Rust в k-nucleotide benchmark, причём даже с небольшим заделом:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html

1. C++ g++ #2
3.66 155,956 1624 11.16 70% 98% 70% 68%
2. C gcc
5.07 130,008 1506 15.25 88% 84% 58% 73%
3. C# .NET Core #9
5.29 186,892 2574 17.90 96% 67% 93% 84%
4. Rust #8
5.76 135,728 1900 16.77 84% 94% 49% 65%
5. Rust #4
6.07 137,948 1749 18.11 51% 81% 78% 90%

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

Tags: , , , ,

(Leave a comment)

July 5th, 2018
09:15 pm

[Link]

Продолжаю бенчмаркать
Итого за три дня написан ~ одинаковый функционал на python и type-script, который уже давно был реализован на расте. Задача довольно примитивная, но зато из реальности:
1) есть какое-то количество данных.
2) строим 100 минутных свечей (по сути только close) _от_текущего_тика_ (есть ли в этом смысл - это отдельная тема)
3) загоняем в ML
3) делаем #2 и #3 проигрывая исторические данные в цикле, например от 0 до 2000 для начала.

Итого:

PYTHON: Изначально всё было написано на питоне и pandas, который вроде как раз предназначен для подобных группировок, однако именно группировку он выполнял настолько долго, что я это даже не мерял - больше минуты.
TS: Написал это же на TS с использованием data-forge - картина аналогичная - с точки зрения производительности всё настолько печально, что даже замерять нету смысла.
TS#2: Выкинул data-forge, итого - TS разогнался до ~20 секунд.
PYTHON#2: Выкинул pandas и переписал всё исключительно цифрами (заодно время тоже, до этого это был datetime) на numpy - получилось всего 0.5sec.
TS#3: Выкинул модуль moment.js и TS тут же разогнался с ~20 до ~2 секунд, что в целом неплохо, учитывая что никаких биндингов.

На данном этапе python победил своим numpy, хотя на тот момент TS нравился больше.

Следующий этап - решил подключить ML, ведь каждый хочет с этим поиграться.
PYTHON#3: 20Mb модель он считает ~13ms.
TS#4: Похоже на то что keras.js это имплементация ML без всяких биндингов - следовательно всё считается на ванильном JS. И, оказалось, что в таком виде, 20Mb модель он предиктит 900ms, что при любом раскладе неприемлемо. Учитывая, что он это делает асинхронно в одном потоке, то, если продолжать слать данные, цифры модели вообще могут начать приходить с большим >30сек. опозданием.

Некий, наверное очевидный, вывод:

Python тормоз, на нём писать нельзя, но можно использовать волшебный numpy, если задача хоть как-то в него заходит.

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

Итого: для склейки оставляю питон.

Tags: , ,

(5 comments | Leave a comment)

June 28th, 2018
01:15 am

[Link]

Как я пофрилансил на react-native.
И чем это закончилось:

Мастер менеджмента и фрилансер. Повесть в трёх частях


Для тех кто просто пролистывает дальше, краткое содержание: «google: freelance подписывайте контракт» спасибо за внимание.

Чуть более полное описание: Как я открыл для себя новые вершины менеджмента благодаря одному заказчику, при работе над совместным фриланс проектом.

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

Действие первое: терпимое
...
https://habr.com/post/412785/

(5 comments | Leave a comment)

June 24th, 2018
01:56 am

[Link]

Вечный вопрос.
Для прода - C++ / Rust / Java / C
Что-то для строгого прототипирования - Haskell / ML
А вот быстро накидать прототип на чём? Python / Perl / Node.JS / Ruby / Go / Lua ?

Посмотрел - библиотек для всего этого много, хотелось бы накидывать на Rust (что и делаю), но быстро на нём никак не получается.

-- дополнение --
Посмотрел библиотеки внимательнее - Perl отпал, что-то современного, например машин-лёнинга для него нет.

(8 comments | Leave a comment)

May 20th, 2018
10:34 pm

[Link]

kx25
Случайно забежал на kx25 https://kx.com/kx25/ . Если отбросить 90% рекламной болтовни, то впечатления следующие: kx продолжает попытки расшириться, штат ~800 человек, причём, если вдруг у кого желание поучаствовать, то, вероятно, уровень входа не особо высокий, так как год назад, на прошлом kx-meetup, про kdb рассказывал человек из kx, по первому впечатлению, совсем студенческого уровня.

Из презентаций показалось, что kdb, в большинстве случаев, используется как некий продвинутый, конечно извиняюсь за такое сравнение, VBA и excel, что немного печально. В основном то, что показали, имеет наколенный или демонстрационный вид, фреймворки не упоминались вообще, вероятно те, у кого большая кодовая база kdb, пишут всю инфраструктуру с нуля, но, так как писать с нуля тяжело и долго, то в большинстве случаев kdb предпочитают использовать в связке с python.

Долго лавировал в толпе в галстуках, пытаясь опознать Arthur Whitney, но, в итоге, обнаружил его в более простой, если можно так сказать, форме, что приятно. Это не отменяет того, что он был постоянно окружён небольшой говорящей толпой, или же пытался убежать от неё, так что переговорить удалось всего парой слов.

Зато удалось интересно пообщаться с core частью kx - Pierre Kovalev и Oleg Finkelshteyn. Подтвердились мысли о том, что создание языка Q преследовало в основном коммерческие цели, и оказалось что я не один, кто считает K понятнее и проще чем Q. В Q 3.6 до сих пор используется K4, однако оказывается Артур уже делает K8 для себя, к сожалению, как и K5 два года назад, не думаю что её удастся посмотреть. Интересно, что K8 не только не пополнела, но и сокращается в объёме относительно K4.

Поспрашивал были ли попытки прикрутить подобие хоть какой-то статической типизации, так как, моё мнение, что как только количество кода или количество человек в команде переходит какой-то порог, то динамическая типизация kdb превращается в ад, что я и наблюдаю на работе, но похоже таких попыток не было, так как Pierre конечно щупал haskell, но о типизации в целом негативно отзывался. Так что, вероятно, если снова дойдут руку, я попытаюсь ещё раз накрыть это системой типов, чтобы хотя бы посмотреть что получится.

Из сопутствующего - было очень много Machine-Learning, но, понятно что через питон или биндинги, это отчасти доказывает, что kdb хорош как небольшая обвязка, но что-то больше писать на этом врядли легко, и не только из-за лицензии. Троль Peter Wang из anaconda.org, предал анафеме C++, однако, как обычно, что на замену не сказал, так как очевидно что не python, так как в докладе он был основной темой. Я спросил его про Rust и попросил в будущем поделиться впечатлением.

Tags: , , , ,

(1 comment | Leave a comment)

March 7th, 2018
01:16 am

[Link]

ох rust
Метод просто элементы интератора печатает - Несколько часов пробирания через то как избавиться от владения итератором:

impl PlayerObj where
    for<'a> &'a T: IntoIterator,
    U: std::fmt::Debug
{
    fn print(&self) {
        self.data.into_iter().for_each(|x| println!("{:?}", x));
    }
}

(4 comments | Leave a comment)

September 20th, 2017
07:59 pm

[Link]

microbenchmarks: Rust vs KDB+ (Q)
Как-то давно натыкался тут на микробенчмарки разных Rust, Haskell и т.д. Но тогда они показались мне абсолютно неадекватными, типа измерение как быстро сможет раздуть в памяти вектор, когда как, на мой взгляд, можно было бы взять не сильно сложные, но гораздо ближе к реальности тесты.

Дело было вечером ... поставил на ноут Rust, и конечно сравниваю его с Q (в домашней 32bit версии).
- Почему именно их? - Потому, что Q у нас в проде, а Rust приобретает репутацию того, что может когда-то взлететит в энтерпрайсе для low-latency и производидтельных задач.

Понятное дело, что сейчас это сравнение интерпретируемого и компилируемого, но Q всегда выдают как что-то запредельно быстрое, с другой стороны на Rust не сильно сложнее писать подобные конструкции через итераторы. В перспективе конечно хорошо бы добавить C и Java в тест. Да и сами тесты немного расширить, только пока не знаю чем.

запушил на гитхаб:
https://github.com/inv2004/rust_vectors

Из того, что было лень пилить - median, оно явно далеко от отпимального на Rust'е.

время в ms

rust-q32

(3 comments | Leave a comment)

July 6th, 2017
12:30 am

[Link]

Всё по кругу. 2/3. ClickHouse / kdb
На работе услышал о новинке - ClickHouse. Ну разумеется несколько бенчмарков, и, кажется, удалось посмотреть на kdb как бы со стороны.

Хотя CH и не кажется чем-то сверхъестественным, и даже не написан на тайном языке Q/K, но с другой стороны поразило, как _современный_подход_ и _адекватная_архитектура_ с ходу решилa большинство преблем, которые kdb, окопавшись в своём мире, имела много лет, и только около года назад, городя конструкции из говна и палок, пытается изобразить что он не просто awk, только векторный.

С другой стороны я привык к kdb, и думаю в в глубине души был бы даже рад, если бы кто в меня вернул веру что kdb + q побеждают всех :)

1) Многопоточность.
KDB однопоточный (кроме чтения с дисков). Это выдаётся как некое "мы и так лучше", но по факту это значит, что пользователи на гейте стояли в очереди и ожидают пока обслужат. Целый гигатский сервер стоит и не занят чем-то особо важным, пока пользовательский запрос не пробежит по ветке процессов и не вернётся назад. Недавно это немного поменяли - запросы хотя бы и уходят в систему асинхронно, но по-прежнему каждый инстанс обрабатывает только по одному из очереди. Ладно, kdb придуман так, что всё должно быть настолько быстро, что якобы и один поток не проблема, но всё не может быть быстро - есть чтение с дисков, есть агрегации на промежуточных процессах. Многократным дублированием этого всего изображается некая как бы многопоточность.

В CH всё кажется уже готово - если есть свободные нитки, то они используются и для чтения, и для распределённой агрегации.

2) Многопоточность.
Если позволять кому-то в kdb залазить своими руками, то всегда надо быть готовым к тому, что кто-то либо отъест всю память (без -w), но скорее он просто заблокирует надолго процесс, и все будут ждать пока он не отвалится по тайм-ауту через много минут.

В CH такой проблемы нет. Да, юзер забьёт одну нитку, другой - вторую, но, если это не какие-то рвущиеся в дверь наркоманы, то система останется работоспособной для всех остальных. В CH даже появятся пулы ресурсов: CPU, disk, net

3) Индексация.
У kdb для диска один индекс `p# - это по сути группировка блоками по этом индексу + сохранние указателя на первый элемент блока. Да, в некоторые случаях это ok, но в реальности случаи сложнее. Как только начинается выборка за пределами индексированного поля, то всё уже не так радостно.

В CH есть составные индексы. Можно не только по одному полю выбирать нормально. С гранулярностью, т.е. и места особо не занимают.

4) Q in-mem.
Вот это интересно думаю. Когда ты пишешь на K, то это по сути обработка простых структур в памяти. Можно сделать довольно эффективно, но для чтения с диска такое не пойдёт - с диска только через select на Q. Разумеется писать разные запросы для памяти и диска никто не будет. Kdb ничего оптимизировать не будет. Итого, какая-нибудь аггрегирующая функция, да хоть last, с группировкой "select last v by k from t", сначала сгенерит для каждого ключа отдельный вектор, покопирует туда соответсвующие группировке данные, а потом выберет последний элемент. Я не знаю как оно там совсем внутри работает (а кто знает?), но select с диска при этом умудряется быстрее отработать. Но именно скорость in-mem продаётся как что-то сверхъестественное. Я с этим не спорю, если писать на моём любимом K или хотя бы изображать это на Q и из памяти- то да, быстро будет, но так писать никто не будет.

В CH есть тип таблицы Memory, потенциально это могло бы накрыть in-mem в kdb, но тут не поддерживаются никакие индексы, да и в целом решение с кешом кажется удобнее. Помимо дискового, в CH есть свой кеш, что можно использовать как in-mem, но только он LVC и нет механизма принудительно там данные удерживать. Но, судя по гугл-группe, какие-то скрытые kdb'шники в группе кликхауса хотят того же. + к этому стоит добавить, что если это простая выборка _только_ по индексам, то kdb выдаёт её за время близкое к нулю, CH такое время не показывает, но причины не искал: может быть обработка запроса, может гранулярность индекса (в kdb `g# в памяти храние все индексы для ключа), а может передача в клиент.

Опять же в kdb - память для данных бывало и заканчивалась, вместе с работой приложения и S1 по сути. С кешом такого произойти не может - да, может замедлиться.

5) Языки. Статическая/динамическая типизация.
Тут уже всё написал thedeemon, я тогда ещё был в жж - http://thedeemon.livejournal.com/54732.html
Да, писать на K и даже на Q удобно и быстро, но оно никуда не развивается. Было и такое, что какие-то данные на входе оборчивались в списки списков, при этом эти данные и принимались и как-то умудрялись обработаться, при этом ломая существующие структуры и частично теряясь. Ес-но в статике такого не было бы. Я бы оставил диалект Q только как какую-то надстройку для пользователей, вроде как и сделал maxim. Видимо надо ещё раз попытаться имитировать K в нормальной системе типов. Так как в основном реальный код на K/Q не является только красивым однострочником, а однострочник можно и переписать на чём-то достаточно функциональном - ML, Haskell, ?Rust?

Но о языках видимо в третьей части, которую ещё не придумал.

(3 comments | Leave a comment)

July 5th, 2017
11:47 pm

[Link]

Всё по кругу. 1/3
Думаю стоит добавить краткое описание от предыдущего поста до этого, т.е. пару пропущенных лет.

Три года назад ушёл в энтерпрайс на Q/kdb, казалось что писать что-то своё особо и не нужно, а даже если и писать, то всё равно выйдет что-то типа K. На фоне этого всё вне-рабочее программирование свелось к нулю, а рабочее - оно понятно - не особо интересно. Как следствие, велосипед заменил компьютер, а ФБ заменил ЖЖ. Два года - сон крепкий, голова - без лишних мыслей.

Но тут опять ударился в программирование и базы данных, тут во второй части.

(Leave a comment)

[<< Previous 10 entries]

inv2004's Home Page Powered by LiveJournal.com