Торговые системы с низкой задержкой, использующие C ++ в Windows? - PullRequest
13 голосов
/ 29 августа 2010

Кажется, что все крупные инвестиционные банки используют C ++ в Unix (Linux, Solaris) для своих серверных приложений с низкой задержкой / высокой частотой. Почему Windows обычно не используется в качестве платформы для этого? Существуют ли технические причины, по которым Windows не может конкурировать?

Ответы [ 8 ]

15 голосов
/ 30 августа 2010

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

Я не уверен насчет Solaris, но в случае Linux эти ребята пишут и используют патчи с низкой задержкой и настройки для всего ядра, от драйверов сетевой карты довверх.Дело не в том, что есть техническая причина, по которой это невозможно сделать в Windows, но есть практическая / юридическая причина - доступ к исходному коду и возможность перекомпилировать его с изменениями.

12 голосов
/ 29 августа 2010

Технически, нет.Однако есть очень простая бизнес-причина: весь финансовый мир работает на Unix.Банки работают на AIX, сам фондовый рынок работает на Unix, и поэтому в финансовом мире проще найти программистов, которые привыкли к среде Unix, а не к Windows.

10 голосов
/ 30 августа 2010

(я проработал в инвестиционном банке 8 лет) На самом деле довольно много того, что банки называют малой задержкой, сделано в Java.И даже не Real Time Java - просто обычная Java с отключенным GC.Основной трюк здесь состоит в том, чтобы убедиться, что вы выполнили весь свой код, достаточный для запуска jit, прежде чем переключать конкретную виртуальную машину на prod (таким образом, у вас есть некоторый цикл запуска, который выполняется в течение нескольких минут - и горячее аварийное переключение).

Причины использования Linux:

Знакомство

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

Настраиваемость - возможность установить swappiness на 0, заставить JVM предварительно распределять большие страницы и другие трюки низкого уровня весьма полезны.

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

4 голосов
/ 29 августа 2010

Причина проста: 10-20 лет назад, когда появились такие системы, «хардкорные» многопроцессорные серверы были ТОЛЬКО на каком-то UNIX.Windows NT была в детском саду в эти дни.Так что причина "историческая".

Современные системы могут быть разработаны под Windows, это просто вопрос вкуса в наши дни.

PS: я в данный момент работаю над одной из таких систем :-)

4 голосов
/ 29 августа 2010

Linux / UNIX гораздо более удобны для одновременных удаленных пользователей, что облегчает создание сценариев для систем, использование стандартных инструментов, таких как grep / sed / awk / perl / ruby ​​/ less, в журналах ... ssh / scp ... все эти вещи только там.

Существуют также технические проблемы, например: для измерения прошедшего времени в Windows вы можете выбрать между набором функций, основанным на отметке часов Windows, и аппаратным QueryPerformanceCounter (). Первым является увеличение каждые 10–16 миллисекунд (примечание: некоторая документация подразумевает большую точность - например, значения из GetSystemTimeAsFileTime () измеряют до 100 нс, но они сообщают об одном и том же фронте 100 нс тактового такта, пока он не заработает снова. Последний - QueryPerformanceCounter () - имеет проблемы с остановкой шоу, когда разные ядра / процессоры могут сообщать о количестве часов с момента запуска, которые отличаются на несколько секунд из-за разогрева в разное время во время загрузки системы. MSDN документирует это как возможную ошибку BIOS, но это часто встречается. Итак, кто хочет разрабатывать торговые системы с низкой задержкой на платформе, которая не может быть правильно оснащена? (Существуют решения, но вы не найдете никаких программных решений, которые бы удобно размещались в boost или ACE).

Многие варианты Linux / UNIX имеют множество легко настраиваемых параметров, позволяющих компенсировать задержку для одного события по сравнению со средней задержкой под нагрузкой, размерами временных интервалов, политиками планирования и т. Д. В операционных системах с открытым исходным кодом есть также гарантия, которая обеспечивается возможность ссылаться на код, когда вы думаете, что что-то должно быть быстрее, чем оно есть, и знание того, что (потенциально огромное) сообщество людей было и делает это критически - с Windows, очевидно, в основном это будут люди, которые " назначен посмотреть на это.

Со стороны FUD / репутации - несколько нематериальных, но важной части причин выбора ОС - я думаю, что большинство программистов в отрасли просто больше доверяют Linux / UNIX для обеспечения надежного планирования и поведения. Кроме того, Linux / UNIX имеет репутацию менее подверженных сбоям, хотя в наши дни Windows достаточно надежна, а Linux имеет гораздо более изменчивую базу кода, чем Solaris или FreeBSD.

2 голосов
/ 08 мая 2012

Я частично согласен с большинством ответов выше. Хотя я понял, что основной причиной использования C ++ является то, что он работает относительно быстро с очень обширной библиотекой STL.

Помимо этого, система linux / unix также используется для повышения производительности. Я знаю много команд с низкой задержкой, которые в значительной степени настраивают ядро ​​Linux. Очевидно, этот уровень свободы не обеспечивается окнами.

Другие причины, такие как устаревшие системы, стоимость лицензии, количество ресурсов, но также являются менее значимыми факторами. Как упоминалось в «rjw», я видел, что команды также используют Java с модифицированной JVM.

2 голосов
/ 29 августа 2010

Есть множество причин, но причина не только историческая. На самом деле, кажется, что в наши дни на * nix работает все больше и больше финансовых приложений на стороне сервера, чем когда-либо прежде (включая такие громкие имена, как Лондонская фондовая биржа, которые перешли с платформы .NET). Для клиентских или настольных приложений было бы глупо предназначаться для чего-либо кроме Windows, поскольку это - установленная платформа. Однако для серверных приложений большинство мест, над которыми я работал, развертываются в * nix.

0 голосов
/ 22 декабря 2012

Я придерживаюсь исторического мнения и доступа к манипуляциям с ядром.

Помимо этих причин, я также считаю, что им нравится то, как они отключают сборку мусора .NET и аналогичный механизм в Java при использовании этих технологий с небольшой задержкой.Они могут избегать Windows из-за высокого уровня API, который взаимодействует с операционной системой низкого уровня, а затем с ядром.

Итак, ядро ​​- это, конечно, ядро, с которым можно взаимодействовать, используя ОС низкого уровня.API высокого уровня предоставляются только для облегчения жизни обычных пользователей.Но в случае низкой задержки это оказывается жирный слой и потери доли секунды вокруг каждой операции.Таким образом, выгодный вариант для получения нескольких долей секунды за вызов.

Помимо этого еще одна вещь, которую следует учитывать, это интеграция.Большинство серверов, центров обработки данных, бирж используют UNIX, а не Windows, поэтому использование клиентов одного семейства упрощает интеграцию и общение.

Тогда у вас есть проблемы с безопасностью (хотя многие могут не согласиться с этим пунктом) взломать UNIX нелегко по сравнению со взломом WINDOWS.Я не согласен с тем, что лицензирование должно быть проблемой для банков, потому что они тратят деньги на каждую единицу оборудования и программного обеспечения и людей, которые их настраивают, поэтому покупка лицензий не будет такой же большой проблемой, если учесть, что они получают от покупки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...