Торговые системы с низкой задержкой, использующие C ++ в Windows?
== сравнивает ссылки на объекты.
.equals() сравнивает значения String.
Иногда == дает иллюзии сравнения значений String, как в следующих случаях:
String a="Test";
String b="Test";
if(a==b) ===> true
Это связано с тем, что при создании любого строкового литерала JVM сначала ищет этот литерал в пуле строк, и если он найдет совпадение, эта же ссылка будет передана новой String. Из-за этого получаем:
(a == b) ===> true
String Pool
b -----------------> "test" <-----------------a
Однако == не выполняется в следующем случае:
String a="test";
String b=new String("test");
if (a==b) ===> false
В этом случае для new String("test") оператор new String будет создан в куче, и эта ссылка будет указана на b, поэтому b будет дана ссылка на кучу, а не на String pool.
Теперь a указывает на String в пуле String, а b указывает на String в куче. Из-за этого мы получаем:
, если (a == b) ===> false.
String Pool
"test" <-------------------- a
Heap
"test" <-------------------- b
Пока .equals() всегда сравнивает значение String, поэтому дает true в обоих случаях:
String a="Test";
String b="Test";
if(a.equals(b)) ===> true
String a="test";
String b=new String("test");
if(a.equals(b)) ===> true
Таким образом, использование .equals() всегда лучше.
5 ответов
Причина проста, 10-20 лет назад, когда появились такие системы, "хардкорные" многопроцессорные серверы были ТОЛЬКО на какой-то UNIX. В эти дни Windows NT была в детском саду. Так что причина "историческая".
Современные системы могут разрабатываться под Windows, в наши дни это дело вкуса.
PS: Сейчас я работаю над одной из таких систем :-)
Требования к производительности систем с чрезвычайно малой задержкой, используемых для алгоритмической торговли, являются экстремальными. В этой среде на счету микросекунды.
Я не уверен насчет Solaris, но в случае с Linux эти ребята пишут и используют патчи с малой задержкой и настройки для всего ядра, начиная с драйверов сетевых карт. Это не техническая причина, по которой это нельзя было сделать в Windows, но есть практическая/юридическая причина — доступ к исходному коду и возможность перекомпилировать его с изменениями.
(8 лет работаю в инвестиционно-банковской сфере) На самом деле довольно многое из того, что банки называют малой задержкой, делается на Java. И даже не Java в реальном времени — просто обычная Java с выключенным сборщиком мусора. Главный трюк здесь заключается в том, чтобы убедиться, что вы выполнили весь свой код достаточно, чтобы jit запустился, прежде чем вы переключите конкретную виртуальную машину в prod (так что у вас есть некоторый цикл запуска, который выполняется в течение нескольких минут — и горячая отработка отказа) .
Причины использования Linux таковы:
Знакомство
Удаленное администрирование все же лучше, а также имеет меньшее влияние — оно окажет минимальное влияние на другие процессы на машине. Помните, что эти системы часто расположены на бирже, поэтому ссылки на машины (от вас/вашей службы поддержки), вероятно, будут хуже, чем на ваши обычные центры обработки данных.
Настраиваемость — возможность установить swappiness на 0, заставить JVM предварительно выделять большие страницы и другие низкоуровневые трюки весьма полезны.
Я уверен, что вы могли бы заставить Windows работать приемлемо, но в этом нет большого преимущества — как говорят другие, любые сотрудники, которых вы переманили, должны будут заново открыть для себя все свои трюки с задержкой, а не просто выполнять контрольный список. .
Причин множество, но причина не только историческая. На самом деле кажется, что в наши дни все больше и больше серверных финансовых приложений работают на *nix, чем когда-либо прежде (включая такие известные компании, как Лондонская фондовая биржа, которые перешли с платформы .NET). Для клиентских или настольных приложений было бы глупо ориентироваться на что-либо, кроме Windows, поскольку это устоявшаяся платформа. Однако для серверных приложений большинство мест, над которыми я работал, развертываются на * nix.
Linux/UNIX гораздо удобнее для одновременного использования удаленными пользователями, упрощая создание сценариев для систем, использование стандартных инструментов, таких как grep/sed/awk/perl/ruby/less для журналов.. .ssh/scp... все это просто есть.
Существуют также технические проблемы, например: для измерения прошедшего времени в Windows вы можете выбирать между набором функций, основанных на тиках часов Windows, и аппаратным QueryPerformanceCounter(). Первый увеличивается каждые 10–16 миллисекунд (примечание: в некоторых документах подразумевается более высокая точность — например, значения из GetSystemTimeAsFileTime() измеряются до 100 нс, но они сообщают о том же 100-нс крае такта часов, пока он не тикает снова). Последний — QueryPerformanceCounter() — имеет проблемы с остановкой показа, когда разные ядра/процессоры могут сообщать о часах с момента запуска, которые отличаются на несколько секунд из-за прогрева в разное время во время загрузки системы. MSDN документирует это как возможную ошибку BIOS, но это обычное дело. Итак, кто хочет разрабатывать торговые системы с малой задержкой на платформе, которая не может быть должным образом оснащена? (Есть решения, но вы не найдете программных, которые удобно сидят в бусте или ACE).
Многие варианты Linux/UNIX имеют множество легко настраиваемых параметров для компромисса между задержкой для одного события и средней задержкой под нагрузкой, размерами временных интервалов, политиками планирования и т. д.В операционных системах с открытым исходным кодом также есть уверенность, связанная с возможностью ссылаться на код, когда вы считаете, что что-то должно быть быстрее, чем есть, и знание того, что (потенциально огромное) сообщество людей было и делает это критически. - с Windows, очевидно, в основном это будут люди, которым поручено смотреть на нее.
Что касается FUD/репутации — несколько неосязаемой, но важной части причин для выбора ОС — я думаю, что большинство программистов в отрасли просто больше доверяют Linux/UNIX, чтобы обеспечить надежное планирование и поведение. Кроме того, Linux/UNIX имеет репутацию менее подверженных сбоям, хотя Windows в наши дни довольно надежна, а Linux имеет гораздо более изменчивую кодовую базу, чем Solaris или FreeBSD.