Кажется, что все крупные инвестиционные банки используют C++ в Unix (Linux, Solaris) для своих приложений с малой задержкой/высокочастотным сервером. Почему Windows обычно не используется в качестве платформы для этого? Существуют ли технические причины, по которым Windows не может конкурировать?Торговые системы с низкой задержкой, использующие C++ в Windows?
Технически, нет. Однако есть очень простая деловая причина: остальная часть финансового мира работает на Unix. Банки работают на AIX, фондовый рынок сам работает на Unix, и поэтому проще всего найти программистов в финансовом мире, которые используются в среде Unix, а не в Windows.
+1 для того, чтобы не переходить в Unix FUD. –
Это ненормально НЕ о том, чтобы найти ребят с знаниями о Windows. Уверяю вас, знания, связанные с ОС, составляют 1% от знаний, необходимых для такого развития, и все, кто работает в этой области, могут при необходимости переключиться на ЛЮБЫЕ ОС. – BarsMonster
@BarsMonster: Я мог видеть, что для таких вещей, как сетевые стеки, которые полностью зависят от платформы, потребуется некоторое количество знаний, прежде чем они смогут переключать платформы. Плюс такие вещи, как 'fork', которые распространены в мире POSIX, но недоступны в среде Windows. Я думаю, что это разумный ответ. –
Linux/UNIX гораздо более удобны для одновременных удаленных пользователей, что упрощает создание сценариев вокруг систем, используя стандартные инструменты, такие как grep/sed/awk/perl/ruby / less на журналах ... ssh/scp .. все это просто.
Существуют также технические проблемы, например: для измерения прошедшего времени в Windows вы можете выбирать между набором функций на основе тактового сигнала Windows и аппаратным QueryPerformanceCounter(). Первый шаг - от 10 до 16 миллисекунд (обратите внимание: какая-то документация подразумевает более высокую точность - например, значения из метода GetSystemTimeAsFileTime() равны 100 нс, но они сообщают о том же 100ns краю тактового сигнала, пока он не гаснет снова). Последний - QueryPerformanceCounter() - имеет проблемы остановки при остановке, когда разные ядра/процессор могут сообщать о часах с момента запуска, которые отличаются на несколько секунд из-за прогрева в разное время во время загрузки системы. MSDN документирует это как возможную ошибку BIOS, но это распространено. Итак, кто хочет разрабатывать системы с низкой задержкой на платформе, которые невозможно правильно измерить? (Есть решения, но вы не найдете ни одного программного обеспечения, сидящего удобно в boost или ACE).
Многие варианты Linux/UNIX имеют множество легко настраиваемых параметров для компенсации латентности для одного события против средней задержки при загрузке, размерах временных интервалов, политиках планирования и т. Д. В операционных системах с открытым исходным кодом также есть уверенность, имея возможность ссылаться на код, когда вы думаете, что что-то должно быть быстрее, чем оно есть, и знание о том, что (потенциально огромное) сообщество людей было и делает это критически - с Windows это, очевидно, в основном будут люди, которые 'назначено посмотреть на него.
На стороне FUD/репутация - несколько неосязаемая, но важная часть причин выбора ОС - я думаю, что большинство программистов в отрасли просто доверяют Linux/UNIX больше, чтобы обеспечить надежное планирование и поведение. Кроме того, Linux/UNIX имеет репутацию снижения количества сбоев, хотя в наши дни Windows довольно надежна, а Linux имеет гораздо более изменчивую базу кода, чем Solaris или FreeBSD.
Операционные системы Windows * client * позволяют только одному пользователю использовать RDP. Однако Windows Terminal Server существует навсегда (это было, по сути, оригинальное использование RDP), и он позволяет столько соединений, сколько у вас есть Лицензии клиентского доступа. ОС Windows Server поставляется с возможностью иметь более одного удаленного пользователя по умолчанию. Если бы вы могли указать комментарий о планировании, я бы добавил +1 здесь - эта часть ответа кажется FUD в этот момент для меня (остальная часть ответа хороша). YMMV. –
Планирование UNIX/Linux отсутствует. Это одна из областей, в которой реализации отличаются. И на самом деле у Linux было более одного выбора планировщика (для полноэкранного графического интерфейса Google для фона), поэтому вы даже не можете сказать, что «Linux-планирование надежное». – MSalters
@Billy: спасибо за исправление re RDP - ответ обновляется соответствующим образом. Уточнили, что такое FUD/мнение, которое, как я считаю, имеет отношение к этому вопросу. @MSalters: Это как сказать, что нет никакого спорта, потому что есть футбол и теннис. Планирование UNIX/Linux все равно можно решать коллективно. И вы можете разумно обобщить, точно так же, как можно сказать, что спорт - это здорово .... –
Причина проста, 10-20 лет назад, когда появились такие системы, многопроцессорные серверы «хардкор» были ТОЛЬКО на какой-то UNIX. В наши дни Windows NT в детском саду. Поэтому причина - «историческая».
Современные системы могут быть разработаны на Windows, сейчас это просто вопрос вкуса.
PS: Я currencly работает на одной из таких систем :-)
+1 для * другого * ответа, не входящего в Unix FUD. –
Есть множество причин, но причина не только историческое. На самом деле кажется, что все больше и больше финансовых приложений на стороне сервера работают на днях, чем когда-либо ранее (включая такие крупные имена, как Лондонская фондовая биржа, которые перешли с платформы .NET). Для клиентских или настольных приложений было бы глупо ориентировать на что угодно, кроме Windows, поскольку это установленная платформа. Однако для приложений на стороне сервера большинство мест, в которых я работал, развертываются до * nix.
Windows, конечно же, не была создана настольная платформа в 1990 году, когда такие торговые системы были впервые разработаны. И если вам потребовалась серьезная производительность на вашем рабочем столе, 16-битная Windows не была вариантом. – MSalters
Требования к характеристикам систем с крайне низкой задержкой, используемых для алгоритмической торговли, - это extreme.В этой среде подсчитываются микросекунды.
Я не уверен в том, что Solaris, но в случае с Linux, эти ребята пишут и используют исправления и настройки с низкой задержкой для всего ядра, начиная с драйверов сетевых карт. Дело не в том, что есть технический, почему это невозможно сделать в Windows, но есть практический/юридический - доступ к исходному коду и возможность перекомпилировать его с изменениями.
Это кажется хорошим ответом, но знаете ли вы, что они пишут латентные задержки и перекомпилируют ядро? – Jon
@ Jon: У меня есть только анекдотические свидетельства из различных обсуждений на LKML и подобных местах за эти годы (например, Кристоф Ламет - разработчик ядра, который некоторое время работал над небольшими задержками для таких приложений). – caf
@Jon Я написал патчи ядра в таких областях, как pdflush. Стандартные допущения доступа к ядру не обязательно совпадают с желаемыми шаблонами доступа. –
(Я занимаюсь инвестиционным банковским бизнесом в течение 8 лет) На самом деле, многие банки называют низкую задержку, выполняются на Java. И даже не в реальном времени Java - просто нормальная Java с выключенным GC. Основной трюк здесь заключается в том, чтобы убедиться, что вы полностью использовали весь свой код для запуска jit до того, как вы переключите конкретную виртуальную машину на prod (так что у вас есть цикл запуска, который выполняется в течение нескольких минут - и горячий переход на другой ресурс) ,
Причины использования Linux являются:
Дружественные
Дистанционное управление еще лучше, а также низкое влияние - оно будет иметь минимальное воздействие на другие процессы на компьютере. Помните, что эти системы часто размещаются на бирже, поэтому ссылки на машины (от вас/вашей группы поддержки), вероятно, будут хуже, чем у ваших обычных центров обработки данных.
Tunability - возможность установить swappiness на 0, получить JVM для предопределения больших страниц и другие низкоуровневые трюки.
Я уверен, что вы можете заставить Windows работать приемлемо, но нет никаких больших преимуществ для этого - как говорили другие, любые сотрудники, которых вы браковали, должны были заново открыть все свои латентные трюки, а не просто сбежать контрольный список.
Я интернировал на фирме HFT/market making, и наш код был на Java, мыслительный процесс - это время и ошибки, которые были перевешивают любую потенциальную выгоду от использования C/C++. – cohensh
Я частично согласен с большинством ответов выше. Хотя то, что я понял, является самой большой причиной использования C++, потому что он относительно быстрее с очень обширной библиотекой STL.
Помимо этого, система linux/unix также используется для повышения производительности. Я знаю много команд с низкой задержкой, которые в значительной степени настраивают ядро Linux. Очевидно, что этот уровень свободы не предоставляется окнами.
Другие причины, такие как устаревшие системы, стоимость лицензии, количество ресурсов, а также меньшие факторы вождения. Как упоминалось «rjw», я видел, что команды используют Java также с модифицированной JVM.
Второе мнение о историческом и доступ к манипуляции с ядром.
Помимо этих причин я также считаю, что так же, как они отключают сборку мусора .NET и аналогичный механизм в Java при использовании этих технологий в некоторой низкой задержке. Они могут избежать Windows из-за API на высоком уровне, которые взаимодействуют с низкими уровнями os, а затем с ядром.
Таким образом, ядро, конечно же, является ядром, с которым можно взаимодействовать с использованием низкоуровневых os. API-интерфейсы высокого уровня предоставляются только для облегчения жизни обычных пользователей. Но в случае низкой латентности это оказывается жирным слоем и потерями секунд в каждой операции. Таким образом, выгодный вариант для получения нескольких долей секунды за вызов.
Помимо этого, нужно учитывать интеграцию. Большинство серверов, центров обработки данных, обмены используют UNIX, а не окна, поэтому использование клиентов того же семейства упрощает интеграцию и общение.
Тогда у вас есть проблемы с безопасностью (многие люди могут не согласиться с этим моментом) взлома UNIX непросто по сравнению с взломом WINDOWS. Я не согласен с тем, что лицензирование должно быть проблемой для банков, поскольку они лишают деньги на каждом отдельном аппаратном и программном обеспечении и людей, которые их настраивают, поэтому покупка лицензий не будет такой же важной проблемой при рассмотрении того, что они получают при покупке.
Кто-нибудь приносит зефиры? Я хочу использовать эти огни для использования! –