Впринципе да, но только собственный шум в темноте у сенсоров очень высокий. Плюс сама камера дорогая, и сенсоры тоже, для работы с сенсором понадобиться FPGA, если брать чисто сенсоры от камер. Схема значительно сложнее и дороже в реализации.
Вы уверены? Вы знаете кого-то из этих гениальных людей? Мне лично знакомо несколько людей из средних компаний, но там нет HFT и они даже не собираются заниматься HFT… Прична озвучана мной выше и кто разбирается в алго впринципе в большинстве будут солидарны со мной. Когда говорят про HFT и Роботов это имхо разводняк полнейший, чтобы кинуть потом инвесторов и домохозяйк...))
При правильном написании нет таких проблем и не было впринципе, мне лично удавалось значительно ускорить алгоритмы, только засчет уменьшения хранимых данных и переписать алгорим так, чтобы сборка мусора тригерилась меньше и не было долгих пауз. Мне очень нравится читать блоги jvm и nodejs разработчиков, они там не редко делятся секретами и показывают частые кейсы проблем с производительностью, есть так же среди них выходцы из постсоветского пространства, с ними интересно пообщаться и они принципе даже на письма по электронке отвечают очень охотно. Честно говоря я раньше JAVA и JS считал очень убогими и тормозными, но потом мое мнение резко поменялось, когда мне показали, что некоторые инструкции практически с нулевым оверхедом конвертируются в ASM сравнимый по скорости код, как из под компилятора. Когда начинаешь изучать и лучше уходить в принципы работы JVM, JIT, AOT, GC, начинаешь понимать какое сложное это изобретение, и какие гениальные программисты пишут там код. Ну и в принципе для таких как вы пишут такие книги www.piter.com/product_by_id/227095092. Издательство Питер ph_piter не забудьте мне заплатить за рекламу вашей книги.
Лично не принижаю достоинств Rust и он мне нравится как язык, мне просто не нравится когда принижают Java или nodejs, и не достаточно понимают как они работают. Впринципе в целях highload и чтобы избавиться от GC на их приложениях, не редко просто пишут свой алокатор для JAVA, которые оптимально подходит именно под их задачи, что даже видел лет 20 назад. Благо это все делается легко.
Вы плохо читали про объем? Вы никогда не слышали историю про то, как одна довольно крупная компания экперементировала с ВЧ алгоритмам, и благодаря сбою в алгоритме просела за день примерно на 200 миллионов? в итоге они отказались от ВЧ алгоритмов… Даже если на исторических данных алгоритм показывает, что можно заработать, на реальных данных очень часто там будет минус так как на рынок уже оказываете влияние своим объемом. Впринципе объем для HFT необходимый есть во фьючерсе на индекс S&P 500, но там тоже объем где-то на несколько миллионов, а у крупных игроков на миллиарды могут быть позиции. У них большии позиции и к примеру даже 15% годовых для большого количества миллиардов будет лучше, чем 40% годовых от 50 миллионов… Это просто математически не оправдано. Плюс получится так, что впринципе они эксплуатируют сами себя, и переносят свои деньги из одной в стратегии в другую. Им проще делать адаптацию, чтобы не эксплуатировали их, чем вводить HFT. Но я бы его не рискнул торговать, он слишком волатильный — высокая дисперсия, что не вписывается в мою модель риск менеджмента, мне комфортные с алгостратегиями где низкая дисперсия.
Для тех кто не верит, что в JS возможно парсить быстро файлы и уложиться в 30мс на файлах в несколько мегабайт.
То вот вам бенчмарк github.com/postcss/benchmark CSS парсеров на JS которые строют AST. Сам тоже лично достигал таких скоростей на JS. Расскажите им про GC и медленный JS. Вы в принципе даже не понимаете теорию компиляторов, и что компьютер работает только с бинарными данными, и что работа с текстом одна из самых дорогих операций, а еще минусуете. Сразу видно плохо учились… Вот они наши ясные солнышки и гордость современной компьютерной науки)))
Все же вам отвечу. Начнем с того, что размещают ближе к бирже по причине дисконнектов, чтобы в дни высокой волатильности успевали сработать стоп приказы. Не все протоколы и не все торговые платформы могут хранить стоп ордера на сервере, и они реализованы только на ПО клиента. Да и в принципе сами биржи не представляют такой функциональности, только брокеры и их ПО. Поэтому не мало кто торгует с VDS, или заводит несколько провайдеров для балансировки трафика. Решения за микросекунды не надо принимать. Банально у вас не будет объема. Плюс при работе с бинарными данными количество сборок мусора в сотни, а то и тысячи раз меньше. Где используют текст там всегда есть заметные даже на глаз и отклик лаги. При правильной оптимизации их просто нет. HFT не подходит крупным игрокам, опять же не будет объема, а крупные ордера тупо раздуют волатильность и уже не получится купить по нужной вам цене, что сломает риск менеджмент и уменьшит потенциальную прибыль. Мне приходилось общаться с западными программистами из средних компаний, которые занимаются алго, и приципе HFT вообще никто не занимается, в лучшем случае там скальпинг на довольно маленькие суммы. По скальпингу так же как по HFT прибыль сильно ограничена объемом, для крупных игроков это копейки. Поэтому даже сильно вкладываться в инфраструктуру не имеет смысла, она не окупится. HFT и скальпинг это только для маленького игрока, который практически не влияет на объем и может заработать хорошие деньги(для него это хорошие, а для крупного игрока это копейки) медленность крупных игроков. Как только вы начнете своим объемом заметно влиять на рынок начнется адаптация и эксплуатация вас, весь трейдинг построен на подстройке и эксплуатации, кто быстрее видит изменения и быстрее подстраивается тот зарабатывает, и это невозможно запрограммировать. Вообще есть мнение среди алготрейдеров, что чем проще алгоритм тем он лучше зарабатывает. Изначально были только инвесторы которые покупали в надежде получить прибыль, но так как у них крупные обьемы, то столько им продать не могли быстро, поэтому они набирают месяцами и годами позиици. Потом появились трейдеры, которые начали спекулировать на боле маленьких отрезках времени, и начали съедать часть прибыли инвесторов, потом появились скальперы, которые начали эксплуатировать трейдеров, и в конце HFT. Но HFT вскоре практически вымер как стиль, но про него до сих пор ходят мифы и легенды. Игроки начали тоже адаптироваться и эксплуатировать не эффективность других игроков. Сейчас крупные игроки не дураки, они уже прячут объемы и размывают границы цен, плюс специально толкают такие алгоритмы и мелких игроков скупать или продавать в надежде движения, а потом их просто их выносят по стопу, и крупный игрок получает нужный объем по лучшей цене. Вообще все быстрые алгоритмы и алгоритмы маркет майкеров очень жестко выносит в волатильные дни, они жестко начинают быстрые убыточными, поэтому их стараются отключаться. В нормальном алго всегда заложено отключение алгоритма при определенном количестве плохих сделок по времени, или при достижении максимальной теоритической просадки.
Парсить сотни мегов и даже несколько гигогов логов в секунду вполне реально, но только если у вас нет сложной токенизации и сложной логики лексического анализатора. Даже на JS можно несколько мегабайт распарсить и построить AST за примерно 30мс. Проблема CSV совсем другая, это то, что файлы усыпаны большим количеством чисел, которые надо распарсить, вот это уже очень медленно! Вы мне затираете про rust и тонкие материи, а сами даже не работаете с бинарными данными. Такие смешные… Вы когда нибудь пробовали делать выгрузку и загрузку базы из postgresql в бинарном и текстом формате и замерить во сколько раз отличаются их скорости? Предлагаю вам поставить postgresql и это проверить прямо сейчас и выложить результаты тут. Сами же несете чушь и минусуете впридачу… Ох уж эти крутые программисты на хаскель… Вот так всегда кончились аргументы, и начали минусовать)))
ЛОЛ. Так вы же говорили про крупные приложения под сотню гигабайтами данных… Да еще чето про HFT пытались писать впринципе не понимая специфику. А сейчас съезжаете… Для HFT даже лаг в несколько секунд много, HFT это быстрый алгоритм, который работает на не эффективности рынка, он просто эксплуатирует более медленных торговцев. Изучайте теорию игр и GTO. На больших данных там не на минуты время идет, а на часы и даже дни, мне приходилось конвертировать большое количество бинарных данных в текст и обратно. Вы никогда не думали почему базы данных все данные хранят в бинарном формате? Ничего сложного с бинарными данными работать, даже значительно проще чем с текстом)))
CSV медленно, тут вы жестко спалились. С бинарными данными всегда проще работать, плюс они выравнены, с текстом работать это самое медленное. Банально parseInt, parseDecimal у вас будет брать кучу времени, с бинарными данными все проще, плюс можно упаковывать данные практически бесплатно бинарными сдвигами, чтобы уменьшить место и увеличить скорость доступа. Все быстрые коннекторы поэтому передают данные только в бинарном формате, например протокол PLAZAII. Скажу больше, хранение больших данных в текстовом формате, это вообще гремучая смесь для сборщика мусора, и основная проблема очень большого количества программ почему они так жестко тормозят при работе.
Отличаются. Не может, это обычный счетчик. Пластиковый сцинтиллятор впринципе даже не создан для спектрометрии и фиксации уровня энергии. Поэтому дискриминацию можно только физическими способами сделать, а не схемой или программно.
Сразу видно профессионал. Точно совсем никак без GC? А можно уточнит для каких провайдеров данных вы писали коннекторы? Как организовывали риск менеджмент? Какой был у вас коэффициент шарпа по вашей стратегии и стандартное отклонение, максимальная просадка? Можно увидеть аналитику?) Можно было все на C++ писать. Вы меня не поняли писал не только коннекторы, но и платформу для алго. На C# банально проще визуализировать данные, работать с таблицами, графиками. C# биндинги есть даже в западных коммерческих платформах для алготрейдинга, не говоря про несколько российских. Вот они же лохи, чувак же на хабр сказал, что GC плохо и вообще никак нельзя вкорячить. Можно уточить, что вы там на сотни гигов грузите? Данные по объемам? В принципе при конвертации данных и компактном их хранения, по инструменту за последние несколько лет данные занимают не более пары сотен гигов. Для HFT впринципе столько данных не нужно, для HFT важна моментальная адаптация по времени. HFT это принципе не про стратегию на исторических данных, там другой принцип. Ага, чувак написал про хаскель, и сразу можно в боги программирования записывать…
Как минимум примерная оценка их количества и построение статистики. Может человек пишет научную статью на тему влияния фазы луны на количество мюонов. Это шутка не стоит воспринимать всерьез. У всех свои цели могут быть по изучению их… )))
Ага, дядька в интернете сказал и все ему поверили… Какая APPA? Они разные бывают. Fluke и Brymen во всем мире считают за эталон безопасности, точности, цена-качество. Посмотрев только спецификацию становится понятно, что это приборы совсем разных классов, Testo это уровень дешевых китай тестеров. У вашего TESTO CAT IV 600V, у меня все равно остаются сомнения, что он не пройдет тест даже на 600в, так как чаще всего пишут их для вида, и во многих приборах впринципе даже нет нормальных схем защит. У Fluke CAT IV 600V и Brymen CAT IV 1000V. Во вторых посмотрите по спецификации погрешность вашего Testo она около 1%, когда у Brymen и Fluke значительно лучше! Даже у китайцев не так редко лучше! В третьих у вашего Testo всего 6000 отсчетов, когда у Fluke 87 — 20 000, а у Brymen 869s — 500 000. У вас он быстро поплывет в показаниях уже на паре КГц. Вместо вашего Testo можно купить значительно лучше китай мультиметр и значительно дешевле. Не согласны, хорошо, открывайте свой Testo и покажите его потроха и как там организована схема защиты, переключатели и т.д. Еще минусуете, когда от вас просят пруфы. Неучи, только минусовать умеете, вместо пруфов и аргументов.
HFT биржи? HFT это лишь стиль торговли, а не биржа, высокочастотная торговля, и да мне приходилось писать коннекторы для трейдинга. Впринципе можно писать на чем угодно, сборка мусора не помеха, у меня это было C++и С#. Если вы про Stock Sharp то он жестко кривой, изначально когда я писал своего работа использовал его как основу, но в итоге избавился и написал свое, которое не тригерит так сборку мусора и не копирует объекты раздувая память. Честно говоря мне не понятно за что там берут деньги, проект совсем кривой и тормозной, и по мне коммерческая ценность его 0. А еще у меня не самая плохая математическая база h0tc0d3.github.io/evtools
Да ладно? Вы в принце не понимаете даже зачем в Java GC. У многих есть ошибочное мнение, что GC это костыли. Ошибочное мнение. Вы неужели думаете, что C++ и С программисты настолько тупы, и так же создатели JVM, что не смогли до Rust придумать удаление сразу объектов как в C++ или C? Или сделать shared pointer? Такие вещи сделать совсем просто, это примитив, даже мне приходилось такое писать и оверхед там не более 1%. Rust это только оптимизировал на уровне компилятора. GC совсем не про это, GC решает проблему при работу с очень крупными данными, десятками гигабайт и больше, где нельзя просто взять и удалить объект, где создается и удаляется много объектов, что повлечет за собой фрагментацию памяти и скажется на производительности! На маленьком приложении вы в принципе это даже не заметите, а на крупном это серьезная проблема. Плюс алгоритмов сборки мусора существует несколько, и они решают именно определенные проблемы, что подходит одному не подойдет другому. Плюс в JAVA есть интеграция с алокатором ОС, там есть к примеру
-XX:+UseLargePages
-XX:+UseTransparentHugePages
Для работы совсем с большими страницами памяти и тоже решает проблему сборки мусора на больших данных.
Java это в первую очередь не десктоп, и не веб и микросервисы, это в первую очередь обработка больших данных для целей бизнеса! Все проблемы с GC от не понимания принципов его работы, и кривых алгоритмов и программистов, от которых не защищены все языки программирования…
На данный момент судьба rust в в ядре Linux под вопросом, и вполне может быть, что поддержку rust для создания модулей ядра Linux даже не примут.
Лично не принижаю достоинств Rust и он мне нравится как язык, мне просто не нравится когда принижают Java или nodejs, и не достаточно понимают как они работают. Впринципе в целях highload и чтобы избавиться от GC на их приложениях, не редко просто пишут свой алокатор для JAVA, которые оптимально подходит именно под их задачи, что даже видел лет 20 назад. Благо это все делается легко.
То вот вам бенчмарк github.com/postcss/benchmark CSS парсеров на JS которые строют AST. Сам тоже лично достигал таких скоростей на JS. Расскажите им про GC и медленный JS. Вы в принципе даже не понимаете теорию компиляторов, и что компьютер работает только с бинарными данными, и что работа с текстом одна из самых дорогих операций, а еще минусуете. Сразу видно плохо учились… Вот они наши ясные солнышки и гордость современной компьютерной науки)))
Для работы совсем с большими страницами памяти и тоже решает проблему сборки мусора на больших данных.
Java это в первую очередь не десктоп, и не веб и микросервисы, это в первую очередь обработка больших данных для целей бизнеса! Все проблемы с GC от не понимания принципов его работы, и кривых алгоритмов и программистов, от которых не защищены все языки программирования…
На данный момент судьба rust в в ядре Linux под вопросом, и вполне может быть, что поддержку rust для создания модулей ядра Linux даже не примут.
Есть ли в Rust MapReduce?