Производительность C++ по сравнению с языками Виртуальной машины в высокочастотных финансах
Я думал, что C/C++ по сравнению с вопросом о производительности C#/Java хорошо шагался, означая, что я считал достаточно доказательства, чтобы предположить, что языки VM не обязательно немного медленнее, чем языки "близко к кремнию". Главным образом, потому что JIT-компилятор может сделать оптимизацию, что статически скомпилированные языки не могут.
Однако я недавно получил CV от парня, который утверждает, что основанная на Java высокочастотная торговля всегда бьется C++, и что он был в ситуации, где это имело место.
Быстрый обзор на сайтах вакансий действительно показывает, что заявителям HFT нужно знание C++, и взгляд на форум Wilmott показывает всем практикам, говорящим о C++.
Есть ли какая-либо конкретная причина почему дело обстоит так? Я думал бы, что с современным финансовым бизнесом, являющимся несколько сложным, язык VM с безопасностью типов, управляемой памятью и богатой библиотекой будет предпочтен. Производительность выше тот путь. Плюс, JIT-компиляторы являются улучшением и лучше. Они могут сделать оптимизацию, когда программа работает, таким образом, Вы думали бы, что они - использование что информация во время выполнения для избиения производительности неуправляемой программы.
Возможно, эти парни пишут критические биты в C++ и и называют их от управляемой среды (P/Invoke и т.д.)? Это возможно?
Наконец, у кого-либо есть опыт с центральным вопросом в этом, которое является, почему в этом доменном неуправляемом коде без сомнения предпочтен по управляемому?
Насколько я могу сказать, парни HFT должны реагировать максимально быстро на входящие данные рынка, но это - не обязательно требование жесткого реального времени. Вы оказываетесь в худшем положении, если Вы являетесь медленными, это наверняка, но Вы не должны гарантировать определенную скорость на каждом ответе, Вам просто нужно быстрое среднее число.
Править
Право, несколько хороших ответов к настоящему времени, но довольно общий (хорошо шагавшая земля). Позвольте мне указать, какую программу парни HFT запустили бы.
Основной критерий является скоростью отклика. Когда порядок поступает в продажу, Вы хотите быть первыми, чтобы смочь реагировать на него. Если Вы опаздываете, кто-то еще мог бы взять его перед Вами, но каждая фирма имеет немного отличающуюся стратегию, таким образом, Вы могли бы быть в порядке, если одно повторение является немного медленным.
Прогоны программы целый день, почти ни с каким вмешательством пользователя. Независимо от того, что функция обрабатывает каждую новую часть данных рынка, выполненные десятки (даже сотни) времен секунда.
Эти фирмы обычно не имеют никакого предела относительно того, насколько дорогой аппаратные средства.
15 ответов
Во-первых, 1 мс - это вечность в HFT. Если вы думаете, что это не так, то было бы неплохо прочитать еще немного о домене. (Это как если бы вы находились в 100 милях от станции.) Пропускная способность и задержка глубоко взаимосвязаны, как вам скажут формулы в любом учебнике элементарной теории массового обслуживания.Те же формулы покажут значения джиттера (часто с преобладанием стандартного отклонения задержки очереди ЦП, если сетевая структура правильная и вы не настроили достаточно ядер).
Одна из проблем HFT-арбитража заключается в том, что, как только вы решаете зафиксировать спред, есть два (или более) этапа для получения прибыли. Если вам не удастся достичь всех легов, вы можете остаться с позицией, которая вам действительно не нужна (и последующим убытком) - в конце концов, вы занимались арбитражем, а не инвестировали.
Вам не нужны позиции, если ваша стратегия не предсказывает (ОЧЕНЬ ближайшую перспективу !!!) будущее (а это, хотите верьте, хотите нет, делается ОЧЕНЬ успешно). Если вы находитесь на расстоянии 1 мс от обмена, тогда значительная часть ваших заказов не будет выполнена, и то, что вы хотели, будет снято. Скорее всего, те, кто выполнил одну ногу, в конечном итоге окажутся в проигрыше или, по крайней мере, в убытке.
Какой бы ни была ваша стратегия, давайте скажем, что в итоге соотношение выигрышей / проигрышей составляет 55% / 45%. Даже небольшое изменение в соотношении выигрышей / проигрышей может иметь большое изменение прибыльности.
re: «запустить десятки (даже сотни)» кажется ошибочным на порядков Даже если посмотреть на 20000 тиков в секунду, кажется мало, хотя это может быть средним за весь день для набора инструментов, который он смотрит.
Скорости, наблюдаемые в каждую секунду, сильно различаются. Приведу пример.В некоторых из своих тестов я смотрю на 7 внебиржевых акций (CSCO, GOOG, MSFT, EBAY, AAPL, INTC, DELL) в середине дня, посекундная скорость для этого потока может варьироваться от 0 м / с (очень-очень редко) до почти 2000 котировок и сделок в пик-секунду. (посмотрите, почему я считаю, что приведенное выше значение 20000 является низким.)
Я создаю инфраструктуру и программное обеспечение для измерения для этой области, и цифры, о которых мы говорим, равны 100000 и миллионам в секунду. У меня есть библиотеки инфраструктуры производителя / потребителя C ++, которые могут передавать почти 5000000 (5 миллионов) сообщений в секунду между производителем и потребителем (32-битные ядра 2,4 ГГц). Это 64-байтовые сообщения с new, build, enqueue, synchronize на стороне производителя и synchronize, dequeue, касанием каждого байта, запуском виртуального деструктора, свободным на стороне потребителя. По общему признанию, это простой тест без ввода-вывода сокета (а ввод-вывод сокета может быть уродливым), как это было бы в конечных точках этапов конвейера конечной точки. Это ВСЕ настраиваемые классы синхронизации, которые синхронизируются только тогда, когда они пусты, настраиваемые распределители, очереди и списки без блокировки, случайные STL (с настраиваемыми распределителями), но чаще настраиваемые навязчивые коллекции (из которых у меня есть значительная библиотека). Не раз я давал производителю на этой арене четырехкратную (и более) пропускную способность без увеличения пакетной обработки на конечных точках сокета.
У меня есть классы OrderBook и OrderBook :: Universe, которые занимают менее 2 мкс для новой, вставки, поиска, частичного заполнения, поиска, второго заполнения, стирания, удаления последовательности при усреднении по 22000 инструментам.Тест выполняет итерацию по всем 22000 инструментам последовательно между первой и последней вставкой, поэтому не требуется дешевых трюков с кешированием. Операции с одной и той же книгой разделены доступом к 22000 разным книгам. Это в значительной степени НЕ характеристики кеширования реальных данных. Реальные данные гораздо более локализованы по времени, и последовательные сделки часто попадают в одну и ту же книгу.
Вся эта работа включает в себя тщательное рассмотрение констант и характеристик кэширования в любой из алгоритмических затрат используемых коллекций. (Иногда кажется, что K в K O (n) K O (n * log n) и т. Д. И т. Д. Отбрасываются слишком бойко)
Я работаю над Marketdata инфраструктурная сторона дела. Невозможно даже представить себе использование java или управляемой среды для этой работы. И когда вы можете получить такую производительность с C ++, и я думаю, что довольно сложно получить производительность в миллион + / mps с управляемой средой), я не могу представить себе какой-либо из крупных инвестиционных банков или хедж-фондов (для которых зарплата в 250000 долларов за первоклассный программист на C ++ - ничего) не идет с C ++.
Кто-нибудь действительно получает производительность 2000000 + / mps из управляемой среды? Я знаю несколько человек на этой арене, и никто никогда не хвастался мне этим. И я думаю, что 2 мм в управляемой среде будет иметь некоторые права на хвастовство.
Мне известен декодер порядка FIX одного крупного игрока, выполняющий 12000000 декодирований полей в секунду. (ЦП с частотой 3 ГГц) Это C ++, и тот, кто его написал, почти заставил кого-то что-то придумать. в управляемой среде это даже вдвое меньше.
Технологически это интересная область с множеством забавных задач по производительности. Рассмотрим рынок опционов при изменении базовой ценной бумаги - может быть, скажем, 6 непогашенных ценовых пунктов с 3 или 4 разными датами истечения срока. Теперь на каждую сделку приходилось примерно 10-20 котировок. Эти котировки могут вызвать изменение цен на опционы.Таким образом, для каждой сделки может быть 100 или 200 изменений котировок опционов. Это всего лишь тонна данных - а не объем данных, подобный детектору столкновений Большого адронного коллайдера, но все же небольшая проблема. Это немного отличается от нажатия клавиш.
Даже споры о FPGA продолжаются. Многие люди считают, что хорошо закодированный синтаксический анализатор, работающий на стандартном аппаратном обеспечении с тактовой частотой 3 ГГц, может превзойти FPGA с тактовой частотой 500 МГц. Но даже если они немного медленнее (не говоря уже о том, что это так), системы на базе FPGA могут иметь более жесткое распределение задержек. (Прочтите «склоняться» - это не общее заявление) Конечно, если у вас есть отличный синтаксический анализатор C ++, который вы проталкиваете через Cfront, а затем проталкиваете его через генератор изображений FPGA ... Но это еще одна дискуссия ...
Огромная причина предпочесть c++ (или более низкий уровень) в этом случае, помимо того, что уже было сказано, заключается в том, что есть некоторые преимущества адаптивности низкого уровня.
Если технология аппаратного обеспечения изменится, вы всегда можете заглянуть в __asm { } блок и фактически использовать его до того, как языки/компиляторы догонят его
Например, до сих пор нет поддержки SIMD в Java.
Возможно, это немного не по теме, но пару недель назад я посмотрел видео, которое может показаться вам интересным: http://ocaml.janestreet.com/?q=node/61
Оно снято торговой компанией, которая решила использовать ocaml в качестве основного языка для торговли, и я думаю, что их мотивы должны быть для вас поучительными (в основном, они, конечно, ценили скорость, но также сильную типизацию и функциональный стиль для более быстрого увеличения, а также более легкого понимания).
Простой факт в том, что C ++ разработан для скорости. C # / Java - нет.
Возьмите бесчисленные иерархии наследования, присущие этим языкам (например, IEnumerable), по сравнению с нулевыми накладными расходами std :: sort или std :: for_each, которые являются универсальными. Чистая скорость выполнения C ++ не обязательно выше, но программист может разрабатывать быстрые системы с нулевыми накладными расходами. Даже такие вещи, как переполнение буфера - вы не можете отключить их обнаружение. В C ++ все под контролем. По сути, C ++ - это быстрый язык - вы не платите за то, что не используете. Напротив, в C #, если вы используете, скажем, stackalloc, вы НЕ можете НЕ выполнять проверку переполнения буфера. Вы не можете размещать классы в стеке или непрерывно.
Есть еще и время компиляции, когда приложения на C ++ могут занимать гораздо больше времени, как на компиляцию, так и на разработку.
Есть причины использовать C++, кроме производительности. Существует ОГРОМНАЯ библиотека кода на C и C++. Переписывать все это на альтернативных языках нецелесообразно. Чтобы такие вещи, как P/Invoke, работали правильно, целевой код должен быть спроектирован так, чтобы его можно было вызвать из другого места. В противном случае вам придется написать какую-то обертку вокруг вещей, раскрывающих полностью C API, потому что вы не можете P/Invoke к классам C++.
Наконец, P/Invoke - это очень дорогая операция.
JIT-компиляторы становятся все лучше и лучше. Они могут выполнять оптимизацию по ходу выполнения программы
Да, они могут это делать. Но вы забываете, что любой компилятор C++ способен сделать те же самые оптимизации. Конечно, время компиляции будет хуже, но сам факт того, что такие оптимизации нужно делать во время выполнения, является накладным. Есть случаи, когда управляемые языки могут превзойти C++ в некоторых задачах, но это обычно связано с их моделями памяти, а не с оптимизацией во время выполнения. Строго говоря, вы, конечно, могли бы иметь такую модель памяти в C++, EDIT: как, например, в C# при работе со строками, /EDIT но немногие программисты C++ тратят столько времени на оптимизацию своего кода, как это делают ребята из JIT.
Есть некоторые проблемы с производительностью, которые являются неизбежным недостатком управляемых языков - а именно дисковый ввод-вывод. Это единовременные затраты, но в зависимости от приложения они могут быть значительными. Даже при самых лучших оптимизаторах вам все равно придется загружать с диска более 30 МБ JIT-компилятора при запуске программы; в то время как бинарные файлы C++ редко приближаются к такому размеру.
Эти фирмы обычно не ограничивают стоимость оборудования.
Если им также безразлично, насколько дорого стоит программное обеспечение, то я бы подумал, что, конечно, C ++ может быть быстрее: например, программист может использовать специально выделенную или предварительно выделенную память; и / или они могут запускать код в ядре (избегая кольцевых переходов), или на O / S в реальном времени, и / или иметь его тесную связь со стеком сетевых протоколов.
JIT-компилятор теоретически может выполнить множество оптимизаций, да, но как долго вы готовы ждать? Компиляция приложения на C++ может занять несколько часов, потому что это происходит в автономном режиме, и пользователь не сидит, постукивая пальцами, и не ждет.
JIT-компилятор должен завершить работу за пару миллисекунд. Итак, как вы думаете, кто может обойтись без наиболее сложных оптимизаций?
Сборщик мусора - тоже фактор. Не потому, что он медленнее, чем ручное управление памятью (я считаю, что его амортизированная стоимость довольно хороша, определенно сравнима с ручной обработкой памяти), но он менее предсказуем. Оно может привести к остановке в практически любой момент, что может быть неприемлемо в системах, которые должны быть чрезвычайно отзывчивыми.
И, конечно, языки поддаются разным оптимизациям. C++ позволяет писать очень плотный код, практически без накладных расходов на память, и где многие операции высокого уровня практически бесплатны (скажем, конструирование классов).
В C#, с другой стороны, вы тратите хороший кусок памяти. А простое создание класса влечет за собой значительные накладные расходы, поскольку базовый Object должен быть инициализирован, даже если ваш реальный класс пуст.
C++ позволяет компилятору агрессивно удалять неиспользуемый код. В C# большая часть кода должна быть там, чтобы его можно было найти с помощью рефлексии.
С другой стороны, в C# нет указателей, которые являются кошмаром оптимизирующего компилятора. И выделение памяти в управляемом языке намного дешевле, чем в C++.
Преимущества есть в любом случае, поэтому наивно ожидать, что вы сможете получить простой ответ "одно или другое". В зависимости от конкретного исходного кода, компилятора, ОС, аппаратного обеспечения, на котором он работает, один или другой может быть быстрее. И в зависимости от ваших потребностей, сырая производительность может не быть целью №1. Возможно, вас больше интересует отзывчивость, предотвращение непредсказуемых задержек.
В целом, ваш типичный код на C++ будет работать аналогично эквивалентному коду на C#. Иногда быстрее, иногда медленнее, но, вероятно, разница не будет драматической.
Но опять же, это зависит от конкретных обстоятельств. И это зависит от того, сколько времени вы готовы потратить на оптимизацию. Если вы готовы потратить столько времени, сколько потребуется, код на C++ обычно может достичь лучшей производительности, чем на C#. Это просто требует много работы.
И еще одна причина, конечно, заключается в том, что большинство компаний, использующих C++, уже имеют большую базу кода на C++, которую они не хотят бросать. Она нужна им для продолжения работы, даже если они постепенно переводят (некоторые) новые компоненты на управляемый язык.
Во многом это сводится к простой разнице между фактом и теорией. Люди выдвинули теории , чтобы объяснить, почему Java должна быть (или, по крайней мере, может быть) быстрее, чем C ++. Большинство аргументов не имеют ничего общего с Java или C ++ как таковыми , но связаны с динамической и статической компиляцией, при этом Java и C ++ на самом деле являются не более чем примерами этих двух (хотя, конечно, можно компилировать Java статически или C ++ динамически). У большинства из этих людей есть контрольные точки, чтобы «доказать» свое утверждение. Когда эти тесты исследуются во всех подробностях, быстро становится очевидным, что во многих случаях они принимали довольно крайние меры, чтобы получить желаемые результаты (например, довольно много включить ) оптимизация при компиляции Java, но специально отключил оптимизацию при компиляции C ++).
Сравните это с игрой Computer Language Benchmarks Game , где практически любой может отправить запись, поэтому весь код имеет тенденцию быть оптимизированным до разумной степени (а в некоторых случаях даже необоснованная степень). Кажется довольно очевидным, что изрядное количество людей рассматривают это как соревнование, в котором сторонники каждого языка делают все возможное, чтобы «доказать», что их предпочтительный язык является лучшим. Так как любой может представить реализацию любой проблемы, особенно плохая отправка мало влияет на общие результаты. В этой ситуации C и C ++ становятся явными лидерами.
Хуже того, во всяком случае, эти результаты, вероятно, показывают Java в лучшем свете, чем это совершенно точно.В частности, тот, кто использует C или C ++ и действительно заботится о производительности, может (и часто будет) использовать компилятор Intel вместо g ++. Это , как правило, дает улучшение скорости по крайней мере на 20% по сравнению с g ++.
Правка (в ответ на пару вопросов, поднятых jalf, но на самом деле они слишком длинные, чтобы уместиться в комментариях):
указатели - кошмар для разработчиков оптимизаторов. Это действительно (совсем) немного преувеличивает. Указатели приводят к возможности сглаживания, что предотвращает определенную оптимизацию при определенных обстоятельствах. Тем не менее, встраивание в большинстве случаев предотвращает вредные эффекты (то есть компилятор может определить, есть ли наложение, а не всегда генерировать код в предположении, что оно может быть). Даже когда код действительно должен принимать псевдоним, кэширование минимизирует снижение производительности от этого (т.е. данные в кэше L1 только поминутно медленнее, чем данные в регистре). Предотвращение псевдонимов улучшит производительность C ++, но не так сильно, как вы думаете.
Распределение выполняется намного быстрее со сборщиком мусора. Конечно, верно, что распределитель по умолчанию во многих реализациях C ++ работает медленнее, чем то, что предоставляют большинство (текущих) распределителей со сборкой мусора. Это уравновешивается (по крайней мере, до некоторой степени) тем фактом, что выделения в C ++, как правило, находятся в стеке, что также быстро, тогда как в языке GC почти все выделения обычно находятся в куче.Хуже того, на управляемом языке вы обычно выделяете пространство для каждого объекта индивидуально, тогда как в C ++ вы обычно выделяете пространство для всех объектов в области видимости вместе.
Также верно, что C ++ напрямую поддерживает замену распределителей как глобально, так и для каждого класса, поэтому, когда / если скорость выделения действительно является проблемой, ее обычно довольно легко исправить.
В конечном счете, jalf прав: оба эти пункта несомненно отдают предпочтение «управляемым» реализациям. Однако степень этого улучшения следует держать в перспективе: их недостаточно, чтобы позволить динамически скомпилированным реализациям работать быстрее на большом количестве кода - даже не в тестах, разработанных с самого начала, чтобы максимально им помочь.
Edit2: Я вижу, что Джон Харроп попытался вставить свои две (миллиардные доли) цента. Для тех, кто не знает его, Джон был печально известным троллем и спамером в течение лет и, похоже, ищет новые возможности для сеять сорняки. Я бы попытался ответить на его комментарий подробно, но (как это типично для него) он состоит исключительно из неквалифицированных, неподдерживаемых обобщений, содержащих настолько мало фактического содержания, что осмысленный ответ невозможен. Все, что можно сделать, - это честно предупредить окружающих о том, что он стал известен как нечестный, корыстный и игнорируемый.
Слоном в комнате здесь является тот факт, что C++ быстрее, чем Java.
Мы все это знаем. Но мы также знаем, что если мы заявим об этом открыто, как я только что сделал, мы не сможем претендовать на участие в содержательной дискуссии на эту бесспорную тему. Насколько быстрее C++, чем Java для вашего приложения? Это похоже на спорную тему, но, увы, она всегда будет гипотетической, пока вы не реализуете свое приложение на обоих языках, и тогда не останется места для дебатов.
Давайте вернемся к вашей первой встрече по проектированию: Жесткое требование к вашему проекту - высокая производительность. Каждый в комнате подумает о C++ и еще нескольких компилируемых языках. Парень в комнате, который предложит Java или C#, должен будет обосновать это доказательствами (т.е. прототипом), а не гипотезами, не заявлениями поставщиков, не заявлениями на сайтах сплетен программистов и уж точно не бенчмарками "hello world".
В нынешнем состоянии, вы должны двигаться вперед с тем, что вы знаете, а не с тем, что гипотетически возможно.
Ники написал: «Не могли бы вы объяснить, что вы можете делать с потоками C ++, а не с, например, .NET-потоки? »
Потоки с .Net могут выполнять практически все, что могут выполнять потоки C ++, за исключением:
- Эффективного выполнения двоичного кода, инкапсулированного в COM. Например, чувствительные алгоритмы, которые, возможно, придется держать в секрете от разработчиков приложений. (Может быть актуально в HFT)
- Создание простых потоков, которые не исчерпывают ресурсы системы, с помощью коротких строительных блоков - обернутых API ОС и примитивов ОС для синхронизации и сигнализации. (Чрезвычайно актуально для параллельных алгоритмов для оптимизации производительности по времени в HFT)
- Увеличение пропускной способности приложения бизнес-процесса в 10 или более раз на том же оборудовании и с той же задержкой. (Не актуально для HFT)
- Увеличение в 100 и более раз количества одновременно обрабатываемых пользовательских взаимодействий на единицу оборудования. (Не актуально в HFT)
Использование большего количества ядер ЦП не может полностью компенсировать исчерпание системных ресурсов строительными блоками .Net, поскольку большее количество ядер ЦП является гарантией возникновения конфликта памяти.
Виртуальные механизмы выполнения (JVM или CLR из .Net) не позволяют структурировать работу эффективным по времени способом, поскольку экземпляры процессов не могут выполняться в таком количестве потоков, которое может потребоваться.
Напротив, простой C ++ позволяет выполнять параллельные алгоритмы и создавать объекты за пределами критических по времени путей выполнения. Это почти все - просто и элегантно. Кроме того, с C ++ вы платите только за то, что используете.
Одна из самых интересных вещей в C ++ - это то, что его показатели производительности не лучше, но более надежны .
Это не обязательно быстрее, чем Java / C # / ..., но оно одинаково во всех прогонах .
Как и в сети, иногда пропускная способность не так важна, как стабильная задержка .
Большую часть нашего кода приходится запускать в Грид-сети, состоящей из тысяч машин.
Я думаю, что эта среда меняет аргументы. Если разница между скоростью выполнения C ++ и C # составляет, например, 25%, тогда в игру вступают другие факторы. Когда это выполняется в сетке, может не иметь значения, как он кодируется, поскольку весь процесс, однажды распределенный по машинам, может не быть проблемой или решен путем выделения или покупки еще нескольких машин. Наиболее важным вопросом и стоимостью может стать «время выхода на рынок», где C # может оказаться лучшим и более быстрым вариантом.
Какой C ++ или C # быстрее?
C # на шесть месяцев ......
Это не только вопрос языка программирования, аппаратное обеспечение и операционная система будут иметь значение.
Наилучшую общую производительность вы получите с операционной системой реального времени, языком программирования реального времени и эффективным (!) программированием.
Итак, у вас довольно много возможностей при выборе операционной системы, и несколько возможностей при выборе языка. Есть C, Realtime Java, Realtime Fortran и некоторые другие.
Или, может быть, вы добьетесь наилучших результатов в программировании ПЛИС/процессора, чтобы отказаться от затрат на операционную систему.
Самый большой выбор, который вам предстоит сделать, сколько возможных оптимизаций производительности вы проигнорируете в пользу выбора языка, который облегчит разработку и будет работать более стабильно, потому что вы сможете сделать меньше ошибок, что приведет к большей доступности системы. Это не следует упускать из виду. Вы не выиграете, если разработаете приложение, которое работает на 5% быстрее, чем любое другое приложение, которое падает каждые несколько точек из-за незначительных труднонаходимых ошибок.
В HFT задержка является более серьезной проблемой, чем пропускная способность. Учитывая присущий источнику данных параллелизм, вы всегда можете добавить больше ядер для решения проблемы, но вы не сможете компенсировать время отклика дополнительным оборудованием. Независимо от того, скомпилирован ли язык заранее или точно в срок, сборка мусора может уменьшить вашу задержку. Существуют JVM реального времени с гарантированной задержкой сборки мусора. Это довольно новая технология, которую сложно настраивать и до смешного дорого, но если у вас есть ресурсы, это можно сделать. Вероятно, в ближайшие годы он станет гораздо более популярным, поскольку первые последователи финансируют исследования и разработки, которые проводятся сейчас.