ОК>>Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
J>Просто этим обычно разные люди занимаются.
Так и я об этом же. Одна команда (технари) переписывает Джаву (возможно даже и успешно), другая команда пишет хреновые стратегии и некачественный код (кванты) и нивелирует достижения первой команды.
Здравствуйте, Олег К., Вы писали:
ОК>Ну начинается. Простой, лаконичный код который можно понять сходу и/или пройтись отладчиком если надо. Так чтобы плеваться не приходилось. На счет 2). Вместо #define MY_CONST 7 пишешь const int MyConst = 7; или енумы, вместо #define SQUARE(x) ((x) * (x)) пишешь соответсвенно инлайн функцию, на счет темплейтов — пользуешься стандартными контейнерами и смарт пойнтерами и очень редко когда сам пишешь темплейтные функции и классы. Большего и не нужно.
Около 5 лет назад (с тех пор я студией не пользовался) она в легкую разбирала куда более сложные конструкции чем ты привел. Тут дело не в студии, lpc просто за уши какие-то нелепые причины притягивает. Полагаю, именно они были использованы для обоснования описанного выше пятиколесного велосипеда с изменяемой геометрией крыла и воздушной подушкой.
ОК>>У вас память что ли бесконечна?
M>Кстати, это вариант. Тогда аллокатор будет реально быстрым
Тогда аллокатора вообще как такового не надо. Создавай свой объект в конце большого массива байт и не думай чтобы убирать ненужные объекты.
ОК>>Давай уж, не говори про курс молодого бойца и два-три месяца. Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
M>Чую, что все 'объекты' у них — это одноуровневые структуры с методами, сильно напоминающими ByteBuffer: getInt(offset), getByte(offset) и т.д. M>Но вот как они их вычищают???
Все равно не понимаю. Наверное, все-таки, они написали свой аллокатор но меня до сих пор заводит в тупик фраза что они все свои объекты преаллокейтают.
Здравствуйте, Олег К., Вы писали:
ОК>>>Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
J>>Просто этим обычно разные люди занимаются.
ОК>Так и я об этом же. Одна команда (технари) переписывает Джаву (возможно даже и успешно), другая команда пишет хреновые стратегии и некачественный код (кванты) и нивелирует достижения первой команды.
Угу. Именно поэтому самые хитрые технари , которых задрало писать бесконечные одинаковые лайн- и фид-хендлеры, уходят в ту самую "другую" команду
Здравствуйте, Олег К., Вы писали:
ОК>Все равно не понимаю. Наверное, все-таки, они написали свой аллокатор но меня до сих пор заводит в тупик фраза что они все свои объекты преаллокейтают.
Почему в тупик заводит? Типичный Си/Си++ подход, когда нужно обеспечить быструю работу с памятью. Выделяешь большой кусок памяти и последовательно отдаешь его по-кусочкам нуждающимся, назад ничего не возвращаешь. Когда все запросившие память из куска "померли" — возвращаешься к началу.
ОК>>Ну начинается. Простой, лаконичный код который можно понять сходу и/или пройтись отладчиком если надо. Так чтобы плеваться не приходилось. На счет 2). Вместо #define MY_CONST 7 пишешь const int MyConst = 7; или енумы, вместо #define SQUARE(x) ((x) * (x)) пишешь соответсвенно инлайн функцию, на счет темплейтов — пользуешься стандартными контейнерами и смарт пойнтерами и очень редко когда сам пишешь темплейтные функции и классы. Большего и не нужно.
KP>Около 5 лет назад (с тех пор я студией не пользовался) она в легкую разбирала куда более сложные конструкции чем ты привел. Тут дело не в студии, lpc просто за уши какие-то нелепые причины притягивает. Полагаю, именно они были использованы для обоснования описанного выше пятиколесного велосипеда с изменяемой геометрией крыла и воздушной подушкой.
Тут речь не об этом. Допустим студия помогает тебе "пройтись" по жутчайшим макросам и темплейтам. Значит ли это что надо писать такую жуть (не сомневаюсь что ты понимаешь о чем я) только потому что тебе помогает студия? Разумеется нет. Я, вот, вообще не понимаю как любители паттернов и Александреску умудряются их впихнуть куда ни попадя.
ОК>Тут речь не об этом. Допустим студия помогает тебе "пройтись" по жутчайшим макросам и темплейтам. Значит ли это что надо писать такую жуть (не сомневаюсь что ты понимаешь о чем я) только потому что тебе помогает студия? Разумеется нет. Я, вот, вообще не понимаю как любители паттернов и Александреску умудряются их впихнуть куда ни попадя.
Обычно "паттерны Александреску" (С) и всякие там low-latency не пересекаются. Просто в силу ортогональности назначения. Хотя бы просто потому, что "все эти ваши паттерны" — попытка из С++ сделать язык чуть более высокого уровня. Попытка, надо сказать, бестолковая, поскольку лучше сразу взять язык упомянутого уровня.
ОК>>Все равно не понимаю. Наверное, все-таки, они написали свой аллокатор но меня до сих пор заводит в тупик фраза что они все свои объекты преаллокейтают.
KP>Почему в тупик заводит? Типичный Си/Си++ подход, когда нужно обеспечить быструю работу с памятью. Выделяешь большой кусок памяти и последовательно отдаешь его по-кусочкам нуждающимся, назад ничего не возвращаешь. Когда все запросившие память из куска "померли" — возвращаешься к началу.
Ну так ты отдаешь эти куски по мере надобности, т.е. это самый настоящий хоть и примитивный аллокатор. Я же его фразу понимаю (возможно неправильно) что они при стартапе создают все объекты которые им понадобятся в будущем. Перечитай его начальный пост.
ОК>>Тут речь не об этом. Допустим студия помогает тебе "пройтись" по жутчайшим макросам и темплейтам. Значит ли это что надо писать такую жуть (не сомневаюсь что ты понимаешь о чем я) только потому что тебе помогает студия? Разумеется нет. Я, вот, вообще не понимаю как любители паттернов и Александреску умудряются их впихнуть куда ни попадя.
SD>Обычно "паттерны Александреску" (С) и всякие там low-latency не пересекаются. Просто в силу ортогональности назначения. Хотя бы просто потому, что "все эти ваши паттерны" — попытка из С++ сделать язык чуть более высокого уровня. Попытка, надо сказать, бестолковая, поскольку лучше сразу взять язык упомянутого уровня.
В теории не пересекаются. На практике у каждого свое видение как надо писать код и паттерны у некоторых товарищей играют далеко не последнюю роль.
ОК>>>>Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
J>>>Просто этим обычно разные люди занимаются.
ОК>>Так и я об этом же. Одна команда (технари) переписывает Джаву (возможно даже и успешно), другая команда пишет хреновые стратегии и некачественный код (кванты) и нивелирует достижения первой команды.
J>Угу. Именно поэтому самые хитрые технари , которых задрало писать бесконечные одинаковые лайн- и фид-хендлеры, уходят в ту самую "другую" команду
Ничего не понял. Технари любят технологии. Им интереснее с сокетами возиться. А кванты — да там немного самого языка (программирования) и куча математики.
Здравствуйте, Олег К., Вы писали:
ОК>Да нормальный у меня настрой и у других тоже нормальный. Ты лучше уж поделись деталями (раз сам затронул тему что вы там сделали) сколько человек это пилило, обсуждало и неужели там не было никого кто бы воспротивился этому решению?
Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь.
То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
ОК>Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
Да ладно тебе, не знаешь.
Берешь объем торгов с какого-нть Russell rebalance, умножаешь на 2 — вот тебе и оценка сверху.
Если памяти хватит все это преаллокировать в массивах (а в условиях рукопашного боя по голым буферам с почти нулевыми дополнительными издержками памяти это вполне реально) — большего и не надо.
Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
Здравствуйте, Олег К., Вы писали:
ОК>>>Так и я об этом же. Одна команда (технари) переписывает Джаву (возможно даже и успешно), другая команда пишет хреновые стратегии и некачественный код (кванты) и нивелирует достижения первой команды.
J>>Угу. Именно поэтому самые хитрые технари , которых задрало писать бесконечные одинаковые лайн- и фид-хендлеры, уходят в ту самую "другую" команду
ОК>Ничего не понял. Технари любят технологии. Им интереснее с сокетами возиться.
Надоедает быстро. Меня лично задрало уже писать одно и то же, копаясь в кривизне очередного непродуманного протокола.
После пары написанных фид/лайн-хендлеров вся эта возня с сокетами превращается в скучнейшую рутину.
ОК>А кванты — да там немного самого языка (программирования) и куча математики.
Смотря какой бизнес. В HFT технологии в полный рост и на стороне стратегии, иначе, как ты правильно заметил, усилия программеров connectivity/market data будут нивелированы тормозной стратегией. А написать быструю стратегию при сохранении всех ее фич — это реальный вызов.
Здравствуйте, jazzer, Вы писали:
J>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
Понятно, решение принималось тогда, когда нормальных сборщиков мусора не было. А потом уже динозавра было не переписать.
J>Да ладно тебе, не знаешь. J>Берешь объем торгов с какого-нть Russell rebalance, умножаешь на 2 — вот тебе и оценка сверху. J>Если памяти хватит все это преаллокировать в массивах (а в условиях рукопашного боя по голым буферам с почти нулевыми дополнительными издержками памяти это вполне реально) — большего и не надо. J>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
Объём торгов? Market side на многих биржах занимает несколько 10-ков гигов. Для broker side все, впрочем, много проще — хорошей персоналки хватит.
Здравствуйте, mik1, Вы писали:
M>Понятно, решение принималось тогда, когда нормальных сборщиков мусора не было. А потом уже динозавра было не переписать.
Ну так это вдвойне глупость — взять язык со сборкой мусора и для начала выкинуть сборку мусора, так как она тормозит. И заодно выкинуть стандартную и остальные библиотеки и прочая, после чего от языка остается какое-то невнятное Си-подобное подмножество, которое гораздо проще и прямее было бы реализовать на языке, который для этого и предназначен (С/С++).
Каша из топора, в общем. Наверняка с десяток манагеров сделали себе карьеры на этом проекте.
M>Объём торгов? Market side на многих биржах занимает несколько 10-ков гигов. Для broker side все, впрочем, много проще — хорошей персоналки хватит.
Во-первых, не факт, что нужно хранить всю market data — в ней обычно куча полей, которые данной конкретной стратегии не нужны.
Во-вторых, не факт, что ее вообще надо хранить всю за день — вполне может быть, что будет достаточно одного текущего снапшота.
В общем, все от конкретной стратегии зависит.
ЗЫ. Если хочешь снести свое сообщение — жми не "Удалить", а "Удалить как ошибочное" — тогда оно исчезнет сразу же, если не было ответов.
H>>У меня был переход с C++ на Node.js. H>>В результате трудоемкость упала раз в пять при сохранении производительности.
DV>а как вы ее, производительность, меряли?
Количество HTTP запросов в секунду и время отклика остались на прежнем уровне. Задержка ухудшилась у 5% запросов из-за сборщика мусора. Но это приемлимое зло, за счет трудоемкости окупается
Здравствуйте, Олег К., Вы писали:
ОК>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем.
Не тяжело жить с мыслью что вокруг одни идиоты?
ОК>С опережением ты поспешил. Я это и не собирался спрашивать. Спрошу другое. Допустим вы выжали целую секунду с вашим решением. Теперь следуя этой логике имеет смысл оптимизировать драйвера и/или планировщик Линукса (Линукс чисто как пример). Вы не собираетесь там этим в ближайшее время заняться?
Настройками линукса, биоса и сетевого оборудования занимается отдельная команда. Там свои гики и я не совсем в теме.
P.S.: Планировшик к счастью оптимизировать не надо, т.к. ему особенно заниматься нечем — на каждый CPU биндится ровно 1 поток.
Здравствуйте, mik1, Вы писали:
M>Интересно таки, почему стоит оставлять от Явы одно название, но пользоваться ею. M>Если маркет не 24-часовой, то в окнах можно чистить память/перезапускать процесс.
Именно так и происходит.
M>Следующий интересный вопрос — размер working set. Minor GC с || коллектором занимают > 0.1 секунды на несколько гигабайтных объёмах (причем тут есть шансы пошаманить, использовать G1 или машину от Azul).
Azul у нас был недавно, сейчас другие команды тестируют, но они сами говорят что будет в целом на 5% медленее, но зато без затыков. Для некоторых наших систем это будет хорошее решение.
M>Если же память вручную аллокировать, то возвращаемся к вопросу о фрагментации, компактированию и прочим около сборочно-мусорным вещам... Тут можно предположить, что памяти до фига и вы дотягиваете до окна в торгах. Только с дофига памяти можно и не городить такой огород...
Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
Здравствуйте, Олег К., Вы писали:
ОК>Тут уже несколько человек раскритиковали ваше решение. Так уж и хорошо?
Совершенно не показатель. Эти несколько человек не являются экспертами в подобных системах, в то время как мы знаем и следим что делают конкуренты.
ОК>Да нормальный у меня настрой и у других тоже нормальный. Ты лучше уж поделись деталями (раз сам затронул тему что вы там сделали) сколько человек это пилило, обсуждало и неужели там не было никого кто бы воспротивился этому решению?
Пилило много людей, некоторых специально переманивали из других компаний, аналогичная технология используется у одного из крупнейших американских эксчейнджей (оно оригинально там и было придумано). Никто не противился, все только радовались. Извини но в цифрах и именах рассказывать не буду по понятным соображениям.
ОК>У вас память что ли бесконечна?
Ну по 48 гигов на каждом боксе минимум. Вполне себе конечно.
ОК>Давай уж, не говори про курс молодого бойца и два-три месяца. Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
С чего ты решил что сколько будет объектов и какого типа — неизвестно? Объемы рынков это не случайная величина и завтра в 5 раз больше чем вчера быть не может.
Здравствуйте, jazzer, Вы писали:
J>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
Я бы посоветовал не делать выводов из ложных предпосылок, слухов и догадок. А то ерунда обычно всякая получается... так в двух предложениях выше — все мимо тазика.
J>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию. Чем это лучше С++ я уже писал.
Здравствуйте, kaa.python, Вы писали:
ОК>>Ну начинается. Простой, лаконичный код который можно понять сходу и/или пройтись отладчиком если надо. Так чтобы плеваться не приходилось. На счет 2). Вместо #define MY_CONST 7 пишешь const int MyConst = 7; или енумы, вместо #define SQUARE(x) ((x) * (x)) пишешь соответсвенно инлайн функцию, на счет темплейтов — пользуешься стандартными контейнерами и смарт пойнтерами и очень редко когда сам пишешь темплейтные функции и классы. Большего и не нужно.
KP>Около 5 лет назад (с тех пор я студией не пользовался) она в легкую разбирала куда более сложные конструкции чем ты привел. Тут дело не в студии, lpc просто за уши какие-то нелепые причины притягивает. Полагаю, именно они были использованы для обоснования описанного выше пятиколесного велосипеда с изменяемой геометрией крыла и воздушной подушкой.
Боюсь здесь дело все таки в студии, а не в lpc. А еще в том, что у кого то остались светлые романтические воспоминания 5 летней давности о старой доброй студии. Мне когда то VC5 очень нравилась, после борланда под досом.
, которых задрало писать бесконечные одинаковые лайн- и фид-хендлеры, уходят в ту самую "другую" команду 
