Производительность языков C ++ и виртуальных машин в высокочастотных финансах - PullRequest
31 голосов
/ 04 июля 2010

Я думал, что вопрос о производительности C / C ++ и C # / Java был задуман, и это означало, что я прочел достаточно доказательств, чтобы предположить, что языки виртуальных машин не обязательно медленнее, чем языки "почти кремний" Главным образом потому, что JIT-компилятор может выполнять оптимизации, которые статически скомпилированные языки не могут.

Однако недавно я получил резюме от парня, который утверждает, что высокочастотная торговля на основе Java всегда побеждена C ++ и что он был в такой ситуации.

Быстрый просмотр рабочих мест действительно показывает, что кандидаты HFT нуждаются в знании C ++, а на форуме Wilmott видно, что все практикующие говорят о C ++.

Есть ли какая-то конкретная причина, почему это так? Я бы подумал, что в условиях современного финансового бизнеса, который является несколько сложным, предпочтение отдается языку VM с безопасностью типов, управляемой памятью и богатой библиотекой. Таким образом, производительность выше. Кроме того, JIT-компиляторы становятся все лучше и лучше. Они могут выполнять оптимизацию во время работы программы, поэтому вы можете подумать, что они используют эту информацию времени выполнения, чтобы повысить производительность неуправляемой программы.

Возможно, эти парни пишут критические биты на C ++ и вызывают их из управляемой среды (P / Invoke и т. Д.)? Это возможно?

Наконец, кто-нибудь имеет опыт решения основного вопроса в этом вопросе, поэтому неуправляемый код в этой области, без сомнения, предпочтительнее управляемого?

Насколько я могу судить, ребята из HFT должны как можно быстрее реагировать на поступающие рыночные данные, но это не обязательно жесткое требование в реальном времени . Вам хуже, если вы медлительны, это точно, но вам не нужно гарантировать определенную скорость при каждом ответе, вам просто нужно быстрое среднее.

EDIT

Правильно, пара хороших ответов на данный момент, но довольно общие (хорошо протоптанные земли). Позвольте мне указать, какую программу будут запускать парни HFT.

Основным критерием является отзывчивость. Когда ордер попадает на рынок, вы хотите первым отреагировать на него. Если вы опоздали, кто-то другой мог бы принять это перед вами, но у каждой фирмы есть немного другая стратегия, поэтому вы можете быть в порядке, если одна итерация немного медленная.

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

Эти фирмы, как правило, не имеют ограничений относительно стоимости оборудования.

Ответы [ 15 ]

1 голос
/ 04 июля 2010

Это не только вопрос языка программирования, к которому будет относиться аппаратное обеспечение и операционная система.
Наилучшую общую производительность вы получите с операционной системой реального времени, языком программирования реального времени и эффективным (!) Программированием.

Таким образом, у вас есть несколько возможностей выбора операционной системы и несколько вариантов выбора языка. Есть C, Realtime Java, Realtime Fortran и некоторые другие.

Или, возможно, у вас будут лучшие результаты при программировании ПЛИС / Процессора, чтобы исключить затраты на операционную систему.

Самый большой выбор, который вам нужно сделать, - сколько возможных оптимизаций производительности вы будете игнорировать в пользу выбора языка, который облегчит разработку и будет работать более стабильно, поскольку вы можете делать меньше ошибок, что приведет к более высокой доступности система. Это не следует упускать из виду. Вы не можете выиграть в разработке приложения, которое работает на 5% быстрее, чем любое другое приложение, которое падает каждые несколько точек из-за незначительных ошибок, которые трудно найти.

0 голосов
/ 07 июля 2010

Ники писал: «Не могли бы вы объяснить, что вы можете делать с потоками C ++, а не, например, с потоками .NET?»

Потоки с .Net могут выполнять практически все, что может C ++, за исключением:

  1. Эффективное выполнение COM-инкапсулированного двоичного кода.Например, чувствительные алгоритмы, которые, возможно, следует держать в секрете от разработчиков приложений.(Может быть уместно в HFT)
  2. Создание скудных потоков, которые не исчерпывают системные ресурсы с помощью объемных строительных блоков - обернутых API-интерфейсов ОС и примитивов ОС синхронизации и сигнализации.(Чрезвычайно актуально для параллельных алгоритмов оптимизации времени в HFT)
  3. Увеличение пропускной способности приложения для бизнес-процессов в 10 и более раз на одном и том же оборудовании с одинаковой задержкой.(Не относится к HFT)
  4. Увеличение в 100 и более раз числа одновременно обрабатываемых взаимодействий пользователя на единицу оборудования.(Не относится к HFT)

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

0 голосов
/ 06 июля 2010

Слон в комнате здесь - факт, что C ++ быстрее чем Java .

Мы все это знаем.Но мы также знаем, что, если мы прямо заявим, как я только что сказал, что мы не можем притворяться, что участвуем в значимой дискуссии по этой несомненной теме.Насколько намного быстрее C ++, чем Java для вашего приложения ?Это похоже на дискуссионную тему, но, увы, она всегда будет гипотетической, если вы не реализуете свое приложение на обоих языках, после чего в нем не будет места для дискуссий.

Давайте вернемся к вашей первой встрече дизайнеров: жестким требованием для вашего проекта является высокая производительность.Все в комнате будут думать «C ++» и несколько других скомпилированных языков.Парень в комнате, который предлагает Java или C #, должен будет обосновать это доказательствами (т. Е. Прототипом), а не гипотетическими соображениями, не заявлениями продавцов, не заявлениями на сайтах сплетен программистов и, конечно же, не "приветмировые "ориентиры.

В нынешнем виде, вы должны двигаться вперед с тем, что вы знаете , а не с тем, что гипотетически возможно.

0 голосов
/ 05 июля 2010

Виртуальные исполнительные механизмы (JVM или CLR .Net) не позволяют структурировать работу с минимальными затратами времени, так как экземпляры процессов не могут работать на столько потоков, сколько может потребоваться.

В отличие от этого, простой C ++ позволяет выполнять параллельные алгоритмы и создавать объекты вне критических по времени путей выполнения. Это почти все - просто и элегантно. Кроме того, с C ++ вы платите только за то, что используете.

0 голосов
/ 04 июля 2010

Огромная причина для предпочтения с ++ (или более низкого уровня) в этом случае, помимо того, что уже было сказано, заключается в том, что есть некоторые преимущества адаптивности, так как низкий уровень .

Если изменяется аппаратная технология, вы всегда можете зайти в блок __asm { } и использовать его до того, как языки / компиляторы догонят

Например, все еще не поддерживает SIMD в Java.

...