У меня кейс — есть большой объем данных в оперативной памяти и я хочу запустить новый .NET код на этих данных, так вот, Ignite ругнулся, что класс должен присутствовать в сборке. Пробовал около месяца назад.
То есть получается, что нельзя один раз поднять данные в память, потом компилировать новый код и запускать на данных в гриде. Необходимо после каждой компиляции перезапускать грид.
Планируется ли какое-то решение? Насколько я понимаю в Java такая возможность в GridGain есть.
Счет давно уже на микросекунды идет, ну раньше было кто быстрее на 10 или на 20 микросекунд успеет, а теперь на -10 мкс или на -20 мкс, какая разница то по-сути :-)
Я как практик HFT, смотрю на 400 мс, и думаю, какая же это целая куча времени! Да это не то что можно отчет проанализировать, это можно все рынки мира обойти, всех опросить, вернуться, и заявку поставить. Короче, это целая куча времени во вселенной HFT. И это кстати здорово, что конкуренция требует нетривиальной работы мозга…
С багами шлюза на ММВБ не сталкивался, но были несколько раз проблемы с брокерами, которые делают свой пре-трейд перед шлюзом, так там да, логи от шлюза отправлял, шлюз сам их умеет вести, причем имеет на выбор несколько уровней детализации.
Но и саппорт на бирже конечно хорошо отвечает, когда что-нибудь требуется.
Маркетинговый ход для JetBrains на основании того что я знаю: выпускаете новую версию решарпера и доттрейса, полностью исключаете возможность, так сказать, обладать продуктом дольше чем срок триала, ну то есть вообще чтобы без вариантов было. Устраивайте подобный аттракцион еще раз. Все :)
Можно найти логику в ваших слов, но разве сетевая карта на PCI сможет в итоге записать в память процесса быстрее чем шина HyperTransport из статьи? Мне рассказывали парни которые делали подобные вещи, что у них ботлнек в шине PCI-E. Вот авторы как раз нашли решение в виде HT.
Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка.
А на микроконтроллере не сделали, они же написали, потому что протокол постоянно меняется, и как я понял на FPGA легче добиться гибкости, но это все допущения, так как сам такого не делал.
В статье они еще пишут что HFT используется для поиска ликвидности, то есть ищут айсберг-заявки, дарк-пулы, скрытые ордеры, но непонятно зачем это нужно.
То есть они шлют кучу мелких заявкок, «пингуют» стакан и т.д.
Если например трейдер обнаруживает большую скрытую заявку на покупку, он может встать перед этой заявкой по чуть более высокой цене, и если цена пойдет вверх — то он сможет заработать. Если же цена пойдет вниз, то он будет застрахован, потому что успеет быстро продать актив в стакане этому дарк-пулу практически без потерь, таким образом полностью контролирует риски.
Если сомневаетесь, вы можете написать ученым из University of Heidelberg, которые проводили данные исследования. Они смогут предоставить вам все необходимые доказательства тех оценок, которые были ими получены.
Простите, я не смогу ответить на ваши вопросы потому что это перевод статьи, которая показалась мне очень интересной.
Я знаю что в России подобная разработка тоже ведется, я видел как этим занимаются мои коллеги, тоже на FPGA, но с хостом общаются через PCI-Express, когда я с ними последний раз разговаривал, этот интерфейс был у них вроде как узким местом. Больше к сожалению сказать ничего не могу.
Именно таких сказать не возьмусь, но я например вначале гоняю на исторических данных, потом на тестовом контуре, который есть у ММВБ'шников, затем под чутким надзором, с дебагером, на маленьких денежных суммах, и только потом уже стратегия полноценно уходит в бой. Возможно они используют какие-то похожие методы.
А зачем интересно юзер с ямайского IP меняет после 04/Sep/2012:03:28:37 +0400 браузер(User-agent во всяком случае) и перелогинивается?
Кстати, выложили бы логи nginx для русского IP, элементарный fingerprint сделать, понимаю, что это ничего бы не доказывало, но все же…
Я вот тоже хотел, но так и не смог разобраться с git и github'ом. Столкнулся с какими-то проблемами с авторизацией, хотя и делал все так как написано на сайте github'а, и в итоге вернулся к SVN.
Я столкнулся в ситуацией, когда мне надо было обработать около 1000 объектов из базы, и создать новые объекты, в каждом из котором где то 20 полей, то есть получается 20000 полей надо было обработать. И решил не заморачиваться с проверками на null, а просто обернуть в try/catch и возвращать пустую строку в случае null. Имеется ввиду не просто object.Property, а например object.anotherObject.anotherProperty, где каждый элемент может быть null. Получилась огромная просадкда производительности. С тех пор я убедился что эксепшены надо юзать осторожно.
Эксепшены тормозят выполнение раз в 10. Я тоже не верил пока не нарвался.
К примеру откройте Visual Studio и выполните простой цикл, чтобы внутри него кидалось и обрабатывлось исключение.
Затем выполните этот же цикл без блока try/catch.
Лично у меня разница получилась в 10 раз, что там где есть исключение работает медленнее.
Я повторюсь, что в это не верится, пока на практике не столкнешься, насколько они работу замедляют.
То есть получается, что нельзя один раз поднять данные в память, потом компилировать новый код и запускать на данных в гриде. Необходимо после каждой компиляции перезапускать грид.
Планируется ли какое-то решение? Насколько я понимаю в Java такая возможность в GridGain есть.
Спасибо.
Но и саппорт на бирже конечно хорошо отвечает, когда что-нибудь требуется.
Еще мысль, драйвер сетевухи же все равно через ядро пойдет, что тоже задержка.
А на микроконтроллере не сделали, они же написали, потому что протокол постоянно меняется, и как я понял на FPGA легче добиться гибкости, но это все допущения, так как сам такого не делал.
То есть они шлют кучу мелких заявкок, «пингуют» стакан и т.д.
Если например трейдер обнаруживает большую скрытую заявку на покупку, он может встать перед этой заявкой по чуть более высокой цене, и если цена пойдет вверх — то он сможет заработать. Если же цена пойдет вниз, то он будет застрахован, потому что успеет быстро продать актив в стакане этому дарк-пулу практически без потерь, таким образом полностью контролирует риски.
*промахнулся, это сюда
Я знаю что в России подобная разработка тоже ведется, я видел как этим занимаются мои коллеги, тоже на FPGA, но с хостом общаются через PCI-Express, когда я с ними последний раз разговаривал, этот интерфейс был у них вроде как узким местом. Больше к сожалению сказать ничего не могу.
Кстати, выложили бы логи nginx для русского IP, элементарный fingerprint сделать, понимаю, что это ничего бы не доказывало, но все же…
К примеру откройте Visual Studio и выполните простой цикл, чтобы внутри него кидалось и обрабатывлось исключение.
Затем выполните этот же цикл без блока try/catch.
Лично у меня разница получилась в 10 раз, что там где есть исключение работает медленнее.
Я повторюсь, что в это не верится, пока на практике не столкнешься, насколько они работу замедляют.