Здравствуйте, lpc, Вы писали:
ОК>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем. lpc>Не тяжело жить с мыслью что вокруг одни идиоты?
Его греет мысль что он сам — Д'Артаньян.
Здравствуйте, lpc, Вы писали:
lpc>Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
Да, в чистой Яве попадать в кэш иногда мучительно непросто. Вкупе с сообщением о 48 гигах и знанием размеров рынков мне теперь практически все понятно
Меня с моими задачами пока что от major сборок сильно спасают коллекции примитивов, типа trove, но если нужно от них нужно избавиться с гарантией, то да, подход неплохой. Опять же, в моем случае можно подкрутить параметры сборщика, чтобы протянуть достаточное (для меня!) время.
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, jazzer, Вы писали:
J>>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
lpc>Я бы посоветовал не делать выводов из ложных предпосылок, слухов и догадок. А то ерунда обычно всякая получается... так в двух предложениях выше — все мимо тазика.
Т.е. ты пришел в команду и участвовал в принятии решения о выборе платформы при том, что ты слез с С++ лишь 2 года назад? Что-то не сходится, имхо.
А так — у вас же, даже если ты в UBS, не одна система ведь на джаве написана, может, человек мне о другой вообще рассказывал
J>>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
lpc>Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию.
Вы считаете наносекунды и используете рефлексию?
А если рефлексия только на стартапе, так аналогичное решение элементарно делается и на плюсах — стартап и прочие некритичные к производительности вещи вообще на чем угодно можно писать, хоть на питоне (очень удобно, кстати).
наследование такого уровня (на массивах) есть и в С++, и в Си — посмотри на архитектуру Motif, например.
Вы выкинули практически все, что есть в джаве, проще, наверное, перечислить то, что сообственно от джавы осталось.
Вы выкинули автоматическое управление памятью и сборку мусора (главное отличие джавы от плюсов) и рулите памятью вручную.
Вы выкинули все библиотеки, даже базовые стандартные — при том, что с аналогичным решением на С/С++ стандартные и околостандартные библиотеки типа буста отлично работают.
Что осталось-то от джавы?
lpc>Чем это лучше С++ я уже писал.
Ага, писал.
Проще найти программера (гы), проще отлаживать, лучше IDE.
Офигенная аргументация в пользу выбора языка при том, что он будет использоваться через одно место.
И это при том, что ни одна из этих причин никак не соотносится с требованиями бизнеса, которые в HFT сводятся к одному — выжать скорость любыми способами.
Борьба со средствами языка, для этого не предназначенного (виртуальная машина, автоматическая сборка мусора) этому безусловно способствует.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Зато она стала гораздо интереснее, так как всякое формоклепание и базострадание наконец нас покинуло в пользу заточенных под это дело языков
Кстати, тут любят поговорить на тему того, что вот, мол, Facebook весь написан на PHP и никакими плюсами там и не пахло.
Так вот, C++ используется фейсбуком очень интенсивно:
So, you'll find Folly complements some existing high quality C++ libraries, such as Boost or the Standard Library, both of which we use heavily.
ОК>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем.
lpc>Не тяжело жить с мыслью что вокруг одни идиоты?
Не тяжело. Уж точно не идиоты стояли во главе (ну и вниз по цепочке) в Bear Stearns, Lehman Brothers, Washington Mutual и что там еще.
ОК>>С опережением ты поспешил. Я это и не собирался спрашивать. Спрошу другое. Допустим вы выжали целую секунду с вашим решением. Теперь следуя этой логике имеет смысл оптимизировать драйвера и/или планировщик Линукса (Линукс чисто как пример). Вы не собираетесь там этим в ближайшее время заняться?
lpc>Настройками линукса, биоса и сетевого оборудования занимается отдельная команда. Там свои гики и я не совсем в теме.
Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
lpc>P.S.: Планировшик к счастью оптимизировать не надо, т.к. ему особенно заниматься нечем — на каждый CPU биндится ровно 1 поток.
ОК>>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем. lpc>>Не тяжело жить с мыслью что вокруг одни идиоты? Т>Его греет мысль что он сам — Д'Артаньян.
Какой же я Д'Артаньян? Д'Артаньяны говорят "давай, давай сделаем, давай напишем, все будет классно!" Я же наоборот понимаю что они удаляли гланды через одно место, как тут уже сказали. Не нужно было этого делать.
А вот ты не только трололо, но еще и школоло. А лпц и остальные лица у него на работе — сто процентные Дон Кихоты.
J>>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
lpc>Я бы посоветовал не делать выводов из ложных предпосылок, слухов и догадок. А то ерунда обычно всякая получается... так в двух предложениях выше — все мимо тазика.
Хоть ты это и отрицаешь, но мне все равно кажется что джаззер прав. Я тоже об этом думал. Какой-то идиот сверху спустил задание и вы бангалорили в рамках указанного.
J>>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
lpc>Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию. Чем это лучше С++ я уже писал.
Чувак, хоть я и не видел вашего кода, но могу сказать с уверенностью что получился очередной говнокод.
ОК>>Тут уже несколько человек раскритиковали ваше решение. Так уж и хорошо?
lpc>Совершенно не показатель. Эти несколько человек не являются экспертами в подобных системах, в то время как мы знаем и следим что делают конкуренты.
А тут и не надо является экспертом в хфт чтобы понимать что вы там наделали (скорее всего по приказу сверху).
А эти люди, я считаю, тоже далеко не дураки хотя у меня и бывают с ними разногласия по другим вопросам.
ОК>>Да нормальный у меня настрой и у других тоже нормальный. Ты лучше уж поделись деталями (раз сам затронул тему что вы там сделали) сколько человек это пилило, обсуждало и неужели там не было никого кто бы воспротивился этому решению?
lpc>Пилило много людей, некоторых специально переманивали из других компаний, аналогичная технология используется у одного из крупнейших американских эксчейнджей (оно оригинально там и было придумано). Никто не противился, все только радовались. Извини но в цифрах и именах рассказывать не буду по понятным соображениям.
Все понятно. Боишься что я найду программистов количеством равному пилильщиков и замучу свой бизнес в области ХФТ?
И переманивание — не показатель.
ОК>>У вас память что ли бесконечна?
lpc>Ну по 48 гигов на каждом боксе минимум. Вполне себе конечно.
Какая ОСь и битность? Я не про физическую память а про ту что доступна процесу. Хотя и физическая тоже не бесконечна.
ОК>>Давай уж, не говори про курс молодого бойца и два-три месяца. Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
lpc>С чего ты решил что сколько будет объектов и какого типа — неизвестно? Объемы рынков это не случайная величина и завтра в 5 раз больше чем вчера быть не может.
Чувак, я не говорю о случайности и объемах рынка. Ты можешь вести где-нибудь счетчик всех своих объектов но речь не об этом. Речь о том что код каждый раз следует разному пути, каждый раз у объектов может быть (и будет скорее всего) разное состояние, разное количество объектов в коллекциях, все эти строки и т.д. Вот как ты инициализируешь объект строкой которую ты еще не получил по сети?
В общем можно извратиться, конечно же, но не стоит это того. Самое правильное дело создавать объекты когда они нужны.
ОК>>>Ну начинается. Простой, лаконичный код который можно понять сходу и/или пройтись отладчиком если надо. Так чтобы плеваться не приходилось. На счет 2). Вместо #define MY_CONST 7 пишешь const int MyConst = 7; или енумы, вместо #define SQUARE(x) ((x) * (x)) пишешь соответсвенно инлайн функцию, на счет темплейтов — пользуешься стандартными контейнерами и смарт пойнтерами и очень редко когда сам пишешь темплейтные функции и классы. Большего и не нужно.
KP>>Около 5 лет назад (с тех пор я студией не пользовался) она в легкую разбирала куда более сложные конструкции чем ты привел. Тут дело не в студии, lpc просто за уши какие-то нелепые причины притягивает. Полагаю, именно они были использованы для обоснования описанного выше пятиколесного велосипеда с изменяемой геометрией крыла и воздушной подушкой.
lpc>Боюсь здесь дело все таки в студии, а не в lpc. А еще в том, что у кого то остались светлые романтические воспоминания 5 летней давности о старой доброй студии. Мне когда то VC5 очень нравилась, после борланда под досом.
Боюсь тут дело в лпц а не в студии. Если лпц каждый раз пишет что-то вроде
#define MY_COOL_MACRO(a, b, c) \
do \
{ \
// Тут дохрена кода
} \
while (false)
вместо того чтобы написать инлайн функцию, то, разумеется, студия ему не поможет.
ОК>>>>Так и я об этом же. Одна команда (технари) переписывает Джаву (возможно даже и успешно), другая команда пишет хреновые стратегии и некачественный код (кванты) и нивелирует достижения первой команды.
J>>>Угу. Именно поэтому самые хитрые технари , которых задрало писать бесконечные одинаковые лайн- и фид-хендлеры, уходят в ту самую "другую" команду
ОК>>Ничего не понял. Технари любят технологии. Им интереснее с сокетами возиться. J>Надоедает быстро. Меня лично задрало уже писать одно и то же, копаясь в кривизне очередного непродуманного протокола. J>После пары написанных фид/лайн-хендлеров вся эта возня с сокетами превращается в скучнейшую рутину.
Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло.
ОК>>А кванты — да там немного самого языка (программирования) и куча математики. J>Смотря какой бизнес. В HFT технологии в полный рост и на стороне стратегии, иначе, как ты правильно заметил, усилия программеров connectivity/market data будут нивелированы тормозной стратегией. А написать быструю стратегию при сохранении всех ее фич — это реальный вызов.
Да, все верно, но тут речь больше не о быстроте квантовского кода (а она, я знаю, очень даже хромает) а о качестве самих стратегий (тоже могут прихрамывать). Стоит ли переписывать Джавовский аллокатор чтобы выжать пару нано-секунд если сама стратегия просирает деньги? Я это больше имел в виду.
ОК>>Да нормальный у меня настрой и у других тоже нормальный. Ты лучше уж поделись деталями (раз сам затронул тему что вы там сделали) сколько человек это пилило, обсуждало и неужели там не было никого кто бы воспротивился этому решению?
J>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
Похоже что так оно и было хоть лпц и отрицает это.
ОК>>Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
J>Да ладно тебе, не знаешь. J>Берешь объем торгов с какого-нть Russell rebalance, умножаешь на 2 — вот тебе и оценка сверху. J>Если памяти хватит все это преаллокировать в массивах (а в условиях рукопашного боя по голым буферам с почти нулевыми дополнительными издержками памяти это вполне реально) — большего и не надо. J>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
Да я не об этом. Грубо оценить или даже подсчитать точное количество объектов, конечно же, можно но в том-то и дело что каждый раз в программе следуется разный путь, состояние объектов неизвестно до рантайма, каждый раз может быть разное количество объектов в коллекциях которое определяется только в рантайме и т.д.
Ну и потом. Допустим они заранее создали все объекты которые только возможно. Зачем им тогда писать свой аллокатор? Просто вырубить сборщик мусора либо посредством АПИ (не знаю возможно ли такое) либо вырубив вызову функции которая запускает этот сборщик мусора.
В общем, скорее всего, они-таки написали свой аллокатор а лпц просто неправильно выразился.
Здравствуйте, Олег К., Вы писали:
ОК>Ну и потом. Допустим они заранее создали все объекты которые только возможно. Зачем им тогда писать свой аллокатор?
Ну, судя по тому, что он еще писал, у них блочный аллокатор, т.е. они преаллокировали здоровый кусок памяти на, скажем, 100000 ордеров, и пока у них меньше 10000 ордеров, никаких больше аллокаций не происходит. Но если рынок колбасит и ордеров нужно больше, то выделяется еще один блок на следуюшую сотню тысяч ордеров, и дальше опять никаких аллокаций.
lpc>>Настройками линукса, биоса и сетевого оборудования занимается отдельная команда. Там свои гики и я не совсем в теме.
ОК>Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
Кстати о жести. Вот здесь объявление о позиции. На всякий случай текст позиции (не рекламы ради):
Java and C++ Systems Programming positions
Algo Trading firm in New York City seeks mid level developers with BS/MS in Computer or Electrical Engineering and practical/commercial experience in low level systems development.
Experience in at least some of the following is preferable: strong knowledge of data structures, algorithms, optimization for the core of the operating systems (Linix ideally); developing daemons, utilities, tools for automating common/difficult tasks; using interfaces and data structures written by the kernel developers to implement device control and IO; interrupt latency and hardware determinism; locks, queues, Kobjects; page allocations, schedulers, etc.
Very competitve pay structure, collegial, professional work environment.
Я раньше думал что они просто хотят понимания как ОС работает на низком уровне, но в свете последних дискуссий ничуть не удивлюсь если они таки залезут в kernel mode если еще не залезли.
И ведь таки залезут и будут считать что сделали лучше чем Линус и Ко и производители сетевых карточек. А потом будут переманивать друг у друга экспертов в данной области, как уважаемый лпц тут уже признался.
В общем в финансовой индустрии многие вещи до маразма доводят .
Здравствуйте, Олег К., Вы писали:
ОК>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло.
Ну так мне это как раз интереснее чем сокеты — обсуждать с квантами, чего они, собственно, хотели тут сделать, а дальше искать эффективные пути реализации их идей.
А то жалко ведь, что с таким трудом полученное физтеховское образование вообще никак не используется. А тут хоть какие-то применение (даже один раз дифур пришлось решить, прикинь) плюс дополнительное (само)образование в области, которая от меня всегда была далека — приятное ощущение, когда мозги работают
Плюс в отличие от кривого протокола, кривизну квантовского кода ты исправить можешь, а с кривизной протокола тебе жить, со всеми сопутствующими граблями и велосипедами типа таких: http://www.rsdn.ru/forum/cpp/2899831.1.aspx
(хотя не спорю, тот велосипед было прикольно изобрести, но это удовольствие, сравнимое с тем, что получает уважаемый lpc — преодоление трудностей изначально кривого решения)
ОК>>>А кванты — да там немного самого языка (программирования) и куча математики. J>>Смотря какой бизнес. В HFT технологии в полный рост и на стороне стратегии, иначе, как ты правильно заметил, усилия программеров connectivity/market data будут нивелированы тормозной стратегией. А написать быструю стратегию при сохранении всех ее фич — это реальный вызов.
ОК>Да, все верно, но тут речь больше не о быстроте квантовского кода (а она, я знаю, очень даже хромает) а о качестве самих стратегий (тоже могут прихрамывать). Стоит ли переписывать Джавовский аллокатор чтобы выжать пару нано-секунд если сама стратегия просирает деньги? Я это больше имел в виду.
если стратегия теряет деньги, то не стоит, конечно же
С другой стороны, если ты можешь сделать быстрый фреймворк для целого класса стратегий, то дальше уже разные кванты могут предложить разное, и что-то будет зарабатывать деньги, и это будет реализуемо с разумными усилиями. Но если в команде нет толкового кванта, который способен выдать прибыльную стратегию, то такой бизнес просто обречен, с любым аллокатором.
ОК>Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
ОК>Я раньше думал что они просто хотят понимания как ОС работает на низком уровне, но в свете последних дискуссий ничуть не удивлюсь если они таки залезут в kernel mode если еще не залезли.
Да уж много лет как там
ОК>И ведь таки залезут и будут считать что сделали лучше чем Линус и Ко и производители сетевых карточек. А потом будут переманивать друг у друга экспертов в данной области, как уважаемый лпц тут уже признался.
Я даже больше скажу — как бы Линус и Ко не старался, но он не может угодить сразу всем. Linux хорош для throughput, но если надо latency — он плох. Если бы вы хоть капельку знали предметную область, то не писали бы полную чушь на тему линусов и т.п..
В первую очередь рекомендую ознакомиться со стеком от solarflare, он есть и в бесплатном виде (openonload). Особенно с их zero-copy интерфейсами, или, новым веянием у меня тут на работе, с ef_vi. Вам просто эти обозначения ничего не говорят. Но разница в latency с "обычным линуксом", извините, колоссальная.
Здравствуйте lpc, Вы писали:
lpc>Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
Вот обьясни- если в ядро в сетевую карту окно прорубили (из-за скор отклика), об'екты занимают больше места в памяти, чем нативные, GC отключен- зачем там Java, это какая-то забава? Плюс наверняка есть JNI и связанные с ним накладные расходы.
Здравствуйте, lpc, Вы писали:
lpc>я хотел было поделиться интересным подходом использования джавы
При этом не ответил ни на один технический вопрос, зато повыпендривался на отличненько.
lpc>а нарвался на традиционное "такое невозможно, да вы дураки, вам вообще это не надо". Но с другой стороны это радует, конкурентов на рынке все еще мало,
Я работаю с подобными поделками (zero-GC, single-thread), весь этот цирк и лубок мне известен на собсвенном опыте. К сожалению дурь в бошках программистов на С++, переквалифицировавшихся на джаву крепка.
lpc>общество еще не созрело
Но дурь общества — еще не столь. Это вселяет надежду.
.
