Первые сдвиги в Go + SQL
В общем долго я маялся, мучился, ленился и, таки себя пересилив, в конечном счете сел за программирование. Кое-как, со скрипом, но сел. Начал буквально через силу: думаю «блин, мне под сраку лет уже, а я пишу какие-то задачки для 5 класса, какого...?». Но это гонор, я засунул его в Ж. и стал тупо брать и делать. Цель есть и надо идти вперед.
Сначала по видео учился, благо недавно у Нильчанпаба вышел четкий курс по Go в 2 частях, большой объемный, хорошо рассказанный с кодом и большой аргументацией. На ютубе лежит, кому надо — найдёте. В принципе вот именно он меня и сдвинул с мертвой точки. Хорошо парень рассказывает, стал его подробно проходить, с тетрадкой, записывая все важное (а там — всё важное!). 2х13 часов видео курс по основам (недели 3-4 заняло по 5-6 часов в день).
Потом стал пробовать писать код, написал всяких простеньких залипух порядка 1.5 сотен. Теперь полностью (почти полностью) понимаю код и пробую писать бота по своей ТС, благо я эту систему сам придумал и знаю ее всю досконально. Все подводные камни помню и предвижу после работы с наемными программистами ранее. ИИ помогает с ошибками и интерфейсом, книгу уже использую как справочник (ага использую, это громко сказано), в общем первые сдвиги есть. А все очень непросто, но интересно. Однако, приятно понимать, что уже что-то можешь. Ладно, как я там говорил, дорогу осилит идущий? Вот-вот.
Тружусь, надеюсь за год приду к простенькой базовой реализации (хотя хрен его знает, там впереди столько всего, а я еще SQL задумал, но по SQL опыт у меня хороший по работе). А БТ пусть пока питоновский остаётся. Он исправен и буду из него сетапы брать.
Такие дела. Впереди долгий путь, но мне уже не привыкать :) Хвастовство в картинках приложил :)
Почему такой выбор?
Михаил Михалёв, приветствую земляка. Уже есть мой бот на питоне, от 5 сетапов и более вообще опухает бот. Написано, как оказалось, монолитом, что мягко говоря не быстро. Плюс мой однокурсник из техунивера (программист со стажем 25+, живет в Европе знает кучу языков) порекомендовал почитать это, чтобы снять все вопросы по выбору языка для HFT:
habr.com/ru/companies/geekfactor/articles/682084/
Спорить не буду.
Go — хороший язык для написание продуктового кода с использованием микросервисов в большой компании
Если это маленькая компания или один человек или не классический продуктовый код про перекладывание json-ов — очень спорное решение
Если много математики и статистики — в Go c этим очень плохо, так как нет нормальных библиотек
Если нужна очень большая скорость, то тоже есть варианты получше
ИМХО если скорость не важна (не надо укладываться в микросекунды и с сервером на колокейшене), но много математики (стат тесты, ML/DL), то лучше Python
Если чего-то очень быстрое, то Rust или С и сервер на колокейшене
Чего у вас на Python тормозит дистанционно сложно понять — при правильной реализации, все тормозное выполняется в библиотеках вроде numpy или pytorch со скоростью недостижимой на Go, а для io операций есть asyncio
Михаил, мне трудно спорить, я начинающий совсем. Да и зачем об этом спорить, холивары программеров давно известны. Выбор языка это же ВЫБОР, вот я и выбрал Go. Скорость ОЧЕНЬ важна. На Питоне мне писали, результат очень слабый по скорости. На Rust писать сильно сложнее, сказали опытные ребята, вообще не лезь в это. Плюсы — тем более. Предлагали еще C#, тоже хороший и быстрый язык, но я выбрал Go, dot.Net может потом, если понадобится. Так и сказали, если надо быстро и многопоточно, то по скорости после плюсов и раста — только Go. Я уже вижу как летает Go в агрегации свечей параллельно в 10 потоков — это раз в 20 быстрее, чем делал код на питоне. Может быть его так написали, возможно. Не вижу смысла дальше обсуждать, думаю вопрос можно закрыть. И я — не компания, я сам по себе, пока что.
P.S. Упомянутый вами комментарий являлся ответом про зарплаты программистов в компании, а не про то, лучше go или хуже. Зарплаты программистов мне не актуальны пока.
Михаил, а вы посмотрите внимательно на картинку с командной строкой и командами SQL, там видно какие свечи собираются (по продолжительности) и из каких они собираются. И почему собираются такие нестандартные интервалы… У меня очень не банальная система и очень нестандартная логика бота. Вот её и предстоит реализовать. Это все подготовка, тут еще даже условия входа не начал прописывать. Впереди много труда.
А сетапов у меня в интерфейсе будет примерно 50 (это когда я буду уверен что логика бота работает хорошо — пока я не дошел до этого). Пайтон на 10 уже опухал в плане отправки ордеров, опроса позиций, слежкой за ценой, а когда добавили сетку… вообще туши свет. Скорость как на бейсике.
А еще представьте у меня на одном и том же тикере одновременно торгуется 3-4 разных торговых сетапа с разными условиями. Если вы со стороны посмотрите что бот там делает с ордерами — вам это покажется вовсе каким-то мракобесием! но тем не менее. Поверьте в торговых системах я далеко ушел и обсчитывать их научился давно. Это вовсе не то, чтобы гадать куда пойдет цена.
Зачем вам в это вникать? Я то одну и ту же задачу реализую на другом языке по той же логике, и уже вижу разницу, даже на этапе параллельного сбора данных и их агрегации — все делается сразу, есть только небольшие вопросы над усилением конфигурации сервера. Смысл спорить с этим?
> вы посмотрите внимательно на картинку с командной строкой и командами SQL, там видно какие свечи собираются
Я видел картинки с часовыми и более редкими свечками, видел ваши рассказы про пинг до сервера под 100 мс в предыдущем посте и большие конфиги (не понимаю, как это вообще может влиять), 50 сетапов — это кажется крайне несущественной нагрузкой. Поэтому у меня большое подозрение, что вы не очень понимаете в чем реальная причина торможения, и что совершаете какие-то простые, но совершенно неочевидные вам ошибки
Я не спорю с вами, что тупое переписывание на Go может некоторые вещи ускорить, но есть подозрение, что ускорение там совсем не из-за потоков, как вы думаете, а из-за не блокирующих io-операций, которые вполне успешно делаются в Питоне. И если вы реально поймете, в чем причина торможения, то вероятно ускоритесь гораздо существеннее
Считаю, что всегда неплохо, когда кто-то осваивает, что-то новое, и просто хотел вам помочь разобраться. Если есть желание, то можно попробовать обсудить без погружение в конфидециальные делали, что вы делаете и попробовать разобраться, как это ускорить. Ну а если желания нет и интересно копаться самому — могу вам пожелать только успехов
Михаил, спасибо вам за добрые слова!
Благодарен Вам за желание помочь, правда, но все же тут без погружения в нюансы бота помочь не получится — а их много, бот не простой.
Подытожим: я сам пайтон не писал, мне на пайтоне код писал другой программист. Я тестировал. Написано монолитом, файлы бота огромные и трудночитаемые, по 900-1200 строк. Все последовательно, даже свечи загружаются последовательно, один тикер за другим, баз данных там нет, все в RAM, именно по этому при 2 и более сетапах на одном тикере возникают долгие задержки и даже ошибки логики. но там отдельная песня, продолжу по теме.
Для сравнения, на Го сейчас уже параллельно все тикеры в базу залетают, на 5-летней истории часовики например (а это порядка 45 тыс. свечей на тикер) залетают около 20 секунд включая запросы и запись в SQL параллельно! А там на 10 сетапах сбор составляет 4-5 минут. Это раз.
Дописывание часовиков в реалтайме происходит менее секунды в записью а базу, на пайтоне разработчик меня лечил что биржа долго отдает свечу, поэтому только через 10 секунд ордер ставится, а мог ставится через 1 секунду.
Далее: при торговле, в пайтоне используется конфиг.пай, там мы прописываем все параметры торговой системы и торгуем например 10 тикеров. Пайтон идет последовательно по коду конфига, опрашивая один сетап за другим, проверяя позиции, следя за ценой, раскидывая ордеры (а вход там стоп-лимитами, иначе математика ТС «поедет»), и проход по одному конфигу (для 10 сетапов) занимает около минуты! Минута, «Карл»! Частенько возникали ситуации, когда цена была рядом — она могла и убегала от ентри поинта, приходилось покупать маркетами, иначе пропуски входов… В общем проблемы, проблемы, проблемы… Именно из-за быстродействия. Я решал это всё примерно год, но в итоге все заканчивалось фразой разработчика «сделаю в несколько потоков, дай денег». Объяснять думаю не надо, как дальше наглели разработчики.
Го может параллельно разными рутинами все это делать. На агрегаторе торговых ТФ я уже убедился как это быстро может работать и уже (!) работает. Часть параметров слушаем вебсокетом, позициями управляем через REST API. и так далее.
Может и пайтон так умеет, спору нет, думаю мне просто написали все криво. Но я хотел изучать именно компилируемый язык со строгой типизацией и многопоточностью. Выбор пал на Go.
Ладно, думаю — понятно. Дальше расписывать не буду. Быстродействие кода во главе угла. И спасибо за помощь, еще раз.
Если у вас много запросов по сети, то потоки особо не нужны, если у вас не десятки тысяч запросов в секунду. Потоки скорее нужны для тяжелой математики, с чем у Go есть проблемы в отличии от Питона. В общем-то у Go со всем проблемы кроме сетевых вызовов. Нарисовать какой-то банальный график или быстро покрутить данные в разных разрезах — отдельных большая задача, хотя в Питоне это делается на щелчок пальцев. Ну если нужно только делать запросы к удаленному серверу и сохранять в базу + какие-то примитивные операции уровня сложить поделить несколько чисел, то Go вполне нормальный вариант
Я на Go пишу каждый день, но вот для трейдинга пишу на Python. Пытался на Go, но плюнул — пользы мало, а постоянно спотыкаешься об какие-то ограничения языка, но у меня много всякой не простой математики + нейронные сеточки
Успехов вам. Освоить язык и писать небольшие программы достаточно легко, но поддерживать кодовую базу по мере ее разрастания совсем другого уровня задача, которую гораздо сложнее осилить
Михаил, ну вот о том и речь, разрабер такой и был (не тот, который друг, а тот который дальше мне проект развивал): ушлый и не великих скиллов, получается. Много считать мне наверное не понадобится, по крайней мере в боте. А вот в бэктесте (БТ)… Там сплошь расчеты. БТ на питоне работает у меня сейчас, но тоже медленно.
Пример: рассчитываю один торговый набор по одному тикеру в одном БэкТесте, с разными тейками и стопами и разными параметрами входа просчитываю таймфрейм и тикер. Это примерно 15000 сетапов для расчета (бывает и больше). А главная задача бэктесту — это разбирать свечи на более мелкие и смотреть где точно был вход, что случилось раньше тейк или стоп, время в сделке, просадки до тейка и т.д… Там много ценного можно увидеть.
Так вот: считаем всю историю какого нибудь LINK, это 3 года и 9.5 месяцев, сделок примерно 150 (±). Один сетап и 15000 рассчитывается сильно по-разному, зависит от конфигурации компа напрямую!
1) на core i3-13XXX один сетап считается около 20 секунд, и расчет не тупит пока нагрузка не превышает запущенных задач до 3 шт., дальше 100% загруз и замедляет частоты.
2) на core i7-13XXX уже 12 секунд на тот же сетап и задачек можно запустить до 7-8 штук без потери времени на каждую. Ну то есть они конечно суммируются, и при 7 запущенных бэктестах сетап считается не 12 секунд, а примерно 80 сек., но так как их запущено 7, то на 1 получается примерно то же самое.
3) а вот на камне i9-14900 один сетап считается уже за 9 секунд, а не за 12, и нагрузку камень тянет в 13 задач!
Это то, на чем я уже считал и фиксировал быстродействие. Горизонты обсчета параметров можно сильно расширить.
Как будет на Go — не знаю. БТ в планах пока. Может скормить код ИИшке и попросить переделать его в многопоточный режим? Посмотрим. Пока я ботом занят. Ну вот… Примерно так. Спасибо за добрые слова!
Михаил, да, об этом читал, но пока не применял Пометил себе на будущее попробовать использовать.
СПАСИБО!![]()
Я не люблю ни питон ни го, но такова истина.
Конечно это не истина, а моё мнение. Как человека который знает хорошо оба языка (и еще много других). Конечно же вы можете его игнорировать и мне в общем то пофиг.
На питоне есть куча инструментов именно для числодробилок. Всякие нейронки и научные вычисления на нем делают. И они наверняка будут работать даже быстрее чем банальный код на go за счет глубокой оптимизации библиотечек.