Один из наиболее часто задаваемых вопросов, который я получаю в почтовом ящике: "Какой лучший язык программирования для алгоритмической торговли?" Короткий ответ заключается в том, что нет "лучшего" языка. Стратегические параметры, производительность, модульность, развитие, устойчивость и стоимость должны быть рассмотрены. В этой статье будут изложены необходимые компоненты архитектуры алгоритмической торговой системы и то, как решения, касающиеся реализации, влияют на выбор языка.
Во-первых, будут рассмотрены основные компоненты алгоритмической торговой системы, такие как инструменты исследования, оптимизатор портфеля, менеджер рисков и движок исполнения. Затем будут изучены различные стратегии торговли и то, как они влияют на конструкцию системы. В частности, будут обсуждены частота торговли и вероятный объем торговли.
После выбора торговой стратегии необходимо разработать архитектуру всей системы. Это включает в себя выбор аппаратного обеспечения, операционной системы и устойчивость системы к редким, потенциально катастрофическим событиям.
Что пытается сделать торговая система?
Перед тем, как принять решение о языке, с помощью которого написать автоматизированную торговую систему, необходимо определить требования. Будет ли система исключительно основана на выполнении? Будет ли системе нужен модуль управления рисками или модуль построения портфеля? Будет ли системе нужен высокопроизводительный бэкстестер? Для большинства стратегий торговую систему можно разделить на две категории: исследование и генерация сигналов.
Исследования связаны с оценкой эффективности стратегии по сравнению с историческими данными. Процесс оценки торговой стратегии по сравнению с предыдущими данными рынка известен как бэкстестинг. Размер данных и алгоритмическая сложность окажут большое влияние на вычислительную интенсивность бэкстестера. Скорость процессора и одновременность часто являются ограничивающими факторами в оптимизации скорости выполнения исследований.
Генерация сигналов связана с генерацией набора торговых сигналов из алгоритма и отправкой таких заказов на рынок, обычно через брокерскую службу. Для определенных стратегий требуется высокий уровень производительности. Вопросы ввода/вывода, такие как пропускная способность сети и задержка, часто являются ограничивающим фактором в оптимизации систем исполнения. Таким образом, выбор языков для каждого компонента всей системы может быть довольно разным.
Вид, частота и объем стратегии
Тип используемой алгоритмической стратегии окажет существенное влияние на дизайн системы. Необходимо учитывать рынки, на которых торгуются, подключение к внешним поставщикам данных, частоту и объем стратегии, компромисс между простотой разработки и оптимизацией производительности, а также любое пользовательское оборудование, включая совместно расположенные пользовательские серверы, GPU или FPGA, которые могут быть необходимы.
Технологический выбор для низкочастотной стратегии американских акций будет сильно отличаться от выбора высокочастотной статистической стратегии арбитража на фьючерсном рынке.
Необходимо будет учитывать подключение к поставщику, структуру любых API, своевременность данных, требования к хранению и устойчивость перед лицом того, что поставщик выходит из сети. Также целесообразно иметь быстрый доступ к нескольким поставщикам! Различные инструменты все имеют свои собственные причуды хранения, примеры которых включают несколько символов тикеров для акций и даты истечения срока действия фьючерсов (не говоря уже о каких-либо конкретных внебиржевых данных).
Частота стратегии, вероятно, будет одним из самых больших факторов, определяющих, как будет определяться технологический стек.
Стратегия, превышающая вторые бары (т.е. данные о тиках), приводит к разработке, основанной на производительности, как основное требование. Для высокочастотных стратегий необходимо будет хранить и оценивать значительное количество рыночных данных.
Для обработки больших объемов данных, необходимых для приложений HFT, необходимо использовать широко оптимизированный бэктестер и систему исполнения. C / C ++ (возможно, с некоторым сборщиком) является наиболее сильным кандидатом на язык. Стратегии сверхвысокой частоты почти наверняка потребуют пользовательского оборудования, такого как FPGA, совместное расположение обмена и настройка интерфейса ядра / сети.
Исследовательские системы
Исследовательские системы, как правило, включают в себя смесь интерактивной разработки и автоматизированного сценария. Первый часто происходит в рамках IDE, таких как Visual Studio, MatLab или R Studio. Последний включает в себя обширные численные вычисления по многочисленным параметрам и точкам данных. Это приводит к выбору языка, обеспечивающего простую среду для тестирования кода, но также обеспечивает достаточную производительность для оценки стратегий по нескольким параметрам.
Типичные IDE в этом пространстве включают Microsoft Visual C ++ / C #, который содержит обширные утилиты отладки, возможности завершения кода (через
Для численного бэкстестинга все вышеперечисленные языки подходят, хотя не обязательно использовать GUI/IDE, так как код будет выполняться
Интерпретируемые языки, такие как Python, часто используют высокопроизводительные библиотеки, такие как NumPy / panda, для этапа бэкстестинга, чтобы поддерживать разумную степень конкурентоспособности с составленными эквивалентами. В конечном итоге язык, выбранный для бэкстестинга, будет определяться конкретными алгоритмическими потребностями, а также диапазоном доступных библиотек на языке (подробнее об этом ниже).
Конструкция портфеля и управление рисками
Портфель строительства и компоненты управления рисками часто игнорируются розничными алгоритмическими трейдерами. Это почти всегда ошибка. Эти инструменты обеспечивают механизм, с помощью которого будет сохранен капитал. Они не только пытаются уменьшить количество рискованных ставок, но и минимизировать отток самих сделок, снижая затраты на транзакции.
Софистицированные версии этих компонентов могут оказывать значительное влияние на качество и последовательность прибыльности. Создание стабильной стратегии легко, поскольку механизм построения портфеля и менеджер рисков могут быть легко изменены для обработки нескольких систем. Таким образом, они должны рассматриваться как важные компоненты в начале разработки алгоритмической торговой системы.
Задача системы построения портфеля заключается в том, чтобы взять набор желаемых сделок и произвести набор фактических сделок, которые минимизируют отток, поддерживают воздействие различных факторов (таких как сектора, классы активов, волатильность и т. д.) и оптимизируют распределение капитала в различные стратегии в портфеле.
Строительство портфеля часто сводится к проблеме линейной алгебры (например, факторизации матрицы), и, следовательно, производительность сильно зависит от эффективности доступной реализации численной линейной алгебры. Общие библиотеки включают uBLAS, LAPACK и NAG для C ++. MatLab также обладает широко оптимизированными матричными операциями. Python использует NumPy / SciPy для таких вычислений.
Управление рисками является еще одной чрезвычайно важной частью алгоритмической торговой системы. Риск может иметь множество форм: повышенная волатильность (хотя это может рассматриваться как желательно для определенных стратегий!), повышенная корреляция между классами активов, дефолт контрагента, сбои серверов, события "черного лебедя" и незамеченные ошибки в торговом коде, чтобы назвать несколько.
Компоненты управления рисками пытаются предсказать последствия чрезмерной волатильности и корреляции между классами активов и их последующее влияние на торговый капитал. Часто это сводится к набору статистических вычислений, таких как Монте-Карло
Системы исполнения
Задача системы исполнения заключается в том, чтобы получать отфильтрованные торговые сигналы от компонентов построения портфеля и управления рисками и отправлять их в брокерский или другой способ доступа на рынок. Для большинства розничных алгоритмических торговых стратегий это включает в себя API или FIX соединение с брокерским агентством, таким как Interactive Brokers.
Большинство API предоставляют интерфейс C++ и/или Java. Как правило, сообщество должно разрабатывать языковые обертывания для C#, Python, R, Excel и MatLab. Обратите внимание, что при каждом дополнительном плагине, используемом (особенно API-обертывания), есть возможность проникновения ошибок в систему. Всегда тестируйте плагины такого рода и убедитесь, что они активно поддерживаются.
Частота выполнения имеет первостепенное значение в алгоритме выполнения. Обратите внимание, что сотни заказов могут быть отправлены каждую минуту, и, как таковая производительность является критической.
Статически типированные языки (см. ниже), такие как C ++ / Java, как правило, оптимальны для выполнения, но есть компромисс во времени разработки, тестировании и простоте обслуживания. Динамически типированные языки, такие как Python и Perl, теперь, как правило, достаточно быстры. Всегда убедитесь, что компоненты спроектированы модульно (см. ниже), чтобы их можно было "заменить" по мере масштабирования системы.
Процесс архитектурного планирования и развития
Компоненты торговой системы, ее частота и объем требований были обсуждены выше, но инфраструктура системы еще не охвачена. Те, кто действует в качестве розничного трейдера или работает в небольшом фонде, вероятно, будут "носить много шляп". Необходимо будет охватить альфа-модель, управление рисками и параметры исполнения, а также окончательную реализацию системы. Перед тем как углубляться в конкретные языки, будет обсуждаться проектирование оптимальной архитектуры системы.
Разделение забот
Одно из самых важных решений, которое должно быть принято с самого начала, - это как "отделить интересы" торговой системы.
Для торговли сверхвысокой частотой правила могут быть проигнорированы за счет корректировки системы для еще большей производительности. Может быть желательна более тесно связанная система.
Однако оптимальный подход заключается в том, чтобы убедиться, что существуют отдельные компоненты для ввода данных рынка в историческом и реальном времени, хранения данных, API доступа к данным, бэкстера, параметров стратегии, построения портфеля, управления рисками и автоматизированных систем исполнения.
Например, если используемое хранилище данных в настоящее время неэффективно, даже при значительном уровне оптимизации, его можно заменить с минимальными перезаписками в API приема данных или доступа к данным.
Еще одно преимущество отдельных компонентов заключается в том, что они позволяют использовать различные языки программирования в общей системе. Нет необходимости ограничиваться одним языком, если метод связи компонентов является языковым независимым. Это будет иметь место, если они общаются через TCP / IP, ZeroMQ или какой-либо другой языковой независимый протокол.
В качестве конкретного примера рассмотрим случай, когда система обратного тестирования написана на C++ для производительности
Учитывание производительности
Для большинства торговых стратегий производительность является важным фактором. Для стратегий с более высокой частотой она является наиболее важным фактором.
Преобладающая мудрость, как заявил Дональд Кнут, один из отцов компьютерной науки, заключается в том, что "преждевременная оптимизация - это корень всего зла". Это почти всегда так - за исключением при создании алгоритма торговли с высокой частотой! Для тех, кто интересуется стратегиями с более низкой частотой, распространенным подходом является создание системы самым простым способом и оптимизация только по мере появления узких мест.
Профилирование инструментов используется для определения, где возникают узкие места. Профили могут быть сделаны для всех факторов, перечисленных выше, либо в среде MS Windows или Linux. Для этого есть много операционных систем и языковых инструментов, а также сторонних утилит. Выбор языка теперь будет обсуждаться в контексте производительности.
C++, Java, Python, R и MatLab содержат высокопроизводительные библиотеки (либо как часть их стандарта, либо внешне) для базовой структуры данных и алгоритмической работы.
Одним из исключений является то, что требуется высококастомизированная аппаратная архитектура, и алгоритм широко использует проприетарные расширения (например, пользовательские кэши). Однако часто "переизобретение колеса" тратит время, которое лучше потратить на разработку и оптимизацию других частей торговой инфраструктуры.
Задержка часто является проблемой системы исполнения, поскольку исследовательские инструменты обычно расположены на одной и той же машине. Для первых задержка может возникать в нескольких точках вдоль пути выполнения.
Для операций с более высокой частотой необходимо хорошо ознакомиться с оптимизацией ядра, а также оптимизацией сетевой передачи.
Кэширование очень полезно в наборе инструментов разработчика количественной торговли. Кэширование относится к концепции хранения часто доступных данных таким образом, который позволяет получить более высокую производительность доступа, за счет потенциальной застойности данных.
Для торговых ситуаций кэширование может быть чрезвычайно полезным. Например, текущее состояние портфеля стратегии может храниться в кэше до его ребалансировки, так что список не должен регенерироваться при каждой петле алгоритма торговли. Такая регенерация, вероятно, будет высокой операцией CPU или диска I / O.
Тем не менее, кэширование не без проблем. Регенерация данных кэша сразу, из-за изменчивого характера кэша, может создать значительный спрос на инфраструктуру.
Динамическое распределение памяти является дорогостоящей операцией при выполнении программного обеспечения. Таким образом, для приложений с высокой производительностью необходимо хорошо знать, как распределяется и распределяется память во время потока программы. Новые языковые стандарты, такие как Java, C # и Python, выполняют автоматический сбор мусора, что относится к распределению динамически распределенной памяти, когда объекты выходят из сферы действия.
Сбор мусора чрезвычайно полезен во время разработки, поскольку он уменьшает ошибки и облегчает читаемость. Тем не менее, он часто не является оптимальным для определенных высокочастотных торговых стратегий.
C++ не предоставляет нативный сборщик мусора, поэтому необходимо обрабатывать все распределение / распределение памяти в рамках реализации объекта. Хотя потенциально подвержены ошибкам (возможно, что приводит к висящим указателям), чрезвычайно полезно иметь тонкий контроль над тем, как объекты появляются на куче для определенных приложений. При выборе языка обязательно изучите, как работает сборщик мусора и можно ли его модифицировать для оптимизации для конкретного случая использования.
Многие операции в алгоритмических торговых системах подвержены параллелизации. Это относится к концепции выполнения нескольких программных операций одновременно, т.е. параллельно.
Другие алгоритмы являются лишь частично параллелизируемыми. Симуляции динамики жидкостей являются таким примером, где область вычислений может быть разделена, но в конечном итоге эти области должны взаимодействовать друг с другом, и, таким образом, операции частично последовательны. Параллелизуемые алгоритмы подчиняются закону Амдаля, который обеспечивает теоретический верхний предел увеличения производительности параллелизированного алгоритма при подчинении NN отдельным процессам (например, на ядре или нитке ЦП).
Параллелизация стала все более важной в качестве средства оптимизации, поскольку тактовые скорости процессоров стагнировали, поскольку новые процессоры содержат много ядер, с помощью которых можно выполнять параллельные вычисления.
В настоящее время большинство современных языков поддерживают некоторую степень одновременности / многопотока. Таким образом, оптимизировать бэкстестер легко, поскольку все расчеты, как правило, независимы от других.
В области разработки программного обеспечения и операций масштабирование относится к способности системы обрабатывать постоянно увеличивающиеся нагрузки в виде больших запросов, более высокого использования процессора и большего распределения памяти.
В то время как системы должны быть разработаны для масштабирования, часто трудно заранее предсказать, где произойдет узкое место. Строгое регистрирование, тестирование, профилирование и мониторинг будут очень помогать в масштабировании системы. Сами языки часто описываются как "немасштабируемые". Это обычно является результатом дезинформации, а не твердого факта. Это общая технология, которая должна быть установлена для масштабируемости, а не язык. Очевидно, некоторые языки имеют большую производительность, чем другие в конкретных случаях использования, но один язык никогда не "лучше" другого во всех смыслах.
Одним из способов управления масштабом является разделение забот, как указано выше. Для дальнейшего внедрения возможности обработки
Вместо того, чтобы запросы терялись, они просто хранятся в стеке, пока сообщение не будет обработано. Это особенно полезно для отправки сделок в движок исполнения. Если движок страдает от большой задержки, то он будет поддерживать сделки. Очередь между генератором торговых сигналов и API исполнения облегчит эту проблему за счет потенциального скольжения торговли.
Аппаратное обеспечение и операционные системы
Аппаратное обеспечение, на котором работает ваша стратегия, может оказать значительное влияние на рентабельность вашего алгоритма. Это не проблема, ограничивающаяся высокочастотными трейдерами. Плохой выбор в аппаратном обеспечении и операционной системе может привести к сбою или перезагрузке машины в самый неподходящий момент. Таким образом, необходимо рассмотреть, где будет находиться ваше приложение. Выбор обычно между персональным настольным компьютером, удаленным сервером, провайдером
Настольные компьютеры просты в установке и администрировании, особенно с более новыми удобными для пользователя операционными системами, такими как Windows 7/8, Mac OSX и Ubuntu. Настольные системы обладают некоторыми значительными недостатками, однако, главное заключается в том, что версии операционных систем, предназначенных для настольных компьютеров, вероятно, потребуют перезагрузки / исправления (и часто в худшие времена!).
Использование оборудования в домашней (или локальной офисной) среде может привести к проблемам с подключением к Интернету и работоспособностью.
Выделенный сервер или облачная машина, хотя часто более дорогая, чем вариант настольного компьютера, позволяет более значительную инфраструктуру избыточности, такую как автоматизированные резервные копии данных, возможность более простой обеспечения времени работы и удаленного мониторинга.
В Windows это обычно происходит через GUI Remote Desktop Protocol (RDP). В системах на базе Unix используется командная строка Secure SHell (SSH).
Колокационный сервер, как используется на рынках капитала, - это просто выделенный сервер, который находится в бирже, чтобы уменьшить задержку алгоритма торговли.
Последний аспект выбора аппаратного обеспечения и выбора языка программирования - независимость от платформы. Есть ли необходимость в том, чтобы код работал на нескольких различных операционных системах? Разработан ли код для работы на определенном типе архитектуры процессора, такой как Intel x86/x64, или можно будет выполнять на процессорах RISC, таких как те, которые производит ARM? Эти вопросы будут сильно зависеть от частоты и типа стратегии, которая реализуется.
Устойчивость и испытания
Одним из лучших способов потерять много денег на алгоритмической торговле является создание системы без устойчивости. Это относится к долговечности системы при редких событиях, таких как банкротства брокерских компаний, внезапная чрезмерная волатильность, простой во всем регионе для поставщика облачных серверов или случайное удаление всей торговой базы данных. Годы прибыли могут быть устранены в течение нескольких секунд с плохой архитектурой. Абсолютно важно учитывать такие вопросы, как отладка, тестирование, регистрация, резервные копии, высокая доступность и мониторинг в качестве основных компонентов вашей системы.
Вполне вероятно, что в любом достаточно сложном пользовательском количественном торговом приложении по меньшей мере 50% времени разработки будет потрачено на отладку, тестирование и обслуживание.
Почти все языки программирования либо поставляются с связанным отладщиком, либо имеют уважаемые сторонние альтернативы. По сути, отладчик позволяет выполнять программу с вставкой произвольных точек перерыва в путь кода, которые временно останавливают выполнение для того, чтобы исследовать состояние системы.
Дебагирование является важным компонентом инструментария для анализа ошибок программирования. Однако они более широко используются в компилированных языках, таких как C ++ или Java, поскольку интерпретируемые языки, такие как Python, часто проще для отладки из-за меньшего количества LOC и менее сложных заявлений. Несмотря на эту тенденцию, Python поставляется с pdb, который является сложным инструментом отладки.
Тестирование в разработке программного обеспечения относится к процессу применения известных параметров и результатов к конкретным функциям, методам и объектам в кодовой базе, с целью моделирования поведения и оценки нескольких путей кода, помогая гарантировать, что система ведет себя так, как она должна. Более поздняя парадигма известна как Test Driven Development (TDD), где тестовый код разрабатывается против определенного интерфейса без реализации. До завершения фактической кодовой базы все тесты будут неудачными.
TDD требует обширного дизайна спецификаций, а также здоровой степени дисциплины для успешного выполнения. В C ++, Boost предоставляет структуру для единичного тестирования. В Java библиотека JUnit существует для выполнения той же цели.
В производственной среде сложная регистрация является абсолютно необходимой. Регистрация относится к процессу вывода сообщений, с различной степенью тяжести, относительно поведения исполнения системы в плоский файл или базу данных. Регистрации являются "первой линией атаки" при поиске неожиданного поведения во время выполнения программы. К сожалению, недостатки системы регистрации, как правило, обнаруживаются только после того, как факт!
Как Microsoft Windows, так и Linux поставляются с обширными возможностями системного журналистики, и языки программирования, как правило, поставляются со стандартными библиотеками журналистики, которые охватывают большинство случаев использования.
В то время как регистрация системы предоставит информацию о том, что произошло в прошлом, мониторинг приложения предоставит представление о том, что происходит прямо сейчас.
Следует также постоянно контролировать такие показатели торговли, как ненормальные цены/объем, внезапные быстрые снижения и риск возникновения счетов на разных секторах/рынках. Кроме того, следует запустить систему пороговых значений, которая предоставляет уведомления при нарушении определенных показателей, повышая метод уведомления (электронная почта, SMS, автоматический телефонный звонок) в зависимости от степени тяжести показателя.
Мониторинг системы часто является доменом системного администратора или операционного менеджера. Однако, как единственный разработчик торговли, эти показатели должны быть установлены как часть более широкого дизайна. Существует много решений для мониторинга: проприетарные, хостинговые и открытые исходные коды, которые позволяют широко настраивать показатели для конкретного случая использования.
Запасные копии и высокая доступность должны быть главными проблемами торговой системы. Рассмотрим следующие два вопроса: 1) Если бы вся производственная база данных о рынке и истории торговли была удалена (без резервных копий), как это повлияло бы на алгоритм исследования и исполнения? 2) Если торговая система потерпит отключение в течение длительного периода (с открытыми позициями), как это повлияет на баланс счета и текущую прибыльность? Ответы на оба этих вопроса часто отрезвляют!
Необходимо установить систему резервного копирования данных, а также для тестирования восстановления таких данных. Многие люди не тестируют стратегию восстановления. Если восстановление после аварии не было протестировано в безопасной среде, какие гарантии существуют, что восстановление будет доступно в худший возможный момент?
Аналогичным образом, высокая доступность должна быть "заготовлена" с самого начала. Избыточная инфраструктура (даже при дополнительных расходах) всегда должна учитываться, поскольку стоимость простоя, вероятно, намного превышает текущую стоимость обслуживания таких систем. Я не буду углубляться в эту тему, поскольку это большая область, но убедитесь, что это одно из первых соображений, которые учитываются в вашей торговой системе.
Выбор языка
В настоящее время предоставлена значительная детализация различных факторов, возникающих при разработке пользовательской высокопроизводительной алгоритмической торговой системы.
Типовые системы
При выборе языка для торгового стека необходимо учитывать систему типов. Языки, которые представляют интерес для алгоритмической торговли, либо статически, либо динамически типируются. Статически типированный язык выполняет проверки типов (например, целых чисел, плавающих, пользовательских классов и т. д.) во время процесса компиляции. Такие языки включают C ++ и Java. Динамически типированный язык выполняет большую часть проверки типа во время выполнения. Такие языки включают Python, Perl и JavaScript.
Для высокоцифровой системы, такой как алгоритмическая торговая система, проверка типа во время компиляции может быть чрезвычайно полезной, поскольку она может устранить многие ошибки, которые в противном случае приводили бы к численным ошибкам. Однако проверка типа не хватает всего, и именно здесь приходит обработка исключений из-за необходимости обрабатывать неожиданные операции. Динамические языки (т. е. те, которые динамически типизируются) часто могут привести к ошибкам в время выполнения, которые в противном случае были бы обнаружены с проверкой типа в время компиляции. По этой причине возникла концепция TDD (см. выше) и единичного тестирования, которые при правильном выполнении часто обеспечивают большую безопасность, чем проверка времени компиляции в одиночку.
Другим преимуществом статически типированных языков является то, что компилятор способен производить множество оптимизаций, которые в противном случае недоступны для динамически типированного языка, просто потому, что тип (и, следовательно, требования к памяти) известны во время компиляции.
Открытый или собственный?
Один из самых больших выборов, доступных для разработчика алгоритмической торговли, - использовать ли собственные (коммерческие) или открытые технологии. Есть преимущества и недостатки обоих подходов. Необходимо учитывать, насколько хорошо поддерживается язык, активность сообщества, окружающего язык, простота установки и обслуживания, качество документации и любые расходы на лицензирование / обслуживание.
Microsoft.NET стек (включая Visual C++, Visual C#) и MathWorks
Microsoft и MathWorks оба предоставляют обширную высококачественную документацию для своих продуктов. Кроме того, сообщества, окружающие каждый инструмент, очень большие с активными веб-форумами для обоих. Программное обеспечение.NET позволяет сплоченную интеграцию с несколькими языками, такими как C ++, C # и VB, а также легкую связь с другими продуктами Microsoft, такими как база данных SQL Server через LINQ. MatLab также имеет много плагинов / библиотек (некоторые бесплатные, некоторые коммерческие) для практически любого домена количественного исследования.
Есть также недостатки. Для одинокого трейдера затраты не незначительны (хотя Microsoft предоставляет бесплатную версию Visual Studio начального уровня). Инструменты Microsoft хорошо взаимодействуют друг с другом, но менее хорошо интегрируются с внешним кодом. Visual Studio также должен выполняться на Microsoft Windows, который, возможно, гораздо менее эффективен, чем эквивалентный сервер Linux, который настроен оптимально.
MatLab также не имеет нескольких ключевых плагинов, таких как хороший оберток вокруг API интерактивных брокеров, одного из немногих брокеров, пригодных для высокопроизводительной алгоритмической торговли.
Одновременно с тем, как и в предыдущих изданиях, инструменты с открытым исходным кодом являются отраслевыми. Большая часть альтернативного пространства активов широко использует open-source Linux, MySQL / PostgreSQL, Python, R, C ++ и Java в высокопроизводительных производственных ролях. Однако они далеко не ограничены этой областью.
Основным преимуществом использования интерпретируемых языков является скорость времени разработки. Python и R требуют гораздо меньше строк кода (LOC) для достижения аналогичной функциональности, главным образом из-за обширных библиотек. Кроме того, они часто позволяют интерактивную консольную разработку, быстро уменьшая процесс итеративной разработки.
Учитывая, что время разработчика чрезвычайно ценно, а скорость выполнения часто меньше (за исключением HFT-пространства), стоит уделить большое внимание стеку технологий с открытым исходным кодом. Python и R обладают значительными сообществами разработчиков и чрезвычайно хорошо поддерживаются из-за их популярности.
Открытый исходный код часто страдает от отсутствия специального коммерческого контракта поддержки и работает оптимально на системах с менее терпимыми пользовательскими интерфейсами. Типичный сервер Linux (например, Ubuntu) часто будет полностью ориентирован на командную строку. Кроме того, Python и R могут быть медленными для определенных задач выполнения. Существуют механизмы интеграции с C ++, чтобы улучшить скорость выполнения, но для этого требуется некоторый опыт в многоязычном программировании.
В то время как проприетарное программное обеспечение не застраховано от проблем с зависимостью / версиями, намного реже приходится иметь дело с неправильными версиями библиотек в таких средах.
Я буду рисковать своим личным мнением здесь и утверждать, что я создаю все мои торговые инструменты с открытыми технологиями. В частности, я использую: Ubuntu, MySQL, Python, C ++ и R. Зрелость, размер сообщества, способность глубоко копаться, если возникают проблемы и более низкая общая стоимость владения (TCO) намного перевешивают простоту проприетарных GUIs и более легкие установки. Сказав это, Microsoft Visual Studio (особенно для C ++) является фантастической интегрированной средой разработки (IDE), которую я также очень рекомендую.
Батареи включены?
Заголовок этого раздела относится к возможностям языка - какие библиотеки он содержит и насколько они хороши? Это то, где зрелые языки имеют преимущество перед более новыми вариантами.
C++ славится своей библиотекой стандартных шаблонов (STL), которая содержит множество высокопроизводительных структур данных и алгоритмов - бесплатно. Python известен тем, что может общаться практически с любым другим типом системы / протокола (особенно с веб), в основном через свою собственную стандартную библиотеку. R имеет множество статистических и эконометрических инструментов, в то время как MatLab чрезвычайно оптимизирован для любого цифрового линейного алгебрического кода (который можно найти в оптимизации портфеля и ценообразовании производных, например).
Помимо стандартных библиотек, C++ использует библиотеку Boost, которая заполняет "пропавшие части" стандартной библиотеки.
Python имеет высокопроизводительную комбинацию библиотеки анализа данных NumPy/SciPy/Pandas, которая получила широкое признание для исследований алгоритмической торговли. Кроме того, существуют высокопроизводительные плагины для доступа к основным реляционным базам данных, таким как MySQL++ (MySQL/C++), JDBC (Java/MatLab), MySQLdb (MySQL/Python) и psychopg2 (PostgreSQL/Python). Python может даже общаться с R через плагин RPy!
Часто упускаемый аспект торговой системы на начальной стадии исследования и проектирования - это подключение к API брокера. Большинство API поддерживают C++ и Java, но некоторые также поддерживают C# и Python, либо напрямую, либо с оберточным кодом, предоставленным сообществом к API C++. В частности, к интерактивным брокерам можно подключиться через плагин IBPy. Если требуется высокая производительность, брокеры будут поддерживать протокол FIX.
Заключение
Как теперь очевидно, выбор языка программирования для алгоритмической торговой системы не является простым и требует глубокого обдумывания.
Преимущество отдельной архитектуры заключается в том, что она позволяет подключать языки для различных аспектов торгового стека по мере изменения требований.