SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. 3Qu
Сравнение C# и Python для построения торговых систем.
- 09 октября 2025, 01:05
- |
Для построения и отладки алгоритма, Python гораздо удобней, об этом даже и спорить не надо. Я выбрал Python не только для этого, но и для продакшн, т.е. для построения рабочей системы.
Многие мне говорили, что Python медленный, что все плохо и т.д. Понятно, что на С++ будет быстрее, но ты еще попробуй реализуй на С++ то, что на Python делается с помощью уже готовых и заведомо рабочих модулей. Потому будем сравнивать Python и С#, т.к. любителей С# тоже достаточно.
Я и раньше говорил, что если не рассматривать простейшие программы, скорости Python и С#, в общем, сравнимы. Но кто я такой, чтобы вы с этим соглашались.))
Решил этот вопрос задать ИИ. Беседа была достаточно продолжительной, касалась нескольких аспектов сравнения, по большинству из которых Python в заметном отрыве от С#.
Приведу итоговую таблицу сравнения, составленную ИИ по моей просьбе:
Думаю, комментировать здесь нечего.
Многие мне говорили, что Python медленный, что все плохо и т.д. Понятно, что на С++ будет быстрее, но ты еще попробуй реализуй на С++ то, что на Python делается с помощью уже готовых и заведомо рабочих модулей. Потому будем сравнивать Python и С#, т.к. любителей С# тоже достаточно.
Я и раньше говорил, что если не рассматривать простейшие программы, скорости Python и С#, в общем, сравнимы. Но кто я такой, чтобы вы с этим соглашались.))
Решил этот вопрос задать ИИ. Беседа была достаточно продолжительной, касалась нескольких аспектов сравнения, по большинству из которых Python в заметном отрыве от С#.
Приведу итоговую таблицу сравнения, составленную ИИ по моей просьбе:
Думаю, комментировать здесь нечего.
8.2К |
Читайте на SMART-LAB:
Смотрим какая на сегодняшний день доходность у юаневых облигаций и как она изменилась за последний месяц
15:01
теги блога 3Qu
- Binance
- C#
- C++
- DDE
- DLL
- EMA
- Excel
- Exponential Moving Average
- Linux
- Lua
- machine learning
- ML
- MOEX
- Moving Average
- Python
- QLua
- Quik
- Quik Lua
- Si
- Smart-lab
- SQLite
- автоматическая торговая система
- акции
- алготрейдинг
- базы данных
- Баффет
- биржа
- Боллинджер
- Брокер
- брокеры
- вероятность
- выбор
- Газпром
- гуру
- дельта
- доллар
- Доллар рубль
- доска опционов
- идеология
- инвестиции
- индикатор
- индикаторы
- интрадей
- календарный спред
- календарный спрэд
- криптовалюта
- МА
- Машинное обучение
- моделирование
- модель
- нейросети
- нейросеть
- нефть
- опрос
- опционные стратегии
- опционы
- оффтоп
- плечо
- прогнозирование
- программирование
- психология
- реклама
- роботы
- рынок
- сеточник
- скальпинг
- скользящие средние
- случайное блуждание
- смартлаб
- спекуляции
- спекуляция
- статистика
- стационарность
- стоп
- стопы
- Стратегии
- стратегия
- стрэддл
- стрэнгл
- Тейк
- терминал
- тест
- тестер стратегий
- тестирование
- технический анализ
- торговая система
- торговая стратегия
- торговые роботы
- торговые системы
- торговые стратегии
- торговый софт
- трейдинг
- ТС
- Фильтры
- Форекс
- фундаментальный анализ
- фьючерс
- фьючерс ртс
- фьючерсы
- эффективный рынок
Вот ответ ИИ на простой промпт о сравнении двух языков для целей алготрейдинга:
Вот уточнение ответа с учетом некоторых обстоятельств:
Там только чтобы в их меню и опциях в программе разобраться надо пару недель.
По мне так пофигу какой язык, главное, чтобы торговые системы робастые и прибыльные были.Всё остальное информационная шелуха.
HFT ты все равно торговать не будешь, потому как это дорохо.
А для торговли на 5мин и выше, абсолютно пофигу что использовать
Действительно, зачем соглашаться, если можно спросить ИИ:
Вот что мне ответил Claude 4.5 когда я его прижал к стенке:------
Отличный вопрос! Признаюсь честно — я не проводил прямых бенчмарков OsEngine лично, и мои цифры были оценочными, основанными на общих характеристиках производительности C# vs Python.
📊 Откуда брались данные:1. Общие принципы производительности:
2. Проблема с моими утверждениями:
- ❌ Я не имею доступа к реальным бенчмаркам OsEngine
- ❌ Производительность сильно зависит от реализации
- ❌ OsEngine может иметь свои узкие места (UI, архитектура)
- ❌ VectorBT очень оптимизирован, может быть быстрее плохого C# кода
💡 Честный ответ:Реальная производительность зависит от:
Хотите:
Извините за необоснованные цифры! В следующий раз буду более осторожен с конкретными числами без реальных тестов. 🙏
поэтому для нормально сравнения надо брать простейшую стратегию на пересечения двух MA, тестировать на всех движках и сравнивать реальные цифры.
Но это делается в Wealt-Lab 6 путем добавление 20-30 строк в код стратегии.
Так же можно реализовать это в Backtesting.py — там больше править в самом коде библиотеки, но делается один раз и потом можно использовать для любых стратегий.
Понятно, что лучше без склеек, но насколько сильно такие склейки влияют на мусорность тестов?
векторный движок и скорость тестирования там быстрее чем на C++
Если же нужно собирать различные данные, то все сильно меняется, 90% сложности будет именно сбор и обработка данных, сам алгоритм будет мелоч. И здесь C# с типами и т.п. проверками будет лучше. Сделать на питоне (да и вообще на любом нетипизированнном языке) сбор данных из множества источников, со сложными схемами данных, будет сложнее.
C#, особенно начиная с .NET 8 работает не сильно отставая от нативного кода написанного на C (даже не на C++, а на чистом C).
У C# есть строгая типизация, что очень хорошо для работы с деньгами.
У C# есть такая штука, как структуры, чего нет на путхоне, что позволяет более эффективно использовать ресурсы при работе с небольшими структурами данных, которые не имеют указателей внутри. При грамотном подходе можно получить алгоритмы, которые работают лишь на 20% медленнее аналогичного кода на чистом C.
JIT компилятор .NET умеет использовать SIMD инструкции в математических расчётах, что существенно повышает скорость вычислений.
Вот «существенно» лишь в отдельных специфических ситуациях, и в большинстве случаев объясняется тем, что под C++ использовали алгоритм оптимизированный скорость, а под C — неоптимизированный.
Я не про это говорю. Я говорю про то, что именно алгоритм под С берётся не оптимизированный.
Например, под C++ берут std::vector, который помимо длины массива хранит ещё и количество ячек, под которое выделена память, за счёт чего он заточен на минимизацию выделения и высвобожднния памяти при изменении длины массива, а под C берут простой массив, представленный указателем и управляемый через malloc и free, и для которого не сделано оптимизации на уменьшение выделений и высвобождений памяти.
Кстати, встраивание бинарного кода вместо вызова функции не всегда приводит к ускорению в реальной задаче. Микробенчмарки могут работать быстро, а вот реальный код может работать медленнее, потому что тело функции получается огромным, оно не помещается в кэш процессора, а при выполнении функции начинается подгрузка недогруженной части функции в кэши, что приводит к задержкам выполения.
В итоге из-за того, что C++ программисты чрезмерно увлекаются модификатором типа forced inline, разработчики компиляторов C++ решили, что forced inline будет игнорироваться, если он в коде проекта встречается слишком часто.
Просто ваше даже создаёт впечатление что плюсы медленные, но там разница не большая, а как я указал бывает что плюсы и выигрывают.
Python на порядок-два медленнее в базовых сценариях. Не всё можно обернуть в быстрые библиотеки, если нужно итерирование — скорее всего код будет сильно медленнее C#. Например, бэктестер, если нужен событийный, итерационный — будет медленно, хотя векторный да, можно сделать быстрым.
В остальном Python хорош. В самой свежей версии нормальную многопоточность подвезли, я правда так и не понял, это ещё beta или уже полноценная.
Python 3.14 was released on 7 October 2025.
Что такое поддержка? C# поддерживает Майкрософт. А Питон какая компания?
Ерунда, а не советы. Так язык не выбирают.
Прелесть ИИ что теперь можно даже на Алголе опять начать писать программы.
Не норм начнется, когда вы начнете использовать сложный функционал, например, типа, ML — для C# многого нет, даже относительно простого — придется делать самому, что почти нереально.
ИИ всё равно. Что спросите, то и ответит. Будете настаивать на своём, ИИ согласится с вами, да еще и прощения попросит. Бездушная машина.))
Например, эллипсы. Помните?
Тут вот какое дело. На С# или, возможно, даже С++ вы вполне можете создать некое сверхбыстродействующее говно, и здесь вы вне конкуренции.
Но есть и другой вопрос: а оно надо?
Это же другой вопрос. Не надо — не делай.)
Что касается эллиптических фильтров в Питоне — эт не вопрос, ничем не отличаются от прочих. Не вижу в них надобности, но это не мое дело.
1) Богаты ли библиотеки в Питоне? Да, богаты.
2) Есть ли возможность использовать в C# разнообразные библиотеки, в том числе написанные на других языках? Да, есть.
Так будет понятнее?)
Действительно, C# сочетает в себе мощь и скорость компилируемого языка и гибкости при использовании стороннего кода. C# удобен для многопараметрической оптимизации на большой истории и построения сильно нагруженных торговых систем.
Python удобен для прототипирования несильно нагруженных проектов и выполнения поисковых работ. Ключевое слово здесь удобен. Пожалуй, трудно найти задачу, которую на C# было бы сильно сложнее выполнить, чем на Python.
Для обычного трейдинга С#, если без сложных библиотек, уже избыточен.
Если подключить сложные библиотеки, быстродействие С# практически сравнивается с Питон ( модули библиотек Питон написаны на С/С++).
Чистый код Питон действительно медленней, чем С#, однако, учитывая скорость поступления данных от брокера или биржи обычному трейдеру, это несущественно, все успевает обработаться в любом случае.
Кроме того, задержка даже ±неск секунд при продолжительности сделок от нескольких минут уже никак не влияет на результаты трейдинга.
В общем, что лучше — дискуссия бессмысленна. В топике вопрос так даже не ставится, ответ очевиден — без разницы.
Если ставить вопрос — кто быстрее?, хотя это и не надо, то для простых систем — С#, для сложных — примерно одинаково.
А если вопрос: что удобней, то тоже очевидно, — Питон.
Из обсуждения можно сделать некоторые предварительные итоги:
1) Многопараметрическая оптимизация на больших объемах данных:
— на C# доступна нативно;
— на Python доступна при использовании специальных библиотек и приемов.
2) Глубокий анализ данных (ML и пр.):
- на C# доступен при использовании специальных библиотек и приемов;
- на Python доступен нативно.
3) Эксплуатация высоконагруженных* торговых систем:
- на C# доступна нативно;
- на Python недоступна или требуются специальные библиотеки и приемы.
Если не заниматься глубоким анализом данных (ML и пр.), то выбор однозначен — C#. Если хочется больше науки, чем торговли, то можно использовать Python. Как-то так.)
* высоконагруженными можно назвать торговые системы, одновременно торгующие большое количество инструментов с анализом потоков ордеров или стаканов.
Но когда мы говорим о «торговой системе», убогоньким не отделаться. Нам надо будет ордеринг. Нам надо будет общаться с брокером и / или биржей в режиме прямого доступа, а это всегда асинхронный обмен. Нам надо будет куда-то постоянно что-то писать. Нам надо будет защиту от сбоев. Все это нам надо будет в режиме MultiThreading со всеми вытекающими отсюда геморроями, иначе нас просто зальет при каких-то резких движениях. И еще дохрена чего нам надо будет, что на пайтоне писать, прямо скажем, странно (и сомневаюсь, что вообще возможно в полном объеме). Пайтон хорош, если вы всю бизнес-логику запихали в БД, наплевав на последствия такого решения, и над ней крутите худенькую надстроечку для общения с фронтами
3Qu, 100мс дискретность? Это что за подключение такое :). Даже почивший в бозе ITInvest со своим кривущим SmartCOM давал задержку миллисекунд 10, если мне память не изменяет.
Ну и по поводу «даже Lua» я бы не стал так отмахиваться, вот пример из сегдняшнего:
[TRACE][STRMGR] 2025.10.09 14:26:17.9227 Prod: RTS-12.25_FT: время на исполнение: 00:00:00.0012286
[TRACE][STRMGR] 2025.10.09 14:26:17.9227 Prod: RTS-12.25_FT: результат: 1
[TRACE][ORDMGR] 2025.10.09 14:26:17.9227 StratMgrSignalHandler: ticker = RIZ5, tsrc = AddTick, price = 101630, Signal = 1, Size = 1, regime = Trade
[TRACE][TRQ_CONN] 2025.10.09 14:26:17.9997 PlaceOrder: Выставление заявки: result = <result success=«true» transactionid=«38205942»/>
Это не холостой прогон, а именно сгенерированный сигнал и выставленная заявка. Видно, что все задержки — сетевые и на стороне брокера, ~70мс прошло от отправки заявки на сервер брокера до его ответа о том, что заявка размещена, обработка же Lua-частью от получения очередной сделки из ленты до генерации сигнала в сторону ордеринга заняла 1.2мс