09 октября 2025, 01:05
Сравнение C# и Python для построения торговых систем.
Для построения и отладки алгоритма, Python гораздо удобней, об этом даже и спорить не надо. Я выбрал Python не только для этого, но и для продакшн, т.е. для построения рабочей системы.
Многие мне говорили, что Python медленный, что все плохо и т.д. Понятно, что на С++ будет быстрее, но ты еще попробуй реализуй на С++ то, что на Python делается с помощью уже готовых и заведомо рабочих модулей. Потому будем сравнивать Python и С#, т.к. любителей С# тоже достаточно.
Я и раньше говорил, что если не рассматривать простейшие программы, скорости Python и С#, в общем, сравнимы. Но кто я такой, чтобы вы с этим соглашались.))
Решил этот вопрос задать ИИ. Беседа была достаточно продолжительной, касалась нескольких аспектов сравнения, по большинству из которых Python в заметном отрыве от С#.
Приведу итоговую таблицу сравнения, составленную ИИ по моей просьбе:
Думаю, комментировать здесь нечего.
Многие мне говорили, что Python медленный, что все плохо и т.д. Понятно, что на С++ будет быстрее, но ты еще попробуй реализуй на С++ то, что на Python делается с помощью уже готовых и заведомо рабочих модулей. Потому будем сравнивать Python и С#, т.к. любителей С# тоже достаточно.
Я и раньше говорил, что если не рассматривать простейшие программы, скорости Python и С#, в общем, сравнимы. Но кто я такой, чтобы вы с этим соглашались.))
Решил этот вопрос задать ИИ. Беседа была достаточно продолжительной, касалась нескольких аспектов сравнения, по большинству из которых Python в заметном отрыве от С#.
Приведу итоговую таблицу сравнения, составленную ИИ по моей просьбе:
Думаю, комментировать здесь нечего.
Читайте на SMART-LAB:
Официально первые 🚀
Вчера мы получили статус официального администратора индикаторов. Биржа стала первой организацией в реестре, а RUSFAR — первым официально зарегистрированным и прошедшим проверку регулятора...
25.12.2025
Президент «Норникеля» Владимир Потанин в интервью телеканалу «Россия 24» подвел итоги 2025 года, оценил макроэкономическую ситуацию и рассказал о технологической трансформации компании.
Собрали ключевые тезисы:
Макроэкономика и ключевая ставка 2025 год был сложным, но мы видим позитив: инфляцию удалось снизить до 6%. Это важно для сохранения покупательной способности...
26.12.2025
Россети Ленэнерго – Прибыль 9 мес 2025г: 28,937 млрд руб (+15% г/г) Россети Ленэнерго – рсбу/ мсфо
8 523 785 320 обыкновенных акций = 132,119 млрд руб
93 264 311 привилегированных акций = 28,063 ...
17:59
Россети Центр – Прибыль мсфо 9 мес 2025г: 9,395 млрд руб (+42% г/г) Россети Центр – рсбу/ мсфо
42 217 941 468 обыкновенных акций
www.e-disclosure.ru/portal/files.aspx?id=7985&type=1
Капит...
Алексей Зайцев, 22.12 нашел информацию что оценщик уже всё имущество оценил, вот только во сколько нигде не указано, осталось продать и может быть нам что-то перепадёт
Donbass, четвертый геп открывать? Снизу еще 3 гепа не звкрытые
17:39
Ещё один момент: в монополии знают законы и пользуются этим.
А вот представитель МПЦ Игорь Матвеев удивил незнанием того, где как и на основании чего можно проводить видеосъёмку. И этот человек в...
🟢 Темп в покупках не сбавляй, в ракете топливо пополняй…
💻 IT-отрасль — ждать ли улучшений в 2026?
IT выдали худший за длительное время год. На самом деле рынок не упал, как, например, ипотека или сталь. По прогнозу он вырастет на 3% в 2025. Но ...
🤔 Рубль начинают ослаблять?
Не раз говорили — рубль сдерживается государством в рамках борьбы с инфляцией.
Целевая инфляция почти достигнута. Что предпринимает регулятор:
▪️ Ежеднев...
17:19
с новым газом! Прошлый год прочитали газ, посмотрим план на этот Усем привет!
Разжевал позиционно ри и газ
по газу прошлый год весь удалось читать 5 волновку с манипуляцией трендовой и целями,...
Вот ответ ИИ на простой промпт о сравнении двух языков для целей алготрейдинга:
Вот уточнение ответа с учетом некоторых обстоятельств:
Там только чтобы в их меню и опциях в программе разобраться надо пару недель.
По мне так пофигу какой язык, главное, чтобы торговые системы робастые и прибыльные были.Всё остальное информационная шелуха.
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мс