Здравствуйте, jazzer, Вы писали:
Т>>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>>Развидеть невозможно!
J>это obfuscated perl, не надо его за нормальынй перл выдавать.
Дык язык позволяет жеж.
Давай тогда и С++ делить на obfuscated и "нормальный".
J>Почему то перловые скрипты, которые пишу я, ни у кого в команде вопросов не вызывают, хотя перл, кроме меня, знает от силы полтора человека.
Наверное потому, почему С++ который я пишу тоже вопросов не вызывает как у коллег так и у IDE?
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, licedey, Вы писали:
L>>Простите, а на чем пишут бэк-энд мэйн-стрима? Гугл, бинг, фэйсбук, яндекс, касперски, паралелс и прочее...Понимаю не все там работают, однако же.
KP>Qt у обоих. Про остальных не знаю
Я бы посмеялся, но вы же уважаемый человек Qt — язык по вашему? Те же плюсы. Или мы тут про STL и не далее глаголим.
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, jazzer, Вы писали:
Т>>>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>>>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>>>Развидеть невозможно!
J>>это obfuscated perl, не надо его за нормальынй перл выдавать. Т>Дык язык позволяет жеж. Т>Давай тогда и С++ делить на obfuscated и "нормальный".
Так и делят же успешно. Даже книжки пишут на эту тему
J>>Почему то перловые скрипты, которые пишу я, ни у кого в команде вопросов не вызывают, хотя перл, кроме меня, знает от силы полтора человека. Т>Наверное потому, почему С++ который я пишу тоже вопросов не вызывает как у коллег так и у IDE?
Здравствуйте, Трололоша, Вы писали:
Т>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>Развидеть невозможно!
Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации.
Здравствуйте, anonymous, Вы писали:
Т>>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>>Развидеть невозможно!
A>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации.
Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
Здравствуйте, Трололоша, Вы писали:
A>>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации. Т>Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
«Не так прикольно оформленные очень похожие кусочки» и JAPH-скрипты — это совершенно разные вещи, уровень владения языком в этих двух случаях различается на порядок.
Здравствуйте, anonymous, Вы писали:
A>>>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации. Т>>Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
A>«Не так прикольно оформленные очень похожие кусочки» и JAPH-скрипты — это совершенно разные вещи, уровень владения языком в этих двух случаях различается на порядок.
Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода.
Мне похрен какой там уровень владения языком у автора, но если он пишет сразу обфусцированный код то и его и код исключительно фтопку.
Здравствуйте, Трололоша, Вы писали:
Т>Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода.
Ещё раз, для непонятливых: подобные кусочки для того и пишутся, чтобы было сложно понять, как они работают.
Т>Мне похрен какой там уровень владения языком у автора, но если он пишет сразу обфусцированный код то и его и код исключительно фтопку.
JAPH-код не пишут для production, в production часто попадает говнокод, но его то как раз пишут на любом языке.
Здравствуйте, anonymous, Вы писали:
Т>>Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода. A>Ещё раз, для непонятливых: подобные кусочки для того и пишутся, чтобы было сложно понять, как они работают.
Ты ничего не понял.
Отдельные идиоты всегда в таком стиле пишут свой код. Потому что могут и хотят.
Перечитай с чего мы в этой ветке на перл вышли.
lpc>>Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
AG>Вот обьясни- если в ядро в сетевую карту окно прорубили (из-за скор отклика), об'екты занимают больше места в памяти, чем нативные, GC отключен- зачем там Java, это какая-то забава? Плюс наверняка есть JNI и связанные с ним накладные расходы.
Да там в других местах скорее всего другие расходы.
ОК>>А вот ты не только трололо, но еще и школоло. А лпц и остальные лица у него на работе — сто процентные Дон Кихоты. Т>Ну я ж говорю: Д'Артаньян. Т>У тебя один ты светоч разума и носитель сакрального знания. А всех вокруг считаешь кем полагается считать Д'Артаньяну окружающих.
ОК>>Какой же я Д'Артаньян? Т>Да классический же!
лпц — дон кихот, а д'артаньян — это ты, чудик. Вот здесь
ОК>>Я раньше думал что они просто хотят понимания как ОС работает на низком уровне, но в свете последних дискуссий ничуть не удивлюсь если они таки залезут в kernel mode если еще не залезли.
SD>Да уж много лет как там
Что-то я ни разу не слышал чтобы JPM, Credit Swiss, UBS, Deutsche Bank, Barclay's и т.д. меняли код ядра и писали свои драйвера. Не подкинешь ссылку ни их contributions в мире опенсорса?
Хотя сейчас на дайсе все чаще и чаще встречается слово ultra — ultra high frequency trading, ultra low latency. Лезут в ядро таки ну и плюс понты что у них все ультра.
ОК>>И ведь таки залезут и будут считать что сделали лучше чем Линус и Ко и производители сетевых карточек. А потом будут переманивать друг у друга экспертов в данной области, как уважаемый лпц тут уже признался.
SD>Я даже больше скажу — как бы Линус и Ко не старался, но он не может угодить сразу всем. Linux хорош для throughput, но если надо latency — он плох. Если бы вы хоть капельку знали предметную область, то не писали бы полную чушь на тему линусов и т.п..
Что-то ты не то тут говоришь. Я, конечно, понимаю что Линус и Ко не может всем угодить, однако замечу что каждый должен заниматься своими делами. Производители железа должны заниматься производством железок и драйверами к ним, Линус должен заниматься своим детищем как он считает нужным, разработчики компиляторов компиляторами, а финансовые компании своими проектами которые работают в юзер моде.
Как бы Линус не мог всем угодить, все равно работу над ядром он сделает в сотни раз лучше чем те которым спустили сверху требования "сделать лучше чем Линус" (как это в случае с Джавой тут) ибо это его детище и хлеб.
Вообще следуя твоей логике для программистов этих банков просто непаханное поле — начиная улучшением кода ядра под свои нужды и заканчивая разработкой своего железа. Я про это прикольнулся уже выше.
SD>В первую очередь рекомендую ознакомиться со стеком от solarflare, он есть и в бесплатном виде (openonload). Особенно с их zero-copy интерфейсами, или, новым веянием у меня тут на работе, с ef_vi. Вам просто эти обозначения ничего не говорят. Но разница в latency с "обычным линуксом", извините, колоссальная.
На дайсе: solarflare — выдало два !!! результата. openonload — ноль. Что это за фигня, каюсь, я не знаю но звучит как third party product. Я же говорил о том чтобы эти банки меняли сами код ядра и драйверов.
ОК>>Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
SD>Это еще почему? Не понимаю вашего наезда.
Потому что каждый должен заниматься своими вещами. Булочники пекут хлеб, производители железок делают железо и пишут драйвера к ним, Линус и Ко занимается Линуксом а разработчики компиляторов занимаются компиляторами. Что вообще от банка будет если он залезет во все эти области (только потому что они посчитают что сделают лучше)? По-моему это очевидно.
ОК>>>Не тяжело. Уж точно не идиоты стояли во главе (ну и вниз по цепочке) в Bear Stearns, Lehman Brothers, Washington Mutual и что там еще. CC>>Ну и где щас тот Lehman Brothers? CC>>Довелось с ними поработать, незадолго до их бесславной кончины. Редкостные дебилы там попадались. Кубло индусов, с подковёрными дрязгами.
J>Подозреваю, что это был сарказм со стороны Олега К.
Все верно. Это был сарказм. Более того мое отношение к этой финансовой индустрии прослеживается во многих ответах тут.
lpc>>>Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию. Чем это лучше С++ я уже писал. ОК>>Чувак, хоть я и не видел вашего кода, но могу сказать с уверенностью что получился очередной говнокод.
lpc>Мальчик, шел бы ты лесом со своей юнешеской самоуверенностью да не возвращался. Реально утомил своим негативом.
Я постарше тебя буду все-таки и это ты влез сюда со своими понтами.
ОК>Что-то я ни разу не слышал чтобы JPM, Credit Swiss, UBS, Deutsche Bank, Barclay's и т.д. меняли код ядра и писали свои драйвера. Не подкинешь ссылку ни их contributions в мире опенсорса?
Это типа сарказм такой, или взаправдашний вопрос?!
ОК>На дайсе: solarflare — выдало два !!! результата. openonload — ноль. Что это за фигня, каюсь, я не знаю но звучит как third party product. Я же говорил о том чтобы эти банки меняли сами код ядра и драйверов.
Ты сейчас делаешь мне очень смешно. Это плохо, потому что я сижу в офисе, и на меня уже начинают коситься остальные. Мне трудно сделать умное лицо и вид, будто я продолжаю копать код красно-черного дерева, которое заюзали для очереди приоритетов без дОлжного понимания, _КАКИЕ_ данные будут в эту очередь попадать. Вероятнее всего, дерево вообще надобно выкинуть, и заменить на, скорее всего, скиплист или кастомную структуру (не придумал пока, какую).
onload, и его ef_vi интерфейс — это такая специальная дырка, которая прокидывает мне в память юзерского процесса tx, rx и events rings виртуализированной сетевой карты. Накукуй мне все эти linux kernel'ы сдались с их громоздкими сокетами, если я спокойно кладу zero-copy frames... и, кстати, про разработку банками железяк — гугли про заказные чипы тоже есть, но нет уверенности, что с ними будет сколь-нибудь быстрее, а вот что геморройнее — это наверняка. Более того, у тех же SolarFlare уже все украдено до нас, и даже гнездо программируемого чипа предусмотрено сразу за PHY сетевухи.
А еще есть забавная сетевуха с Linux'ом на борту (Killer зовется), жаль, не удалось ее попробовать. Начальник сначала с серьезным видом кивал, мол, да, надо бы глянуть, но потом глупо заржал и сказал, что провести геймерскую сетевуху по бухгалтерии у него рука не поднимется, и вообще засмеют.
ОК>>>Ну и потом. Допустим они заранее создали все объекты которые только возможно. Зачем им тогда писать свой аллокатор? J>>Ну, судя по тому, что он еще писал, у них блочный аллокатор, т.е. они преаллокировали здоровый кусок памяти на, скажем, 100000 ордеров, и пока у них меньше 10000 ордеров, никаких больше аллокаций не происходит. Но если рынок колбасит и ордеров нужно больше, то выделяется еще один блок на следуюшую сотню тысяч ордеров, и дальше опять никаких аллокаций.
lpc>Да, все примерно так (только расти x2 нет смысла, +25% обычно хватит чтобы дожить до конца дня). Назвать это "аллокатором" у меня язык не поворачивается, слишком уж все это тривиально. Но некоторым товарищам здесь этого не понять и они будут с пеной у рта доказывать что они там наговнокодили.
Вот именно что наговнокодили и я до сих пор не могу понять что же именно.
Если вы уж занялись тем чем вы занялись, то вот решение в лоб. На старте имеем большой массив — нашу кучу. Каждый новый объект создаем вконце массива (при вызове new) — операция мгновенная и где-то тут ты говорил что не удаляете объекты. К чему эти 10000 ордеров и +25% — .
ОК>>А тут и не надо является экспертом в хфт чтобы понимать что вы там наделали (скорее всего по приказу сверху).
lpc>Все твои вопросы в этом и других ответах показывают, что таки надо. Уж если не экспертом, но хотя бы иметь опыт работы с подобными системами. Иначе — шквал очень глупых и смешных вопросов, отвечать на которые нет никакого желания.
Ну еще бы! Ваше решение настолько гениально что куда уж мне понять его?
ОК>>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло.
J>Ну так мне это как раз интереснее чем сокеты — обсуждать с квантами, чего они, собственно, хотели тут сделать, а дальше искать эффективные пути реализации их идей. J>А то жалко ведь, что с таким трудом полученное физтеховское образование вообще никак не используется. А тут хоть какие-то применение (даже один раз дифур пришлось решить, прикинь) плюс дополнительное (само)образование в области, которая от меня всегда была далека — приятное ощущение, когда мозги работают
Ну ок. Убедил. Каждому свое.
J>Плюс в отличие от кривого протокола, кривизну квантовского кода ты исправить можешь, а с кривизной протокола тебе жить, со всеми сопутствующими граблями и велосипедами типа таких: http://www.rsdn.ru/forum/cpp/2899831.1.aspx
(хотя не спорю, тот велосипед было прикольно изобрести, но это удовольствие, сравнимое с тем, что получает уважаемый lpc — преодоление трудностей изначально кривого решения)
И опять ты исходишь из того что уже существует кривой протокол но квантовский код пишется с нуля и ты можешь подправить его если что. На деле я видел такой код на который страшно смотреть и который не понимали сами кванты. Об эффективности того кода даже речь и не шла.
ОК>>>>А кванты — да там немного самого языка (программирования) и куча математики. J>>>Смотря какой бизнес. В HFT технологии в полный рост и на стороне стратегии, иначе, как ты правильно заметил, усилия программеров connectivity/market data будут нивелированы тормозной стратегией. А написать быструю стратегию при сохранении всех ее фич — это реальный вызов.
ОК>>Да, все верно, но тут речь больше не о быстроте квантовского кода (а она, я знаю, очень даже хромает) а о качестве самих стратегий (тоже могут прихрамывать). Стоит ли переписывать Джавовский аллокатор чтобы выжать пару нано-секунд если сама стратегия просирает деньги? Я это больше имел в виду.
J>если стратегия теряет деньги, то не стоит, конечно же J>С другой стороны, если ты можешь сделать быстрый фреймворк для целого класса стратегий, то дальше уже разные кванты могут предложить разное, и что-то будет зарабатывать деньги, и это будет реализуемо с разумными усилиями. Но если в команде нет толкового кванта, который способен выдать прибыльную стратегию, то такой бизнес просто обречен, с любым аллокатором.
Да как случится. Я знаю об одной группе. Написали но денег которые зарабатывали только и хватало чтобы оплатить помещение, зарплату и т.д. Инвесторам это потом надоело и дело закрылось. Но они, конечно же, тоже считали что написали мега ультра хай фриквенси трейдинг систему.
ОК>>>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло. Т>>Аналогично. Кванты просто адова тоска.
зиг>математику зато можно было бы вспомнить, тряхнуть стариной
Зиг, математика та что в книжке отличается от той что в коде. Поверь мне, ты не хочешь иметь дело с существующим квантовским кодом который они сами понять не в состоянии.
Qt — язык по вашему? Те же плюсы. Или мы тут про STL и не далее глаголим.
