Мне кажется я понял наконец посыл статьи, они пытаются убедить финансистов что HFT стал безвреден и даже полезен. Вроде как некая часть очень быстрых (плохих) HFT стрижет другую часть более медленных (хороших) HFT, а те героически защищают рынок, предоставляя в нужный момент ликвидность и терпя убытки, а снежно-белым-пушистым трйдерам торгующим вручную ничего не грозит.
Не думаю что денежное сообщество с ними согласится, однако зерно истины в этом безусловно есть. Порог вхождения в HFT сейчас черезвычайно высок за счет того что приходится ставить самое мощное оборудование, арендовать дата центр, ну и конечно вкладываться в софт. Рубка между ними идет жесточайшая, доходность кажется упала и процент выживаемости тоже.
Но тем не менее, поскольку кто-то выживает, значит он получает доход, а поскольку сами спекулянты денег не рынок не приносят, они забирают у кого-то еще, закон сохранения массы никто не отменял
Забавно, Bloomberg всегда гордился своей системой обработки и быстрой доставки новостей, это один из главных сервисов которые они продают. Получается что их система вносит примерно двухсекудную задержку…
Нет, Boost Foundation с вами не свяжется, и по моему это к лучшему. Смотрите сами: с многопоточностью вообще никак не совместимо, деструкторы не вызываются и еще много чего в этом роде.
На самом деле то что у Вас получилось — это не очень ловкая попытка имплементировать std::shared_ptr не используя шаблонов, модели использования будут аналогичны.
Мне кажется там логическая ошибка (на Stackoverflow вместе с Александреску). Дело в том что GC тоже не может знать когда обьект можно безопасно удалять если используются обычные указатели. В частности в той статье у Александреску его код очевидно с грохотом упадет независимо от того освобождается память через delete() или GC. Там требуются более кардинальные подходы, например отменить указатели вообще или заменить их все на shared_ptr, но тогда это уже не C++ а совершенно другой язык.
В идеальной системе будет также сохраняться симметрия, т.е. биток будет всегда двигаться по осевой
Кстати, это же верно как минимум еще для трех шаров. К сожалению идеальная партия не кончится никогда.
Определением крупного ордера как раз и является то, что он хочет купить больше чем предложение на данный момент. Таким образом он разом снимает всю доступную ликвидность и ждет пока появятся новые предлжения. Естественно, покупатель ожидает встречного предложения по разумной цене, а вместо этого получает аукцион наоборот.
«Особо шустрые трейдеры» по вашей классификации и есть HFT. Проблема в том что их стало слишком много.
Крупных сделок не бывает (шутка). Число ордеров значительно превосходящих средний обьем невелико, а вероятность того что два таких ордера случайно встретятся в один и тот же момент исчезающе мала. Следовательно, один из крупных ордеров появится на рынке раньше и, прежде чем потенциальный контрагент успеет отреагировать, будет растащен по кускам. Вопрос о том стабилизирует ли это рынок является скорее холиварным, еще недавно все уважаемые финансисты уверяли что да, сейчас они скорее всего уйдут от ответа. Сами HFT вовсе не заинтересованы в стабилизации, мечта каждого спекулянта — качнуть рынок в нужную сторону или предугадать движение, крупные ордера для них — желанная добыча.
Насчет «долгосрочной» биржи вы угадали, в 2013 г. как минимум две торговые площадки обьявили о разработке «fair play» системы, где скорость торгов будет ограничена. Время покажет что из этого выйдет.
Небольшое разьяснение в тезисах, в ответ на сразу несколько комментариев.
— Биржа создана главным образом для того чтобы обеспечивать ликвидность, то есть любой желающий продать или купить мог бы немедленно найти контрагента.
— Традиционно основными игроками на бирже являлись крупные и мелкие инвесторы, которые покупали на относительно большую сумму и держали этот пакет достаточно долго, например месяцы. Акции покупались в расчете на дивиденды, выигрыш от того что продал дороже чем покупал считался приятным но случайным бонусом.
— Возникший позднее класс краткосрочных (однодневных) трейдеров торговал в расчете на случайные колебания курса, поскольку на случайном процессе выигрывать постоянно невозможно, закреплялись на рынке только те кто так или иначе имел какое либо преимущество или информацию.
— Одним из основных легальных конкурентных преимуществ быстро стала скорость посылки ордера, ударить случайно возникшую хорошую цену быстрее конкурентов. Так возник(ла? ло? ли?) HFT.
— Краткосрочные трейдеры не убирают и не добавляют ликвидность в среднем, как правило прибыль ими фиксируется на конец дня, к формированию «справедливой/правильной цены» они тоже не имеют никакого отношения, по сути соответствующий корректный русский термин — «спекулянты».
— Для биржи HFT участники в краткосрочной перспективе выгодны. Поскольку как правило биржа берет плату за убирание ликвидности и за исполнение сделки, краткосрочные трейдеры обеспечивают постоянный доход.
— Конкретный пример негативного влияния спекуляций — некий инвестор размещает крупный market order на покупку (это ордер без указанной цены, исполняется по текущей цене рынка). Как только ордер становится виден, HFT трейдеры начинают откусывать от него маленькими кусочками, одновременно рыночная цена начинает ползти вверх. В результате инвестор покупает в сумме значительно дороже чем была цена рынка на момент выхода ордера. Такой механизм существовал естественно всегда, с самого возникновения бирж, однако именно с распространением HFT потери инвесторов вышли за пределы разумного. За последние 2-3 года инвесторы просто покинули многие мелкие площадки из-за засилья спекулянтов.
— HFT является просто техническим термином для описания самых быстрых из платформ, по существу все краткосрочные трейдеры делают то же самое, только не так быстро. В настоящий момент существует достаточно много вполне успешных компаний существенно более медленных (algorithmic trading) и даже с живыми людьми за терминалами. На рынок скорее негативно влияет общее число таких спекулянтов чем частота с которой они могут торговать.
— Мне кажется что все недавние попытки регулировать HFT в разных странах были крайне неэффективны, зато они легли тяжелым грузом на биржи, которые вынужденны лихорадочно внедрять новые изменения. Хотя, с точки зрения программиста, это как раз совсем и не плохо…
сложно в основном по двум причинам:
— финансисты и трейдеры не очень дружат с математикой и логикой, каждый вид инструмента имеет собственнуя терминологию и происходит по собственным правилам, в основном по историческим причинам. Очень немногие знают все виды торгов просто потому, что для каждого требуется свой язык, хотя логика в основе заложена одна и та же.
— за последние годы правительства многих стран предпринимали лихорадочные усилия по регуляции торгов, что запутало ситуацию еще больше. Попытки быстро добавить требования регуляторов к существующему коду легли тяжким грузом на ИТ отделы и вывело бизнес-логику из стабильного состояния. Трейдеры кстати, особенно китайские, довольно легко находят лазейки, сводя на нет многомесячные усилия.
— Если время обработки сообщения заведомо меньше интервала между событиями, то многопоточность не нужна
например несколько логически независимых потоков пишут в один выходной канал
— Если время обработки сообщения в среднем значительно меньше интервала между событиями, то нужна очередь некого фиксированного размера
если «в среднем», то рано или поздно возникнет ситуация когда буфер переполнился и входной поток будет вынужден ждать. А если он не может ждать?
— Если время обработки сообщения в среднем больше интервала между событиями, то все, приплыли.
естественно, однако в спецификацию очереди время обработки сообщения вообще не входит, по определению. Это задача пользовательского кода, обеспечить обработку, в частности за счет распараллеливания, для чего очередь и сделана многопоточной. В задачу библиотеки, какой эта структура является, входит условие внести как можно меньшую задержку при передаче, что мы и оцениваем.
не нужно использовать многопоточность, от которой будут только накладные расходы
— это немножко уж слишком чересчур кардинальный взгляд.
Гарантированно получить 1 мкс конечно нельзя, можно гарантировать процент транзакций который произойдет быстрее 1 мкс. В этом и состоит количественный подход.
Проблема в том что последний из потоков в цепочке обязательно завязан на внешнего потребителя, например пишет в сокет, и вот тут от нас уже ничего не зависит. Речь шла о том чтобы полностью развязать входной и выходной потоки, так чтобы при любых задержках в передаче выходных данных, входной поток об этом не знал и не беспокоился.
Приоритет конечно поднять можно, но при принудительных блокировках потока, на write() например, это никак не поможет. К тому же приоритет приоритету рознь, если буду писать еще, я на этом обязательно остановлюсь.
Речь как раз шла не о быстродействии и загрузке системы, а о мимимизации latency, задержки обработки каждого отдельного пакета. Простое быстродействие прекрасно обеспечивается собиранием сообщений в группы, вот там как раз неблокирующие алгоритмы не нужны. Попробуйте для контраста написать систему, которая получает всего лишь одно сообщение в час, но отреагировать должна за время <= 1 мкс, мало не покажется.
Я как раз считаю что 50 мкс задержки мало, для абсолютно корректного исключения неких предполагаемых адаптивных алгоритмов ядра я бы использовал 100 миллисекунд минимум. У меня к сожалению терпения не хватает ждать завершения каждого теста несколько часов, на это только профессиональные исследователи на зарплате спосбны.
Ну так я же специально выбрал boost::lockfree::queue для тестирования, она идет под все системы и платформы. Мне не на чем проверить, но я подозреваю что под Windows результаты будут очень близкие. Вот на чем бы я с удовольствием их погонял, это SPARC, там совершенно другая организация ядер и потоков. Наш последний SPARC сервер утилизовали к сожалению в прошлом году, проверить не на чем.
Вот это я постараюсь использовать. Только вот, они там измеряют общее время исполнения, слишком грубо и дает ответ не на тот вопрос который задавали. Мой то пунктик как раз в замере каждого сообщения и применении статистики.
Да, но это к сожалению общие соображения, да и пример выбран очень грубый. Вот я собственно и пытаюсь подвести количественную базу под такие обсуждения.
Спасибо, не знал. По современным скедьюлерам вообще немного информации, я кажется читал что-то похожее, но с пометкой что это сделало бы сам скедьюлер слишком тяжелым и медленным.
В любом случае постараюсь учесть и придумать какой нибудь адекватный тест. Вообще-то мне давно хотелось хотелось сделать планомерную серию тестов при разных scheduling policies, но тогда публикации придется ждать минимум месяц.
Не думаю что денежное сообщество с ними согласится, однако зерно истины в этом безусловно есть. Порог вхождения в HFT сейчас черезвычайно высок за счет того что приходится ставить самое мощное оборудование, арендовать дата центр, ну и конечно вкладываться в софт. Рубка между ними идет жесточайшая, доходность кажется упала и процент выживаемости тоже.
Но тем не менее, поскольку кто-то выживает, значит он получает доход, а поскольку сами спекулянты денег не рынок не приносят, они забирают у кого-то еще,
закон сохранения массы никто не отменялНа самом деле то что у Вас получилось — это не очень ловкая попытка имплементировать std::shared_ptr не используя шаблонов, модели использования будут аналогичны.
Кстати, это же верно как минимум еще для трех шаров. К сожалению идеальная партия не кончится никогда.
«Особо шустрые трейдеры» по вашей классификации и есть HFT. Проблема в том что их стало слишком много.
Насчет «долгосрочной» биржи вы угадали, в 2013 г. как минимум две торговые площадки обьявили о разработке «fair play» системы, где скорость торгов будет ограничена. Время покажет что из этого выйдет.
— Биржа создана главным образом для того чтобы обеспечивать ликвидность, то есть любой желающий продать или купить мог бы немедленно найти контрагента.
— Традиционно основными игроками на бирже являлись крупные и мелкие инвесторы, которые покупали на относительно большую сумму и держали этот пакет достаточно долго, например месяцы. Акции покупались в расчете на дивиденды, выигрыш от того что продал дороже чем покупал считался приятным но случайным бонусом.
— Возникший позднее класс краткосрочных (однодневных) трейдеров торговал в расчете на случайные колебания курса, поскольку на случайном процессе выигрывать постоянно невозможно, закреплялись на рынке только те кто так или иначе имел какое либо преимущество или информацию.
— Одним из основных легальных конкурентных преимуществ быстро стала скорость посылки ордера, ударить случайно возникшую хорошую цену быстрее конкурентов. Так возник
(ла? ло? ли?)HFT.— Краткосрочные трейдеры не убирают и не добавляют ликвидность в среднем, как правило прибыль ими фиксируется на конец дня, к формированию «справедливой/правильной цены» они тоже не имеют никакого отношения, по сути соответствующий корректный русский термин — «спекулянты».
— Для биржи HFT участники в краткосрочной перспективе выгодны. Поскольку как правило биржа берет плату за убирание ликвидности и за исполнение сделки, краткосрочные трейдеры обеспечивают постоянный доход.
— Конкретный пример негативного влияния спекуляций — некий инвестор размещает крупный market order на покупку (это ордер без указанной цены, исполняется по текущей цене рынка). Как только ордер становится виден, HFT трейдеры начинают откусывать от него маленькими кусочками, одновременно рыночная цена начинает ползти вверх. В результате инвестор покупает в сумме значительно дороже чем была цена рынка на момент выхода ордера. Такой механизм существовал естественно всегда, с самого возникновения бирж, однако именно с распространением HFT потери инвесторов вышли за пределы разумного. За последние 2-3 года инвесторы просто покинули многие мелкие площадки из-за засилья спекулянтов.
— HFT является просто техническим термином для описания самых быстрых из платформ, по существу все краткосрочные трейдеры делают то же самое, только не так быстро. В настоящий момент существует достаточно много вполне успешных компаний существенно более медленных (algorithmic trading) и даже с живыми людьми за терминалами. На рынок скорее негативно влияет общее число таких спекулянтов чем частота с которой они могут торговать.
— Мне кажется что все недавние попытки регулировать HFT в разных странах были крайне неэффективны, зато они легли тяжелым грузом на биржи, которые вынужденны лихорадочно внедрять новые изменения. Хотя, с точки зрения программиста, это как раз совсем и не плохо…
сложно в основном по двум причинам:
— финансисты и трейдеры не очень дружат с математикой и логикой, каждый вид инструмента имеет собственнуя терминологию и происходит по собственным правилам, в основном по историческим причинам. Очень немногие знают все виды торгов просто потому, что для каждого требуется свой язык, хотя логика в основе заложена одна и та же.
— за последние годы правительства многих стран предпринимали лихорадочные усилия по регуляции торгов, что запутало ситуацию еще больше. Попытки быстро добавить требования регуляторов к существующему коду легли тяжким грузом на ИТ отделы и вывело бизнес-логику из стабильного состояния. Трейдеры кстати, особенно китайские, довольно легко находят лазейки, сводя на нет многомесячные усилия.
например несколько логически независимых потоков пишут в один выходной канал
если «в среднем», то рано или поздно возникнет ситуация когда буфер переполнился и входной поток будет вынужден ждать. А если он не может ждать?
естественно, однако в спецификацию очереди время обработки сообщения вообще не входит, по определению. Это задача пользовательского кода, обеспечить обработку, в частности за счет распараллеливания, для чего очередь и сделана многопоточной. В задачу библиотеки, какой эта структура является, входит условие внести как можно меньшую задержку при передаче, что мы и оцениваем.
Гарантированно получить 1 мкс конечно нельзя, можно гарантировать процент транзакций который произойдет быстрее 1 мкс. В этом и состоит количественный подход.
Приоритет конечно поднять можно, но при принудительных блокировках потока, на write() например, это никак не поможет. К тому же приоритет приоритету рознь, если буду писать еще, я на этом обязательно остановлюсь.
Я как раз считаю что 50 мкс задержки мало, для абсолютно корректного исключения неких предполагаемых адаптивных алгоритмов ядра я бы использовал 100 миллисекунд минимум. У меня к сожалению терпения не хватает ждать завершения каждого теста несколько часов, на это только профессиональные исследователи на зарплате спосбны.
В любом случае постараюсь учесть и придумать какой нибудь адекватный тест. Вообще-то мне давно хотелось хотелось сделать планомерную серию тестов при разных scheduling policies, но тогда публикации придется ждать минимум месяц.