Для тех кто не верит, что в 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 даже не примут.
1. Вы высосали проблему из пальца. Таких проблем в принципе нет в нормальных проектах, такое пресекают на корню, закомитили косячный код, первый раз предупреждение, дальше лишение премии. Дисциплину в нормальных проектах так прививают, чтобы не делали кривые коммиты, и тестировали код перед отправкой. Вы видимо даже с гитом дело не имеете, так как в нормальном открытом проекте такие вещи не пройдут, сначала вам сделают замечание и попросят оформить код как надо, а дальше просто отклонят пулреквест, если вы не исправите код!
2. У вас код кривой и это сразу глазами видно, что не соблюдены отступы. Плюс редактор на него ругается! Видимо у вас майтенеру глаза выкололи и вы работаете по старинке в блокноте?
3. Видимо по вашему мнению миллионы пользователей python, стоит заметить, который входит в топ 5 языков по пулярности, настолько тупы, что у них все на отступах и они программируют на нем? По некоторым рейтингам python занимает 1 и 2е место. Мне в python лично не нравится только отсутствие строгой типизации, отчего там с производительность не все хорошо. В остальном он практически идеален.
lany лично по моему опыту язык программирования не так сильно влияет на производительность, значительно больше влияет на производительность опыт и знания программистов. Можно даже на nodejs найти очень тяжелые, большие и быстрые проекты. И вы правильно написали про миграцию, это самое дорогое. Во вторых те же же Java и nodejs можно спрофилировать на рабочем бэкенде с помощью утилиты perf, а дальше критический код переписать на C++ или C.
Лично флюку больше доверяю хоть там отсчетов меньше. У моего brymen 869s вообще 500000 отсчетов. Что fluke, что brymen работают отлично, у обоих отлично с высоковольтной безопасностью и точностью, не плывут. Мне не очень понятна ценовая политика на метрахит, что есть в нем такого чего нет во fluke и brymen. За цену метрахта можно купить совсем крутой fluke.
Upd. Посмотрел обзор на этот метрахит, там совсем все печально жестко плывет на последних разрядах и не может стабилизироваться в показаниях, ловит не понятные наводки по воздуху, его надо было назвать мегарахит… Категории только до 600в, ну совсем ни о чем. 600в даже у моего китай unit-t ut61e plus есть, и не плывет он на последних разрядах. А brymen 869 как вкопанный показывает…
То вот вам бенчмарк github.com/postcss/benchmark CSS парсеров на JS которые строют AST. Сам тоже лично достигал таких скоростей на JS. Расскажите им про GC и медленный JS. Вы в принципе даже не понимаете теорию компиляторов, и что компьютер работает только с бинарными данными, и что работа с текстом одна из самых дорогих операций, а еще минусуете. Сразу видно плохо учились… Вот они наши ясные солнышки и гордость современной компьютерной науки)))
Для работы совсем с большими страницами памяти и тоже решает проблему сборки мусора на больших данных.
Java это в первую очередь не десктоп, и не веб и микросервисы, это в первую очередь обработка больших данных для целей бизнеса! Все проблемы с GC от не понимания принципов его работы, и кривых алгоритмов и программистов, от которых не защищены все языки программирования…
На данный момент судьба rust в в ядре Linux под вопросом, и вполне может быть, что поддержку rust для создания модулей ядра Linux даже не примут.
Есть ли в Rust MapReduce?
2. У вас код кривой и это сразу глазами видно, что не соблюдены отступы. Плюс редактор на него ругается! Видимо у вас майтенеру глаза выкололи и вы работаете по старинке в блокноте?
3. Видимо по вашему мнению миллионы пользователей python, стоит заметить, который входит в топ 5 языков по пулярности, настолько тупы, что у них все на отступах и они программируют на нем? По некоторым рейтингам python занимает 1 и 2е место. Мне в python лично не нравится только отсутствие строгой типизации, отчего там с производительность не все хорошо. В остальном он практически идеален.
Upd. Посмотрел обзор на этот метрахит, там совсем все печально жестко плывет на последних разрядах и не может стабилизироваться в показаниях, ловит не понятные наводки по воздуху, его надо было назвать мегарахит… Категории только до 600в, ну совсем ни о чем. 600в даже у моего китай unit-t ut61e plus есть, и не плывет он на последних разрядах. А brymen 869 как вкопанный показывает…