Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, jazzer, Вы писали:
J>>Я подозреваю, уважаемый lpc пришел в команду сильно позже того, когда это обсуждалось, так что ты не того человека спрашиваешь. J>>То, что я слышал про UBS — там было чисто менеджерское решение (Java как раз стала самым горячим мейнстримом), технарей особо никто не спрашивал, им предоставили потом в рамках принятого решения педалить то, что у них в результате напедалилось (по описанию сильно похоже на то, что описывает lpc).
lpc>Я бы посоветовал не делать выводов из ложных предпосылок, слухов и догадок. А то ерунда обычно всякая получается... так в двух предложениях выше — все мимо тазика.
Т.е. ты пришел в команду и участвовал в принятии решения о выборе платформы при том, что ты слез с С++ лишь 2 года назад? Что-то не сходится, имхо.
А так — у вас же, даже если ты в UBS, не одна система ведь на джаве написана, может, человек мне о другой вообще рассказывал
J>>Нафига только в такой конфигураци Java — не очень понятно, так как получается в результате чисто сишное решение по сути, хоть и через одно место.
lpc>Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию.
Вы считаете наносекунды и используете рефлексию?
А если рефлексия только на стартапе, так аналогичное решение элементарно делается и на плюсах — стартап и прочие некритичные к производительности вещи вообще на чем угодно можно писать, хоть на питоне (очень удобно, кстати).
наследование такого уровня (на массивах) есть и в С++, и в Си — посмотри на архитектуру Motif, например.
Вы выкинули практически все, что есть в джаве, проще, наверное, перечислить то, что сообственно от джавы осталось.
Вы выкинули автоматическое управление памятью и сборку мусора (главное отличие джавы от плюсов) и рулите памятью вручную.
Вы выкинули все библиотеки, даже базовые стандартные — при том, что с аналогичным решением на С/С++ стандартные и околостандартные библиотеки типа буста отлично работают.
Что осталось-то от джавы?
lpc>Чем это лучше С++ я уже писал.
Ага, писал.
Проще найти программера (гы), проще отлаживать, лучше IDE.
Офигенная аргументация в пользу выбора языка при том, что он будет использоваться через одно место.
И это при том, что ни одна из этих причин никак не соотносится с требованиями бизнеса, которые в HFT сводятся к одному — выжать скорость любыми способами.
Борьба со средствами языка, для этого не предназначенного (виртуальная машина, автоматическая сборка мусора) этому безусловно способствует.
Здравствуйте, LaptevVV, Вы писали:
KP>>>Но я бы не сказал что ниша C++ как-то уменьшается. Сократилась ниша GUI-писателей, это да. RSA>>И слава богу! Уж чего чего а интерфейс действительно лучше писать на чем нибудь типа C# или даже Visual Basic. LVV>Да ладно... LVV>Qt рулит по полной!
Вот-вот, сейчас таким образом, вспомнятся все технологии и ниши, и выяснится, что никто никуда не девался
Это вообще интересное явление.
Стоит как-то сделать "шаг в сторону", и мир сразу пошатнулся. Сколько раз я, начиная делать что-то в другой области, вдруг обнаруживал, что оказываетсяяя... Помню, делал первый (и последний) проект на яве. Сел так плотно за него, с форумами, консультациями у спецов, отладкой вплоть до декомпиляции стандарных классов и выявления багов там... ушёл с головой в проект... мне тогда показалось, что ВЕСЬ МИР пишет на яве! А С++ все бросили, а мне только сейчас открылась истина. И потом много ещё раз так было. Ну не так, но похоже.
Это было 10 лет назад
Это называется не разогнаться еще больше, а придумать собственный новый велосипед. От Java у вас все равно ничего не осталось, тогда можно использовать C++ и не париться.
Здравствуйте, lpc, Вы писали:
M>>А был смысл так извращаться? Требования делали нежелательными даже minor GC? lpc>Требование — zero GC.
Писали бы уже на плюсах. Жаба тут нафиг не нужна, только мешать будет.
Здравствуйте, mik1, Вы писали:
M>Понятно, решение принималось тогда, когда нормальных сборщиков мусора не было. А потом уже динозавра было не переписать.
Ну так это вдвойне глупость — взять язык со сборкой мусора и для начала выкинуть сборку мусора, так как она тормозит. И заодно выкинуть стандартную и остальные библиотеки и прочая, после чего от языка остается какое-то невнятное Си-подобное подмножество, которое гораздо проще и прямее было бы реализовать на языке, который для этого и предназначен (С/С++).
Каша из топора, в общем. Наверняка с десяток манагеров сделали себе карьеры на этом проекте.
M>Объём торгов? Market side на многих биржах занимает несколько 10-ков гигов. Для broker side все, впрочем, много проще — хорошей персоналки хватит.
Во-первых, не факт, что нужно хранить всю market data — в ней обычно куча полей, которые данной конкретной стратегии не нужны.
Во-вторых, не факт, что ее вообще надо хранить всю за день — вполне может быть, что будет достаточно одного текущего снапшота.
В общем, все от конкретной стратегии зависит.
ЗЫ. Если хочешь снести свое сообщение — жми не "Удалить", а "Удалить как ошибочное" — тогда оно исчезнет сразу же, если не было ответов.
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, jazzer, Вы писали:
J>>Что не отменяет идиотизма изначально принятого кем-то решения вырезать гланды через об использовании этой платформы.
lpc>Ох устал я пытаться доказывать непонятно что и непонятно зачем... Но сделаю очень маленькую последнюю попытку.
Спасибо.
lpc>Дело в том, что система алготрейдинга это не один изолированный чемоданчик — это совместная работа 2-3 десятков систем, от маленьких до больших, от быстрых до не очень. Все они взаимодействуют, загружают одни и те же данные, используют одни и те же протоколы и в конце концов один и тот же messaging bus (разумеется самодельный — очень узкоспециализированный и поэтому очень эффективный, всякие tibco rv рядом не валялись). Считать наносекунды во всех (под)системах не надо и классическая java для большой половины идеально подходит.
Спасибо за объяснение.
Лично я вижу здесь некоторую инверсию приоритетов.
Все эти 2-3 десятка разных систем — это все обслуга, главное, что делает систему конкурентноспособной — это то самое наносекундное ядро и транспорт к бирже.
И именно оно имеет самый высший приоритет, и именно от него надо плясать.
А у вас получается, что вспомогательные системы типа приема/загрузки клиенстких баскетов/ордеров, репортинг, букинг и прочая фигня фактически диктуют выбор платформы для самого главного компонента.
Хотя вроде как должно быть ровно наоборот — наносекундный компонент должен быть написан на языке, исключающем левые влияния типа сборки мусора, виртуальной машины, джита и т.д, и быть максимально близким к процессору. И вместо того, чтобы выбрать язык, в котором всякой фигни нет изначально, вы выбираете язык, в котором все это есть, и последовательно со всем этим боретесь (при этом заодно повторно реализуя стандартную библиотеку).
И вот в скоростном ядре скоростной messaging очень в тему, но для связи с упомянутыми 2-3 десятками систем отлично подойдет та же tibco rv, тем более что зачастую она уже поддерживается, еще до того, как вы начали свое писать. Ибо это стандарт для среднескоростных систем. И сериализацией вопрос решается.
lpc>Но если одну половину систем писать на C++, а другую на java, то придется очень многое дублировать. Весь common layer. А это огромный гемор и огромный источник ошибок. Лучше уж с небольших извратом написать это на java и использовать как в zero GC системах так и в "обычных". Это экономит очень много сил и средств, позволяет легко ратировать людей между коммандами и многое другое.
Ты сильно преувеличиваешь насчет огромного гемора и огромного источника ошибок.
Мы вот с остальными системами (которые написаны и на плюсах, и на java, и на шарпе, и даже безумное легаси на перле) развязаны полностью, никакого common layer у нас с ними нет вообще, мы с ними общаемся по их протоколам (базы данных, CSV, tibrv, JSON и т.п.).
И никаких проблем, затраты на поддержание этого минимальны, потому что все эти системы обслуги меняются раз в сто лет все равно.
Тем более ты выше сказал, что остальные компоненты "используют одни и те же протоколы" — т.е. достаточно один раз реализовать этот общий протокол и больше проблем не знать
lpc>А в самом начале это позволило избежать крайне рискованного и непростого процесса — найма и построения с нуля комманды С++ девелоперов.
Т.е. у вас просто уже была готовая команда java-программеров и стояла задача написать быстрый (или ускорить существующий) алготрейдинг, вот его и писали силами имеющейся команды, естественно, на java, так?
lpc>А самое смешное — даже если бы пришлось писать на С++, то точно так же пришлось бы делать преаллокацию объектов, т.к. даже в плюсах new и delete совершенно не бесплатные. Поэтому реальной разницы тупо нет (единственный реальный плюс в плюсах это кастинг поинтеров, в java приходится хранить примитивы разных типов в разных массивах, но это ерунда по сравнению с другими плюсами).
О чем я и говорю. В С/С++ все эти преаллокации и прочие игры — это естественный способ работы, и под это дело не нужно переписывать стандартную библиотеку, что пришлось сделать вам. В С++ буст STL — замечательно работает "из коробки" на таких массивах.
А вы фактически реализовали Си на Java своими руками.
То, что естественно на С/С++ — извращение на Java, и наоборот.
И вы в результате решаете реализовать сишное решение, но не на естественном для этого решения языке, а на Java.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Delphi то и тот не умер. Он превратился в зомби, вокруг него летают мухи, но он тупо идёт вперёд со стеклянным взглядом. А вы уже плюсы хороните, которые во всю мутируют и обрастают неимоверным количеством либ.
Здравствуйте, __kot2, Вы писали:
lpc>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). __>а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Мне об этом сообщили так примерно в 2000-м году. Потом поработал ещё на многих проектах, и всё не кончаются.
Проблема ещё и в том, где ищете. И в США полно городов где негусто с C++, или выбор ограничен, например, преобладающий спрос на C++ в области High Frequency Trading.
Потому, на всё забил, и приложив усилия переместился туда, где такой работы больше и она разнообразнее, а именно в Силиконовую Долину или San Francisco Bay Area.
Кстати, применимость C++ программиста резко возрастает, если он знает ещё что-то, скажем Java. И, скажем, зная Java, знает платформу Android. Тогда получается куча интересных вариантов, это просто для примера. Столько идей вокруг, какую-бы мобильную кракозябру сочинить, а надо UI и с Internet интегрировать. Это просто пример. Хорошо продаются те, у кого понятия про Network Security + C++, embedded + C++, комбинаций не счесть числа.
Здравствуйте, jazzer, Вы писали:
J>Что не отменяет идиотизма изначально принятого кем-то решения вырезать гланды через об использовании этой платформы.
Ох устал я пытаться доказывать непонятно что и непонятно зачем... Но сделаю очень маленькую последнюю попытку.
Дело в том, что система алготрейдинга это не один изолированный чемоданчик — это совместная работа 2-3 десятков систем, от маленьких до больших, от быстрых до не очень. Все они взаимодействуют, загружают одни и те же данные, используют одни и те же протоколы и в конце концов один и тот же messaging bus (разумеется самодельный — очень узкоспециализированный и поэтому очень эффективный, всякие tibco rv рядом не валялись). Считать наносекунды во всех (под)системах не надо и классическая java для большой половины идеально подходит. Но если одну половину систем писать на C++, а другую на java, то придется очень многое дублировать. Весь common layer. А это огромный гемор и огромный источник ошибок. Лучше уж с небольших извратом написать это на java и использовать как в zero GC системах так и в "обычных". Это экономит очень много сил и средств, позволяет легко ратировать людей между коммандами и многое другое. А в самом начале это позволило избежать крайне рискованного и непростого процесса — найма и построения с нуля комманды С++ девелоперов.
А самое смешное — даже если бы пришлось писать на С++, то точно так же пришлось бы делать преаллокацию объектов, т.к. даже в плюсах new и delete совершенно не бесплатные. Поэтому реальной разницы тупо нет (единственный реальный плюс в плюсах это кастинг поинтеров, в java приходится хранить примитивы разных типов в разных массивах, но это ерунда по сравнению с другими плюсами).
Здравствуйте, RSATom, Вы писали:
KP>>Но я бы не сказал что ниша C++ как-то уменьшается. Сократилась ниша GUI-писателей, это да. RSA>И слава богу! Уж чего чего а интерфейс действительно лучше писать на чем нибудь типа C# или даже Visual Basic.
Да ладно...
Qt рулит по полной!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, volodya777, Вы писали:
V>Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
V>есть отрасли где традиционно используется C++, в силу требований по скорости и минималистичному управлению ресурсами (т.е. там где Java и прочие вирт.машины не катят) V>-трейдинговые платформы V>-ембеддед V>-геймдев V>-графика и CAD V>-разработка ядра СУБД V>-системное программирование (правда там больше C)
Еще в поисковики, rtb, системы виртуализации и т.п.
И вообще кажется количество работы на C++ в последнее время только растет, только оно все серверное. Новый GUI конечно уже очень давно не пишут, только Legacy.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Лично я знаю только о случаях перехода на Java (сам вынужденно перешел). Но я бы не сказал что ниша C++ как-то уменьшается. Сократилась ниша GUI-писателей, это да. Ну а системные приложения никуда ни делись.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
есть отрасли где традиционно используется C++, в силу требований по скорости и минималистичному управлению ресурсами (т.е. там где Java и прочие вирт.машины не катят)
-трейдинговые платформы
-ембеддед
-геймдев
-графика и CAD
-разработка ядра СУБД
-системное программирование (правда там больше C)
Здравствуйте, lpc, Вы писали:
V>>-трейдинговые платформы
lpc>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается).
А потом приходят спецы по плюсам и увеличивают производительность на порядок
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
не часто, но регулярно встречаю коллег (.Net с опытом 5+) которые "вдруг" решают начинать учить С++.
аргументы на вопрос "почему?": от "от С++ никуда не деться" до "я понял что С# — фуфел".
вот. тоже тема к размышлениям.
Здравствуйте, lpc, Вы писали:
lpc>Ха-ха, а мы и есть спецы по плюсам, которых попросили сделать на java так же быстро как на плюсах Получилось.
Мне вот еще интересно, перед тем, как делать zero-GC какое-нибудь профилирование проводилось? Дело в том, что специалисты по С++ обычно не очень хорошо понимают, как работает мусоросборник, порой такой фигни от них наслушаешься, и сразу zero-GC да.
lpc>>>да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз Т>>Это ты про какие? Т>>Нормальная плюсовая IDE это вижуалка + ассист.
lpc>Про нее любимую. В простом проекте то конечно работает, а если навернуть чуток макросов и шаблонов то капец.
А не нужны эти макросы и шаблоны в нормальном коде. (Эти слова не следует понимать что нужно отказаться от СТЛ — их следует понимать что не надо писать в стиле "меня Александреску в полнолуние укусил.")
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, Олег К., Вы писали:
ОК>>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло. Т>Аналогично. Кванты просто адова тоска.
математику зато можно было бы вспомнить, тряхнуть стариной
Здравствуйте, Почемучкин, Вы писали:
П>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Программисту все равно на каком языке писать... привязка к языку говорит о низкой квалификации...
П>Неправда. Во-первых так думают часто те, кто пишет исключительно на Си-подобных языках (то есть C/C++/C#/Java/JavaScript) П>Напишите что-нибудь на Fortran, Cobol, Smalltalk, Forth — посмотрю как лихо Вы сразу и лихо начнете на них писать. Да даже на том же Pascal/Delphi (обычно сишники начинают ныть, что там все убого и не так — а секрет в том, что они попросту не разобрались и не изучили язык и его возможности, а ткаже не въехали в философию языка — что очень важно для интуитивной и продуктивной работы). П>Во-вторых — у каждого языка (и даже бывает, — среды/компилятора) свои библиотеки, которые нужно изучить, чтобы хотя-бы знать чем сможешь оперировать. А это — довольно много информации. Больше, чем просто язык. П>Так что не надо приуменьшать сложности.
Вы просто не умеете работать с информацией... Любой язык отличается синтаксисом и немного семантикой. Базовые алгоритмические принципы едины везде... везде есть условные переменные и массивы, везде есть условные операторы циклов и условий, все современные языки имеют структуры. Все библиотеки завязаны на платформенных особенностях — практически везде есть память, везде где есть многопоточность — есть объекты синхронизации,.. файлы, сокеты и другие объекты системы, к которым можно получить доступ посредством языка, за исключением случаев накладываемых VM.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, licedey, Вы писали:
L>>Простите, а на чем пишут бэк-энд мэйн-стрима? Гугл, бинг, фэйсбук, яндекс, касперски, паралелс и прочее...Понимаю не все там работают, однако же.
KP>Qt у обоих. Про остальных не знаю
Я бы посмеялся, но вы же уважаемый человек Qt — язык по вашему? Те же плюсы. Или мы тут про STL и не далее глаголим.
Здравствуйте, RSATom, Вы писали:
RSA>Здравствуйте, mik1, Вы писали:
M>>Есть случаи, когда нет железки, соответствующей имющемуся софту и требованиям. Например, во сколько вам обойдется железка со 128 гигами оперативки и как быстро вы ее достанете? (это не самый страшный случай).
RSA>Пограничные случаи всегда были и всегда будут, я же говорю о mainstream'е
В mainstream — конечно Вот поэтому оптимизаторы крутятся в основном в финансах.
A>Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
Хех. Я как раз недавно на практике замерял. Ethernet-кабель длиной 30 метров на фреймах длиной 128 байт payload (+издержки самого ethernet) идут на 1 мкс длиннее, чем с кабелем 0.3 метра. Так что, чувакам стенку-то пробурить бы
Здравствуйте, Олег К., Вы писали:
lpc>>Решение получается далеко не сишное. Никто не запрещает использовать наследование и даже (сюрприз!) рефлексию. Чем это лучше С++ я уже писал. ОК>Чувак, хоть я и не видел вашего кода, но могу сказать с уверенностью что получился очередной говнокод.
Мальчик, шел бы ты лесом со своей юнешеской самоуверенностью да не возвращался. Реально утомил своим негативом.
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... RSA>Да нет, я серьезно, есть чуство что пора профиль менять (точнее что его нужно было менять еще "вчера") — а на что менять придумать не могу, т.к. хочется сложных (и как следствие интересных)задач, а вокруг только "сайтики" да "кнопочки на формах"...
А вот почему это "сайтики" стали простыми задачами? Приложения мигрируют в Web, тренд совершенно очевидный. Сделать "сайтик" с динамичным интерфейсом на JavaScript с кучей AJAX запросов — совсем не тривиальная задачка.
Тренд ухода с C++ есть, программеров надо будет меньше, но задачи все равно есть и зарплаты неплохие
KP>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел). Но я бы не сказал что ниша C++ как-то уменьшается. Сократилась ниша GUI-писателей, это да. Ну а системные приложения никуда ни делись.
Тоже идет сокращение. Для новых проектов все чаще выбираются альтернативы. C++ это всегда "круто" но при этом почти всегда долго и дорого. У нас в конторе был положительный опыт миграции с C++ на (осторожно, кощунство) PHP и Node.js. Мигрировал не весь продукт, а части, но тем не менее.
Такое ощущение, что тренд идет в сторону JavaScript. Qt5 продолжает движение в эту сторону, роль C++ в Qt снижается. На серверах начинается пришествие Node.js (Яндекс активно мигрирует на него со своим БЭМ велосипедом). Даже Windows 8 предлагает писать проги на JS (http://msdn.microsoft.com/en-us/library/windows/apps/br211385.aspx). А то, что десктопные проги мигрируют в веб — это очевидно.
Я не говорю что JS (или любой другой язык) вытеснит C++, просто тренд C++ однозначно направлен вниз. Тренд JS направлен вверх
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, Олег К., Вы писали:
ОК>>Кстати... Вот ты затронул тут чисто технические аспекты. А что там у вас на счет бизнес аспектов? Что с самими стратегиями? ОК>>Успех это ведь не только "как можно быстрее передать данные по сети."
lpc>Мы номер 1 в алготрейдинге практически по всем параметрам (согласно Thomson Reuters Extel Survey и ряду других).
UBS?
В UBS, помнится, клепали подобное извращение на джаве, в результате от джавы одно название осталось, а то, что получилось, по уровню языка было чуть ли не ниже Си (рукопашная возня с байтами в буферах).
Здравствуйте, sysenter, Вы писали:
S>Зависит от области, если интересует конкретно веб то C# это реально кроссплатформенная вещь, если писать бизнес логику C# так же полностью кроссплатформенен.
Только на нем ничего кроссплатформенного не пишут. А так, да, он очень кроссплатформенен.
Здравствуйте, kaa.python, Вы писали:
KP>Только на нем ничего кроссплатформенного не пишут. А так, да, он очень кроссплатформенен.
Глядя на наш проект на C# который будет крутиться/крутится под Linux в свою очередь хочу заметить, что и на Java тоже ничего кросс платформенного не пишут т.к. это только принтер/мфу-онли приблуда))
Здравствуйте, sysenter, Вы писали:
S>Глядя на наш проект на C# который будет крутиться/крутится под Linux в свою очередь хочу заметить, что и на Java тоже ничего кросс платформенного не пишут т.к. это только принтер/мфу-онли приблуда))
Хиханьки хахоньками, но ты же понимаешь что на C# кроссплатформенные проекты по пальцам пересчитать можно. Я не вдавался в детали почему, но полагаю что причин на это достаточно.
Здравствуйте, Abalak, Вы писали:
A>Далеко не все части, то что связано с непосредственным исполнением все еще во власти плюсов и навряд ли куда-то двинется в обозримом будущем.
Движется и ещё как движется. 5-7 лет назад C++ действительно был "наше всё" в области exchange connectivity, то сейчас он движется в сторону определенной ниши. Крупные игроки, у кого есть деньги на уход с С++, двигают на FPGA — никакой С++ не сравнится в плане производительности с готовой железкой. В тоже время мелким игрокам, работающим с брокерами особо и не нужна головная боль с выпиливанием С++ приложений — им Matlab, C# и Java за глаза хватает. А за С++ остаются средние игроки с уже готовой инфраструктурой, которых борьба за тики интересует, но не настолько, чтобы всё переписать.
M>От меня хотят, чтобы условный гиг данных перемололся за 30 секунд, а не за 3 часа. Вот до 2-3 минут (например) можно алгоритмами пилить, а дальше да — начинается охота за константой. Там уже начинаю изучать, где что ненужное вызывается, а где более быстрые аналоги дернуть можно.
Так это, простите, халява — для такого инструментов создано — море разливанное. Банальнейший профайлер сразу покажет, где затыки, после чего самым что ни на есть простым "методом пристального взгляда" можно сообразить, что к чему. Тем более это не собеседования и гугл с книжками не запрещен.
Здравствуйте, Олег К., Вы писали:
A>>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
ОК>Если собираешься оставаться в финансовой индустрии, то не советую. На плюсах нового мало что пишут. В основном джава и шарп. И на плюсах работы существенно меньше и в основном старые проекты. Говорю как плюсовик и сам хочу свалить чисто на шарп хоть и люблю С++.
Ну шарп-то не забуду, слишком много времени уже на нем. А связка плюсы/шарп мне видится вполне боевой.
ОК>Так ТС прав в своем наблюдении. По крайней мере в НЙ.
За весь НЙ не скажу, но у пары очень крупных игроков плюсы никуда не деваются. Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). __>>а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
lpc>P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
Посоветуй начальству написать свой язык программирования специально заточенный для ваших задач. Уж вы-то точно уделаете Джаву. Дальше дело останется совсем за малым. Написать свою ОСь. Ну и сделать свое железо заодно.
Здравствуйте, RSATom, Вы писали:
RSA>Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... RSA>Да нет, я серьезно, есть чуство что пора профиль менять (точнее что его нужно было менять еще "вчера") — а на что менять придумать не могу, т.к. хочется сложных (и как следствие интересных)задач, а вокруг только "сайтики" да "кнопочки на формах"...
Если хочется надуманных сложностей, можно начать делать сайтики на С++.
Здравствуйте, lpc, Вы писали:
M>>А был смысл так извращаться? Требования делали нежелательными даже minor GC?
lpc>Требование — zero GC.
Очень интересно. Значит пулы примитивов. Хорошо, строим на них аналоги malloc/free. Остается вопрос о том, как построен менеджер памяти и как ведутся списки (или другие структуры?) свободных блоков. Впрочем, если делать линейный поиск, то можно и без списков обойтись
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
Вот я про что и писал — все можно сделать на Java (мне язык сам очень нравится, я на нем несколько проектов сделал, в т.ч. под Андроид), но тогда от большинства плюшек оной Java придется отказаться. Вот и зачем мне это счастье, чтоб сложнее было disasm смотреть? Спасибо, кушайте сами.
ОК>>Кстати... Вот ты затронул тут чисто технические аспекты. А что там у вас на счет бизнес аспектов? Что с самими стратегиями? ОК>>Успех это ведь не только "как можно быстрее передать данные по сети."
lpc>Мы номер 1 в алготрейдинге практически по всем параметрам (согласно Thomson Reuters Extel Survey и ряду других).
Смешно читать такое. Сейчас каждая шарашкина контора является номером один согласно какому-нибудь исследованию, опросу, журналу или сайту.
Ну и еще все поголовно сами объявляют себя номером один.
ПМ>>Мне вот еще интересно, перед тем, как делать zero-GC какое-нибудь профилирование проводилось? Дело в том, что специалисты по С++ обычно не очень хорошо понимают, как работает мусоросборник, порой такой фигни от них наслушаешься, и сразу zero-GC да.
lpc>О боже... ты серьезно считаешь что топовый инвест банк, который зарабатывает на алготрейдинге миллионы и вкладывает огромные деньги в свои технологии, это куча идиотов которые не догадались проверить а правда ли будет быстрей?
Здравствуйте, SkyDance, Вы писали:
ОК>>А если несколько клиентов "вещают в сети?"
SD>К таким конфигурациям даже сами понятия latency (и тем более realtime, с обязательным жестким ограничением на время ответа) неприменимы в общепринятом смысле А главное, что это у вас такое, древний ethernet с коаксиальным кабелем?
Ну скажешь тоже.
Вот у тебя в сетке несколько фидов с разных бирж, все мультикастят — все равно нет latency?
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). __>>а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
lpc>P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
Для тех кто в танке, можно объяснить на пальцах что же вы там все-таки набангалорили?
Я не понимаю. Как можно преаллокейтать все объекты когда их количество неизвестно до рантайма ровно также как и не известно какие "пути будут следоваться в коде." И всех этих объектов, мягко говоря, дохрена.
Или вы написали свой аллокатор? В таком случае чем он лучше сановского? И что происходит с объектами которые больше не нужны? Где берется память когда закончилась существующая?
Здравствуйте, trophim, Вы писали:
T>Ха, вообще поразительная реакция аудитории: да вы ваще отключать то его умеете? Вот я то отключу, я д'Артаньян, а вы там в банке своем ...расы криворукие. Вот, то есть был профи, а как пришел в банк и на тебе — руки в зюзю скривились.
Реакция аудитории, с сожалению, была весьма предсказуема... я хотел было поделиться интересным подходом использования джавы а нарвался на традиционное "такое невозможно, да вы дураки, вам вообще это не надо". Но с другой стороны это радует, конкурентов на рынке все еще мало, общество еще не созрело
ОК>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем.
lpc>Не тяжело жить с мыслью что вокруг одни идиоты?
Не тяжело. Уж точно не идиоты стояли во главе (ну и вниз по цепочке) в Bear Stearns, Lehman Brothers, Washington Mutual и что там еще.
ОК>>С опережением ты поспешил. Я это и не собирался спрашивать. Спрошу другое. Допустим вы выжали целую секунду с вашим решением. Теперь следуя этой логике имеет смысл оптимизировать драйвера и/или планировщик Линукса (Линукс чисто как пример). Вы не собираетесь там этим в ближайшее время заняться?
lpc>Настройками линукса, биоса и сетевого оборудования занимается отдельная команда. Там свои гики и я не совсем в теме.
Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
lpc>P.S.: Планировшик к счастью оптимизировать не надо, т.к. ему особенно заниматься нечем — на каждый CPU биндится ровно 1 поток.
ОК>>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем. lpc>>Не тяжело жить с мыслью что вокруг одни идиоты? Т>Его греет мысль что он сам — Д'Артаньян.
Какой же я Д'Артаньян? Д'Артаньяны говорят "давай, давай сделаем, давай напишем, все будет классно!" Я же наоборот понимаю что они удаляли гланды через одно место, как тут уже сказали. Не нужно было этого делать.
А вот ты не только трололо, но еще и школоло. А лпц и остальные лица у него на работе — сто процентные Дон Кихоты.
Здравствуйте lpc, Вы писали:
lpc>Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
Вот обьясни- если в ядро в сетевую карту окно прорубили (из-за скор отклика), об'екты занимают больше места в памяти, чем нативные, GC отключен- зачем там Java, это какая-то забава? Плюс наверняка есть JNI и связанные с ним накладные расходы.
Здравствуйте, lpc, Вы писали:
lpc>я хотел было поделиться интересным подходом использования джавы
При этом не ответил ни на один технический вопрос, зато повыпендривался на отличненько.
lpc>а нарвался на традиционное "такое невозможно, да вы дураки, вам вообще это не надо". Но с другой стороны это радует, конкурентов на рынке все еще мало,
Я работаю с подобными поделками (zero-GC, single-thread), весь этот цирк и лубок мне известен на собсвенном опыте. К сожалению дурь в бошках программистов на С++, переквалифицировавшихся на джаву крепка.
lpc>общество еще не созрело
Но дурь общества — еще не столь. Это вселяет надежду.
Здравствуйте, anonymous, Вы писали:
Т>>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>>Развидеть невозможно!
A>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации.
Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
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. Я же говорил о том чтобы эти банки меняли сами код ядра и драйверов.
ОК>>Что-то я ни разу не слышал чтобы JPM, Credit Swiss, UBS, Deutsche Bank, Barclay's и т.д. меняли код ядра и писали свои драйвера. Не подкинешь ссылку ни их contributions в мире опенсорса?
SD>Это типа сарказм такой, или взаправдашний вопрос?!
Ты что-то уходишь в сторону и почему-то вырезал средний параграф.
ОК>>На дайсе: solarflare — выдало два !!! результата. openonload — ноль. Что это за фигня, каюсь, я не знаю но звучит как third party product. Я же говорил о том чтобы эти банки меняли сами код ядра и драйверов.
SD>Ты сейчас делаешь мне очень смешно. Это плохо, потому что я сижу в офисе, и на меня уже начинают коситься остальные. Мне трудно сделать умное лицо и вид, будто я продолжаю копать код красно-черного дерева, которое заюзали для очереди приоритетов без дОлжного понимания, _КАКИЕ_ данные будут в эту очередь попадать. Вероятнее всего, дерево вообще надобно выкинуть, и заменить на, скорее всего, скиплист или кастомную структуру (не придумал пока, какую).
Ты мне тоже делаешь смешно. Особенно в свете того что ты так и не привел ни одного конкретного примера на счет программистов банков.
SD>onload, и его ef_vi интерфейс — это такая специальная дырка, которая прокидывает мне в память юзерского процесса tx, rx и events rings виртуализированной сетевой карты. Накукуй мне все эти linux kernel'ы сдались с их громоздкими сокетами, если я спокойно кладу zero-copy frames... и, кстати, про разработку банками железяк — гугли про заказные чипы тоже есть, но нет уверенности, что с ними будет сколь-нибудь быстрее, а вот что геморройнее — это наверняка. Более того, у тех же SolarFlare уже все украдено до нас, и даже гнездо программируемого чипа предусмотрено сразу за PHY сетевухи.
Ну не сомневаюсь что есть какие-нибудь решения но только они не используются на волл стрите. Иначе почему ты не прокомментировал что на солар флэр выдало два результата?
"про разработку банками железяк — гугли про заказные чипы " Так это разработка самими банками железяк или все-таки заказ у тех кто специализируется в этой области?
SD>А еще есть забавная сетевуха с Linux'ом на борту (Killer зовется), жаль, не удалось ее попробовать. Начальник сначала с серьезным видом кивал, мол, да, надо бы глянуть, но потом глупо заржал и сказал, что провести геймерскую сетевуху по бухгалтерии у него рука не поднимется, и вообще засмеют.
Опять вода. Ты можешь привести мне конкретные примеры что программисты банков программируют в kernel mode? А не какие-то заказы на стороне и существующие решения.
человек имеет аналогичное мнение об одной из этих финансовых компаний. Т>Ничо что там про других идиотов? По ссылке мнение про разработку а тут речь о людях, принимающих решения.
Я тебе о том, что идиоты и *удаки старающиеся урвать кусок на ходятся на всех уровнях карьерной лестницы.
ОК>Что значит зачем? Я написал что программисты в этих банках залезут скоро-таки в режим ядра. Ты мне на это ответил что уже давно залезли. Я тебя попросил привести примеры того что делают банковские программисты в режиме ядра и сейчас ты возмущаешься "зачем?"
Окей, раз сразу не понимаешь — давай подробнее.
Сначала, до SolarFlare и их "дырок" в железки, приходилось брать драйвера сетевых карт и их допиливать до требуемой кондиции (в первую очередь — проковыривать "дырки" для обхода всего в ядре). Нынче это не требуется, т.к. такие "дырки" делают, что называется, серийно. Промышленным производством. Так понятнее?
ОК>Смотри выделенное. То есть получается что те же самые сокеты.
Я же не просто так ef_vi упомянул. Научись читать, что тебе пишут.
ОК>Я не совсем понял как ты используешь железяку напрямую и где ты ее используешь (ядро или юзермод). Считать кадры с железяки это одно но есть еще TCP/IP stack, нужно собрать полученные данные в правильной последовательности, запросить неполученные сегменты и т.д. и т.п. Работы поболее чем просто считать данные с железяки через, возможно, какой-то другой интерфейс в юзермоде.
Не далее чем пару сообщений назад я про все это писал
Кстати, openOnload и есть модифицированный linux TCP/IP stack, работающий полностью в usermode.
ОК>Уж не знаю где ты работаешь, но я ни разу не слышал чтобы программисты в банках лезли ниже сокетов.
"О сколько нам открытий чудных" (С)
Я вот тоже не знаю, чем депутаты занимаются. Они тоже "ниже сокетов" лезть не должны. А их, то в одних сокетах находят, то в других
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Вы просто не умеете работать с информацией... Любой язык отличается синтаксисом и немного семантикой. Базовые алгоритмические принципы едины везде... везде есть условные переменные и массивы, везде есть условные операторы циклов и условий, все современные языки имеют структуры. Все библиотеки завязаны на платформенных особенностях — практически везде есть память, везде где есть многопоточность — есть объекты синхронизации,.. файлы, сокеты и другие объекты системы, к которым можно получить доступ посредством языка, за исключением случаев накладываемых VM.
Вы прямо сделали мне больно, базовые алгоритмические принципе едины везде — только вот почему так мучительно больно иногда (хотя и приятно) писать на хаскеле с эрлангом после десяти лет С++ с Java?
Проблема не в синтаксисе, и не в семантике. Проблема с парадигме.
Процедурное программирование, логическое программирование, объектно-ориентированое программирование, аспектно-ориентированное программирование, функционально программирование, метопрограммирвоание — любой язык навязывает определенную парадигму, и сменить ее не очень просто — это не синтаксис и не семантика, зачастую — алгоритмы которые были плохи в предыдушей парадигме становятся хороши в новой и т.п.
Да блин, да просто любой язык с иммутабельными данными может местами взорвать могз на совершенно ровном месте.
Здравствуйте, Почемучкин, Вы писали:
П>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Вы просто не умеете работать с информацией... Любой язык отличается синтаксисом и немного семантикой. Базовые алгоритмические принципы едины везде... везде есть условные переменные и массивы, везде есть условные операторы циклов и условий, все современные языки имеют структуры. Все библиотеки завязаны на платформенных особенностях — практически везде есть память, везде где есть многопоточность — есть объекты синхронизации,.. файлы, сокеты и другие объекты системы, к которым можно получить доступ посредством языка, за исключением случаев накладываемых VM.
П>Ага, вот об этом я и говорю — особенностей языка такой универсал использовать не будет. Будет пользоваться только тем, что безопасно совпадает с возможностями его основного языка (например C++).
В который раз неудачное сравнение с с++.
Общего у C++ с C# и Java столько же сколько у Java и JavaScript — только скобочки.
Ну, еще название у кого-то похоже.
И как раз С++ может служить примером языка на который с напрыга за месяцок не пересядешь.
Тут обычно несколько лет нужно для начального уровня вменяемости.
Хотя, нужно отметить, многие этим особо не заморачиваются
Здравствуйте, mtnl, Вы писали:
M>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Программисту все равно на каком языке писать... привязка к языку говорит о низкой квалификации...
M>Это если есть бесконечное количество времени и ему пофиг на качество создаваемого продукта.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Да нет, я серьезно, есть чуство что пора профиль менять (точнее что его нужно было менять еще "вчера") — а на что менять придумать не могу, т.к. хочется сложных (и как следствие интересных)задач, а вокруг только "сайтики" да "кнопочки на формах"...
Здравствуйте, Handie, Вы писали:
RSA>>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... RSA>>Да нет, я серьезно, есть чуство что пора профиль менять (точнее что его нужно было менять еще "вчера") — а на что менять придумать не могу, т.к. хочется сложных (и как следствие интересных)задач, а вокруг только "сайтики" да "кнопочки на формах"...
H>А вот почему это "сайтики" стали простыми задачами? Приложения мигрируют в Web, тренд совершенно очевидный. Сделать "сайтик" с динамичным интерфейсом на JavaScript с кучей AJAX запросов — совсем не тривиальная задачка.
Извиняюсь если кого то обидел, под "сайтиками" я имел в виду "Берем готовую CMS, чуть меняем дизайн — готово!" В этом плане думаю показателен gmail и google docs — реально интересные проекты (с точки зрения сложности), но ктож меня туда возьмет? — да и переезжать особо не хочется... а с/с++ на удаленке — сомнительно что много желающих будет заполучить такого работника...
Здравствуйте, kaa.python, Вы писали:
KP>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел).
Да, тоже уже думал об этом варианте.
KP>Но я бы не сказал что ниша C++ как-то уменьшается. Сократилась ниша GUI-писателей, это да.
И слава богу! Уж чего чего а интерфейс действительно лучше писать на чем нибудь типа C# или даже Visual Basic.
Здравствуйте, kaa.python, Вы писали:
KP>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел).
А вот кстати вопрос, а как получилось перескочить на Java? Работодатели же косо смотрят на людей без опыта?
Здравствуйте, RSATom, Вы писали:
RSA>А вот кстати вопрос, а как получилось перескочить на Java? Работодатели же косо смотрят на людей без опыта?
Вышел на новое место работы и мне говорят что теперь я пишу на Java. Мне подумалось что это не достаточно весткая причина разрывать контракт, особенно с учетом того, что мои любимые сети никуда от меня не делись
Здравствуйте, kaa.python, Вы писали:
KP>Вышел на новое место работы и мне говорят что теперь я пишу на Java. Мне подумалось что это не достаточно весткая причина разрывать контракт, особенно с учетом того, что мои любимые сети никуда от меня не делись
Здравствуйте, RSATom, Вы писали:
RSA>Здравствуйте, kaa.python, Вы писали:
KP>>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел). RSA>А вот кстати вопрос, а как получилось перескочить на Java? Работодатели же косо смотрят на людей без опыта?
Работодатель может начать проект на другом языке. В случае перетаскивания своих разработчиков, смотрят не на знание языка, а на успехи в прошлых проектах. Язык подучивается по ходу дела.
Здравствуйте, RSATom, Вы писали: RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
меня на сайтик посадили
Здравствуйте, RSATom, Вы писали:
KP>>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел). RSA>А вот кстати вопрос, а как получилось перескочить на Java? Работодатели же косо смотрят на людей без опыта?
Традиционно на джаву с опытом С++ берут туда, где нужна "Core Java", а не "Enterprise Java". Пример таких мест — инвест. банки.
Здравствуйте, lpc, Вы писали: lpc>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается).
а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... RSA>Да нет, я серьезно, есть чуство что пора профиль менять (точнее что его нужно было менять еще "вчера") — а на что менять придумать не могу, т.к. хочется сложных (и как следствие интересных)задач, а вокруг только "сайтики" да "кнопочки на формах"...
Может тогда лучше место жительства сменить? Поближе к сложным и интересным задачам, например к финансам.
Здравствуйте, SkyDance, Вы писали:
A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
SD>Примерно так SD>Потом прихожу я, и дожимаю остатки. А там еще порядок может спрятаться
А что тогда не по 150 баксов в час гребешь? Или уже гребешь?
ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
A>А что тогда не по 150 баксов в час гребешь? Или уже гребешь?
Не гребу Разве что в тысячах и в год.
Чтобы было как ты пишешь, это, во-первых, знакомства в нужных местах. Во-вторых — аврально-дебильный режим работы "заплатим любые деньги, только СДЕЛАЙ ПРЯМО СЕЙЧАС, а еще лучше вчера".
Ну и, в Австралии есть прямой резон не зарабатывать больше 150к в год, там дальше начинается совершенный коммунизм и полная налоговая обдираловка. "Оптимизировать" что-то боязно, при виде коллеги, которого налоговая на 20 килобаксов раскрутила (неверно посчитал доходы, полученные при продаже стартапа, где он имел долю).
A>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
ЗЫ: однако, последние 2 проекта на голом С, без ++, есичо.
Ужасно неудобно (особенно без template'ов), но многократно проще контролировать, что там в бинарнике получится. Не хочу холивор C vs ++ поднимать, т.к. аргументы там все банальные — да, C++ может так же быстро работать, но если чего-то не так, то быстрее разобраться в С, чем с наворотах с ++. А уж всякая фигня типа "виртуальный вызов медленный" — это натурально фигня.
Здравствуйте, AlexanderVX, Вы писали:
AVX>Кстати, применимость C++ программиста резко возрастает, если он знает ещё что-то, скажем Java. И, скажем, зная Java, знает платформу Android. Тогда получается куча интересных вариантов, это просто для примера. Столько идей вокруг, какую-бы мобильную кракозябру сочинить, а надо UI и с Internet интегрировать. Это просто пример. Хорошо продаются те, у кого понятия про Network Security + C++, embedded + C++, комбинаций не счесть числа.
Ну с побочными скиллами и так проблем нет, да и с незнакомыми вещами разобраться не проблема, но продать их можно только в крупных городах(а мигрировать не хочется) или по удаленке (куда я и пытаюсь последнее время двигаться, но пока без особого успеха) да и не совсем понятно какие из скиллов прокачивать...
AVX>Кстати, применимость C++ программиста резко возрастает, если он знает ещё что-то, скажем Java. И, скажем, зная Java, знает платформу Android. Тогда >получается куча интересных вариантов, это просто для примера. Столько идей вокруг, какую-бы мобильную кракозябру сочинить, а надо UI и с Internet >интегрировать. Это просто пример. Хорошо продаются те, у кого понятия про Network Security + C++, embedded + C++, комбинаций не счесть числа.
это точно
я исторически с++ник, последние 2-3 года пишу на Java но если подвернется плюсовый проект то не откажусь — вроде не забыл еще
Здравствуйте, volodya777, Вы писали:
V>я исторически с++ник, последние 2-3 года пишу на Java но если подвернется плюсовый проект то не откажусь — вроде не забыл еще
а вот тогда вопрос, что именно пишется на Java? уж точно не desktop приложения — что тогда? серверная логика?
On 06.06.2012 11:02, RSATom wrote:
> V>я исторически с++ник, последние 2-3 года пишу на Java но если > подвернется плюсовый проект то не откажусь — вроде не забыл еще > > а вот тогда вопрос, что именно пишется на Java? уж точно не desktop > приложения — что тогда? серверная логика?
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Вы просто судите по бизнес проектам видимо. Там java и С# рулит. Однако, что то "пониже" — будет на плюсах ништяк. Я вот например удаленно пишу антивирусник за 5К.
С++ вечен, только если ситуация не появится чтобы его задавить.
Здравствуйте, TimurSPB, Вы писали:
TSP>Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... TSP>Delphi то и тот не умер. Он превратился в зомби, вокруг него летают мухи, но он тупо идёт вперёд со стеклянным взглядом. А вы уже плюсы хороните, которые во всю мутируют и обрастают неимоверным количеством либ.
Слишком категорично про Делфи. Где ж он умер то? Помоему один инструмент нативность поддерживать.
Здравствуйте, hrensgory, Вы писали:
>> а вот тогда вопрос, что именно пишется на Java? уж точно не desktop >> приложения — что тогда? серверная логика?
H>В основном да. Причём как с использованием Enterprise Edition H>(http://docs.oracle.com/javaee/6/tutorial/doc/), так и самостоятельные H>приложения на core java
Хорошо, допустим я решил двигаться в сторону Java. С чего начать? Я не про "что почитать", а про "что попытаться сделать" (в рассчете на то, что в процессе создания этого самого "что", можно будет ознакомится с ключевыми моментами разработки на Java)?
Здравствуйте, RSATom, Вы писали: RSA>Хорошо, допустим я решил двигаться в сторону Java. С чего начать? Я не про "что почитать", а про "что попытаться сделать" (в рассчете на то, что в процессе создания этого самого "что", можно будет ознакомится с ключевыми моментами разработки на Java)?
Кстати, вот например всякие "облачные" технологии типа Google App Engine и Amazon Web Services — насколько они востребованы? Там же тоже Ява...
Здравствуйте, kaa.python, Вы писали: KP>Например у нас сейчас на Java практически вся логика на принтерах написана, кроме самых низкоуровневых вещей.
хм... любопытно...
Здравствуйте, oncer, Вы писали:
O>Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
O>не часто, но регулярно встречаю коллег (.Net с опытом 5+) которые "вдруг" решают начинать учить С++. O>аргументы на вопрос "почему?": от "от С++ никуда не деться" до "я понял что С# — фуфел". O>вот. тоже тема к размышлениям.
С# хорошая штука, но думаю проблема в том что его пытаются запихать туда где ему не место. Например работу с сетью гораздо разумней делать на С++, а интерфейс лучше делать на C# — вопрос правильного применения инструмента...
Здравствуйте, RSATom, Вы писали:
RSA>С# хорошая штука, но думаю проблема в том что его пытаются запихать туда где ему не место. Например работу с сетью гораздо разумней делать на С++, а интерфейс лучше делать на C# — вопрос правильного применения инструмента...
С++ читать как С++/С
Здравствуйте, SkyDance, Вы писали:
A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
SD>Примерно так SD>Потом прихожу я, и дожимаю остатки. А там еще порядок может спрятаться
RSA>Хорошо, допустим я решил двигаться в сторону Java. С чего начать? Я не про "что почитать", а про "что попытаться сделать" (в рассчете на то, что в процессе создания этого самого "что", можно будет ознакомится с ключевыми моментами разработки на Java)?
И в нагрузку вопрос — насколько реально после C++ с реверсингом устроиться на яву без опыта в ней? При этом максимум на что хватит времени — какие-нибудь тетрисообразия на андроидный мобильник намолотить чтобы хоть что-то было предъявить, или такое вообще не в тему, лучше книжек в это время почитать?
Здравствуйте, sysenter, Вы писали:
S>После твоих слов о том, что в принтерах самсунг используется Java резко расхотелось покупать принтеры этой марки))
Ну именно что в принтерах у нас только Си, но в МФУ уже полно Java (да, у конкурентов аналогично, иначе индусов не привлечь ).
S>p.s. Что разве моно нельзя собрать под твой принтер?
Может и можно, но я сомневаюсь, у нас там и MIPS-ы и ARM-ы есть. Да и зачем себе головную боль создавать? C# — это реально Венда-онли фуфел
Здравствуйте, kaa.python, Вы писали:
KP>Может и можно, но но я сомневаюсь, у нас там и MIPS-ы и ARM-ы есть. Да и зачем себе головную боль создавать? C# — это реально Венда-онли фуфел
Зависит от области, если интересует конкретно веб то C# это реально кроссплатформенная вещь, если писать бизнес логику C# так же полностью кроссплатформенен.
Здравствуйте, kaa.python, Вы писали:
KP>Хиханьки хахоньками, но ты же понимаешь что на C# кроссплатформенные проекты по пальцам пересчитать можно. Я не вдавался в детали почему, но полагаю что причин на это достаточно.
Я с C# недавно работаю, но думаю что любой проект на ASP.NET, ASP.NET MVC можно запустить на mono. В таких проектах обычно платформозависимые фичи не используют.
Если проект написан на Java это ещё не гарантирует на 100% его кроссплатформенности судя по прочтению форумов посвящённых Java.
В реальности кроссплатформеных проектов на C# немеряно, это и базы данных, и системы сборки, и всякие web'кие приблуды типа nhibernate и т.д. Если ты о них не знаешь это ещё не говорит, что их нет. Я сам думал, что кроссплатформенных проектов на C# мало.
RSA>а вот тогда вопрос, что именно пишется на Java? уж точно не desktop приложения — что тогда? серверная логика?
на Java пишется ВСЕ (без преувеличения) — enterprise серверы, web приложения, офисные приложения (тот же OpenOffice) , IDE (Eclipse & Netbeans),
мобильные приложения — умаешься перечислять
но в некоторых особо критичных местах часть кода пишется на C/C++ который дергается из Java , так что С++ это всегда нужный скилл
Здравствуйте, SkyDance, Вы писали:
A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
SD>Примерно так SD>Потом прихожу я, и дожимаю остатки. А там еще порядок может спрятаться
И вапще, "на порядок" — это какие-то детские заявления. Это константу при сложности улучшил что-ли? Хорошо, только редко когда ее нужно улучшать бывает.
Обычно от квадратичных (а иногда и хуже) индо-алгоритмов приходится в сторону n*logn, а то и к чему лучше уходить. А там "на порядок" — бессмыслица,
от данных зависит. Я так могу сказать, что однажды за один заход на три порядка код улучшил...
Я еще 8 лет назад почуял что слабо дело с C++, занялся .NET и веб и не ошибся, работы завались и платят нормально. До этого где-то 4 года работал с С++ и был доволен. В основном ASP.NET занимаюсь и SQL Server-oм.
Здравствуйте, SkyDance, Вы писали:
A>>А что тогда не по 150 баксов в час гребешь? Или уже гребешь?
SD>Не гребу Разве что в тысячах и в год. SD>Чтобы было как ты пишешь, это, во-первых, знакомства в нужных местах. Во-вторых — аврально-дебильный режим работы "заплатим любые деньги, только СДЕЛАЙ ПРЯМО СЕЙЧАС, а еще лучше вчера".
Знакомства далеко не обязательны, знаю примеры, а вот овертаймы действительно случаются достаточно часто, но не 24/7. Вспомнил, ты же банки не любишь
M> Я так могу сказать, что однажды за один заход на три порядка код улучшил...
Охотно верю.
Но специфика массового индуса программиста на managed-языке — полнейшее незнание и непонимание базовых вещей, порой даже O(n). Плюс, еще раз отмечаю, иногда важна на сама по себе производительность, а ее предсказуемость (читай, realtime).
Здравствуйте, SkyDance, Вы писали:
M>> Я так могу сказать, что однажды за один заход на три порядка код улучшил...
SD>Охотно верю. SD>Но специфика массового индуса программиста на managed-языке — полнейшее незнание и непонимание базовых вещей, порой даже O(n). Плюс, еще раз отмечаю, иногда важна на сама по себе производительность, а ее предсказуемость (читай, realtime).
На Java достигается комбинацией прямых рук при кодировании (чтобы Major GC стрелял насколько можно реже в стандартных условиях), параметрами сборщика мусора (параллельные сборщики в таких случаях применяются) и, при возможности, доращиванием оперативки — чтобы Major GC происходила тогда, когда можно.
M>На Java достигается комбинацией прямых рук при кодировании (чтобы Major GC стрелял насколько можно реже в стандартных условиях), параметрами сборщика мусора (параллельные сборщики в таких случаях применяются) и, при возможности, доращиванием оперативки — чтобы Major GC происходила тогда, когда можно.
Угу. "После сборки обработать напильником". Говорю же, что на С++, что на Java, что на многих других языках — "нет ничего невозможного" (С)
Но быстрее и проще сразу написать на С те части, где требуется кропотливое высчитывание critical path. Честно сказать, не знаю, чем вы занимаетесь, но ответ на вопрос "устроит ли ваших пользователей время ответа системы в 10 мкс" даст мне понять, на одном ли мы языке с вами говорим, и об одних ли и тех же вещах.
PS: я просто сейчас уже в той ситуации, когда clock_gettime(), занимающий 25 нс (i7-2600k, SB, TSC правильный, общий для всех ядер), заменяется на rdtsc (7 нс). Сейчас мозг ломаю, что делать с некоторыми местами, где требуется синхронизация. Пробуем optimistic locking. Посмотрю, что получится. Конечно, все это можно на Java. Только зачем, если все равно disasm читать?
Здравствуйте, SkyDance, Вы писали:
M>>На Java достигается комбинацией прямых рук при кодировании (чтобы Major GC стрелял насколько можно реже в стандартных условиях), параметрами сборщика мусора (параллельные сборщики в таких случаях применяются) и, при возможности, доращиванием оперативки — чтобы Major GC происходила тогда, когда можно.
SD>Угу. "После сборки обработать напильником". Говорю же, что на С++, что на Java, что на многих других языках — "нет ничего невозможного" (С) SD>Но быстрее и проще сразу написать на С те части, где требуется кропотливое высчитывание critical path. Честно сказать, не знаю, чем вы занимаетесь, но ответ на вопрос "устроит ли ваших пользователей время ответа системы в 10 мкс" даст мне понять, на одном ли мы языке с вами говорим, и об одних ли и тех же вещах.
SD>PS: я просто сейчас уже в той ситуации, когда clock_gettime(), занимающий 25 нс (i7-2600k, SB, TSC правильный, общий для всех ядер), заменяется на rdtsc (7 нс). Сейчас мозг ломаю, что делать с некоторыми местами, где требуется синхронизация. Пробуем optimistic locking. Посмотрю, что получится. Конечно, все это можно на Java. Только зачем, если все равно disasm читать?
На разных. Мне блох ловить не требуется
От меня хотят, чтобы условный гиг данных перемололся за 30 секунд, а не за 3 часа. Вот до 2-3 минут (например) можно алгоритмами пилить, а дальше да — начинается охота за константой. Там уже начинаю изучать, где что ненужное вызывается, а где более быстрые аналоги дернуть можно.
Здравствуйте, RSATom, Вы писали:
RSA>Ну с побочными скиллами и так проблем нет, да и с незнакомыми вещами разобраться не проблема, но продать их можно только в крупных городах(а мигрировать не хочется) или по удаленке (куда я и пытаюсь последнее время двигаться, но пока без особого успеха) да и не совсем понятно какие из скиллов прокачивать...
Здравствуйте, RSATom, Вы писали:
RSA>Хорошо, допустим я решил двигаться в сторону Java. С чего начать? Я не про "что почитать", а про "что попытаться сделать" (в рассчете на то, что в процессе создания этого самого "что", можно будет ознакомится с ключевыми моментами разработки на Java)?
Если таки хотите остаться C++ программистом, а Java была бы бэкграундом то можно посмотреть в сторону NDK / OpenGL для Android.
Там есть, что замутить на C++ особенно в графике, игрушках, и недавно появилась Native Activity, которая позволяет целиком писать на C++ для Android. Цимес в том, что эта комбинация становится всё востребованнее и всё больше конторок за две копейки хотят делать некие девайсы на базе открытого Android (от secure телефонов до специфических таблеток под определённый бизнес), а там непочатый край работы для адаптации к своему железу.
Здравствуйте, warhast, Вы писали:
W>И в нагрузку вопрос — насколько реально после C++ с реверсингом устроиться на яву без опыта в ней? При этом максимум на что хватит времени — какие-нибудь тетрисообразия на андроидный мобильник намолотить чтобы хоть что-то было предъявить, или такое вообще не в тему, лучше книжек в это время почитать?
В чистую Java, IMHO, скушновато. А в смежных областях, почему бы и не.
Так и происходит, что есть опыт с девайсами, а за одно давай немного UI подрисуем.
Здравствуйте, Abalak, Вы писали:
A>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
Я вот медленно, но верно сруливаю на плюсы — дотнет надоел как-то Пока делаю ОС-проект, чтобы освежить свои знания, а там уже можно и на контракт замахиваться
Здравствуйте, SkyDance, Вы писали:
M>>От меня хотят, чтобы условный гиг данных перемололся за 30 секунд, а не за 3 часа. Вот до 2-3 минут (например) можно алгоритмами пилить, а дальше да — начинается охота за константой. Там уже начинаю изучать, где что ненужное вызывается, а где более быстрые аналоги дернуть можно.
SD>Так это, простите, халява — для такого инструментов создано — море разливанное. Банальнейший профайлер сразу покажет, где затыки, после чего самым что ни на есть простым "методом пристального взгляда" можно сообразить, что к чему. Тем более это не собеседования и гугл с книжками не запрещен.
А пацаны то и не знали. Работал недавно с кодом — 95 % времени в чтении с диска. Работает условных 10 минут. Закончил — 95% в чтении с диска (меньше процента разброс). Работает минуту. Профайлер — лучший на данный момент (YourKit). Помимо "пристального взгляда" еще не мешает знать, что ищешь.
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, SkyDance, Вы писали:
M>>>От меня хотят, чтобы условный гиг данных перемололся за 30 секунд, а не за 3 часа. Вот до 2-3 минут (например) можно алгоритмами пилить, а дальше да — начинается охота за константой. Там уже начинаю изучать, где что ненужное вызывается, а где более быстрые аналоги дернуть можно.
SD>>Так это, простите, халява — для такого инструментов создано — море разливанное. Банальнейший профайлер сразу покажет, где затыки, после чего самым что ни на есть простым "методом пристального взгляда" можно сообразить, что к чему. Тем более это не собеседования и гугл с книжками не запрещен.
M>А пацаны то и не знали. Работал недавно с кодом — 95 % времени в чтении с диска. Работает условных 10 минут. Закончил — 95% в чтении с диска (меньше процента разброс). Работает минуту. Профайлер — лучший на данный момент (YourKit). Помимо "пристального взгляда" еще не мешает знать, что ищешь.
Короче говоря, я улучшаю throughput, а вы — latency
M>А пацаны то и не знали. Работал недавно с кодом — 95 % времени в чтении с диска.
Ну видишь, как у тебя все просто. Упирается в диск. Взял и посмотрел, почему упирается. Там никакой rocket science, либо данные читаются несколько раз, либо буферизация плохая, либо вы пользуетесь random access на жестких дисках (которые, как известно, лучше делают linear read — таки не SSD!)
То ли дело у нас. Конкуренты вчера были быстрее.
Все
Здравствуйте, SkyDance, Вы писали:
SD>Ну и, в Австралии есть прямой резон не зарабатывать больше 150к в год, там дальше начинается совершенный коммунизм и полная налоговая обдираловка.
Если жена не работает (или работает, но получает немного), то попробуй family trust. Не знаю как это работает, но получается, что весь семейный доход делится пополам и налогов платится меньше. Знакомые практикуют, надо разузнать.
A>>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
K>Я вот медленно, но верно сруливаю на плюсы — дотнет надоел как-то Пока делаю ОС-проект, чтобы освежить свои знания, а там уже можно и на контракт замахиваться
Новые проекты на плюсах никто не пишет в финансовой индустрии ибо дорого и хотят как всегда вчера. На плюсах остается только поддержка легаси проектов. Все новые проекты на дот нете и джаве.
На всякий случай повторюсь что речь о финансовой индустрии.
ned>Если жена не работает (или работает, но получает немного), то попробуй family trust. Не знаю как это работает, но получается, что весь семейный доход делится пополам и налогов платится меньше. Знакомые практикуют, надо разузнать.
Спасибо за совет! Надо будет разузнать, действительно.
Особенно, в свете последних событий с ценами на детсады. Я их как увидел, так охренел совсем очень удивился, $115 в день на ребенка... иными словами, "доналоговых" 35к в год. Практически среднеавстралийская зарплата. Просто за сад. На 1-го ребенка.
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
L>Вы просто судите по бизнес проектам видимо. Там java и С# рулит. Однако, что то "пониже" — будет на плюсах ништяк. Я вот например удаленно пишу антивирусник за 5К.
А "в контакте" тогда при чем?
L>С++ вечен, только если ситуация не появится чтобы его задавить.
Я тоже так считал но в последнее время мое вера в него сильно пошатнулась.
З.Ы. Антивирусы — слишком специфичная и небольшая ниша.
RSA>>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время... TSP>>Delphi то и тот не умер. Он превратился в зомби, вокруг него летают мухи, но он тупо идёт вперёд со стеклянным взглядом. А вы уже плюсы хороните, которые во всю мутируют и обрастают неимоверным количеством либ.
L>Слишком категорично про Делфи. Где ж он умер то? Помоему один инструмент нативность поддерживать.
RSA>>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
O>>не часто, но регулярно встречаю коллег (.Net с опытом 5+) которые "вдруг" решают начинать учить С++. O>>аргументы на вопрос "почему?": от "от С++ никуда не деться" до "я понял что С# — фуфел". O>>вот. тоже тема к размышлениям.
RSA>С# хорошая штука, но думаю проблема в том что его пытаются запихать туда где ему не место. Например работу с сетью гораздо разумней делать на С++, а интерфейс лучше делать на C# — вопрос правильного применения инструмента...
Это почему еще работу с сетью разумней делать на плюсах?
Здравствуйте, Abalak, Вы писали:
A>Здравствуйте, lpc, Вы писали:
V>>>-трейдинговые платформы
lpc>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается).
A>А потом приходят спецы по плюсам и увеличивают производительность на порядок
Твои фантазии.
A>ЗЫ Если что, я сам — дотнетчик.
Я плюсовик но и под дот нет пишу. Код с которым приходится иметь дело что на плюсах, что на шарпе одинаково, мягко говоря, плох. Не смотря на все эти собеседования.
Здравствуйте, SkyDance, Вы писали:
M>>А пацаны то и не знали. Работал недавно с кодом — 95 % времени в чтении с диска.
SD>Ну видишь, как у тебя все просто. Упирается в диск. Взял и посмотрел, почему упирается. Там никакой rocket science, либо данные читаются несколько раз, либо буферизация плохая, либо вы пользуетесь random access на жестких дисках (которые, как известно, лучше делают linear read — таки не SSD!)
SD>То ли дело у нас. Конкуренты вчера были быстрее. SD>Все
Приятно общаться с человеком, который в курсе Да, оно все действительно не сложно. Когда ты в курсе Но почему-то почти никто не в курсе
A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
SD>Примерно так SD>Потом прихожу я, и дожимаю остатки. А там еще порядок может спрятаться
A>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
Если собираешься оставаться в финансовой индустрии, то не советую. На плюсах нового мало что пишут. В основном джава и шарп. И на плюсах работы существенно меньше и в основном старые проекты. Говорю как плюсовик и сам хочу свалить чисто на шарп хоть и люблю С++.
Так ТС прав в своем наблюдении. По крайней мере в НЙ.
Здравствуйте, Олег К., Вы писали:
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается).
A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
ОК>Твои фантазии.
Медицинский факт. Лично видел.
A>>ЗЫ Если что, я сам — дотнетчик.
ОК>Я плюсовик но и под дот нет пишу. Код с которым приходится иметь дело что на плюсах, что на шарпе одинаково, мягко говоря, плох. Не смотря на все эти собеседования.
Сам себе противоречишь этими двумя фразами. Если код — дерьмо, то его есть куда улучшать, ну или переписать накрайняк.
Здравствуйте, SkyDance, Вы писали:
SD>Особенно, в свете последних событий с ценами на детсады. Я их как увидел, так охренел совсем очень удивился, $115 в день на ребенка... иными словами, "доналоговых" 35к в год. Практически среднеавстралийская зарплата. Просто за сад. На 1-го ребенка.
Centrelink половину возвращает и средняя цена все-таки немного ниже $100, но все равно очень дорого, да.
Здравствуйте, Олег К., Вы писали:
RSA>>С# хорошая штука, но думаю проблема в том что его пытаются запихать туда где ему не место. Например работу с сетью гораздо разумней делать на С++, а интерфейс лучше делать на C# — вопрос правильного применения инструмента...
ОК>Это почему еще работу с сетью разумней делать на плюсах?
Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
Здравствуйте, RSATom, Вы писали:
RSA>Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
Да фиг понять. С тех пор как в той же Java появилась поддержка асинхронной работы с сетью, никаких очень уж серьезных плюсов за C/C++ в сетевой области я не вижу. По памяти будет выигрыш, по производительности скорей всего будет выигрыш, но, зачастую, ты даже на Питоне можешь написать и никто и не заметит что тормозит
A>>>ЗЫ Самого подмывает плюсами конкретно заняться, надо лень побороть и решить окончательно, либо делать уклон в бизнесс, либо в плюсы.
ОК>>Если собираешься оставаться в финансовой индустрии, то не советую. На плюсах нового мало что пишут. В основном джава и шарп. И на плюсах работы существенно меньше и в основном старые проекты. Говорю как плюсовик и сам хочу свалить чисто на шарп хоть и люблю С++.
A>Ну шарп-то не забуду, слишком много времени уже на нем. А связка плюсы/шарп мне видится вполне боевой.
Ну да. Боевая. Я не отрицаю этого. Можно еще пару аббревиатур/технологий добавить. Тогда еще более боевая будет.
ОК>>Так ТС прав в своем наблюдении. По крайней мере в НЙ.
A>За весь НЙ не скажу, но у пары очень крупных игроков плюсы никуда не деваются. Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
Да знаю я прекрасно этих игроков. Какое-то нелепое поверье что чем ближе к бирже тем у них больше преимущества. Да, я понимаю что Япониии с ними, конечно же, не соперничать но в пределах Манхеттена уж вряд ли можно говорить о каких либо преимуществах. Ну и сам код тоже г. Только понты одни.
lpc>>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается).
A>>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
ОК>>Твои фантазии.
A>Медицинский факт. Лично видел.
Ты не в стране эльфов случайно живешь?
A>>>ЗЫ Если что, я сам — дотнетчик.
ОК>>Я плюсовик но и под дот нет пишу. Код с которым приходится иметь дело что на плюсах, что на шарпе одинаково, мягко говоря, плох. Не смотря на все эти собеседования.
A>Сам себе противоречишь этими двумя фразами. Если код — дерьмо, то его есть куда улучшать, ну или переписать накрайняк.
Уж не знаю как я себе противоречу. Ты знаешь пословицу "что написанно пером не вырубишь топором?" Если код дерьмо с самого начала, то его не так и просто улучшить. Переписать — это маловероятно т.к. лишние расходы и, самое главное, где гарантия что не получится очередное г.? Иногда-таки переписывают, когда меняется начальство, но обычно результат не лучше существующего. А обычно людям приходится работать в рамках того, что набангалорили их предшественники.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, RSATom, Вы писали:
RSA>>Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
KP>Да фиг понять. С тех пор как в той же Java появилась поддержка асинхронной работы с сетью, никаких очень уж серьезных плюсов за C/C++ в сетевой области я не вижу. По памяти будет выигрыш, по производительности скорей всего будет выигрыш, но, зачастую, ты даже на Питоне можешь написать и никто и не заметит что тормозит
На "тормозит/не тормозит" похоже все уже забили — дешевле железяку новую взять, чем оптимизировать что либо
RSA>>>С# хорошая штука, но думаю проблема в том что его пытаются запихать туда где ему не место. Например работу с сетью гораздо разумней делать на С++, а интерфейс лучше делать на C# — вопрос правильного применения инструмента...
ОК>>Это почему еще работу с сетью разумней делать на плюсах? RSA>Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
Вот не согласен совсем! Да, если тебе нужно общаться по какому-то проприетарному протоколу, то прийдется работать с сокетами и шарп, имхо, тут будет не хуже плюсов т.к. боттлнек в самой сети. Если же ты планируешь какую-то новую распределенную архитектуру, то тут уж сразу надо брать более высокоуровневые абстракции чем сокет, биты и байта. В дот нете очень хороша сериализация и ремоутинг тоже хорош или что там нового Майкрософт придумал (WCF?). Так что в этом случае вообще надо забыть о сокетах.
Здравствуйте, Олег К., Вы писали:
ОК>>>Это почему еще работу с сетью разумней делать на плюсах? RSA>>Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
ОК>Вот не согласен совсем! Да, если тебе нужно общаться по какому-то проприетарному протоколу, то прийдется работать с сокетами и шарп, имхо, тут будет не хуже плюсов т.к. боттлнек в самой сети. Если же ты планируешь какую-то новую распределенную архитектуру, то тут уж сразу надо брать более высокоуровневые абстракции чем сокет, биты и байта. В дот нете очень хороша сериализация и ремоутинг тоже хорош или что там нового Майкрософт придумал (WCF?). Так что в этом случае вообще надо забыть о сокетах.
Я не спорю с тем что все что можно сделать на C/C++ можно сделать на C# — я говорю только про "удобней", в контексте работы с сокетами, и ничего более. Мое ИМХО в том что и Java и C# и С и С++ и много много других — замечательные языки, но у каждого из них есть своя специфика, и некоторые вещи удобней делать с помощью одного инструмента, а другие с помощью другого.
"Серебрянной пули" не существует к сожалению...
Здравствуйте, RSATom, Вы писали:
RSA>Здравствуйте, kaa.python, Вы писали:
KP>>Здравствуйте, RSATom, Вы писали:
RSA>>>Я ниже поправлялся что лучше на C/C++. Просто по тому что работать с "битиками" и "байтиками" проще. Естественно при этом подразумевается низкоуровневая реализация протоколов, а не использование готовых библиотек.
KP>>Да фиг понять. С тех пор как в той же Java появилась поддержка асинхронной работы с сетью, никаких очень уж серьезных плюсов за C/C++ в сетевой области я не вижу. По памяти будет выигрыш, по производительности скорей всего будет выигрыш, но, зачастую, ты даже на Питоне можешь написать и никто и не заметит что тормозит RSA>На "тормозит/не тормозит" похоже все уже забили — дешевле железяку новую взять, чем оптимизировать что либо
Есть случаи, когда нет железки, соответствующей имющемуся софту и требованиям. Например, во сколько вам обойдется железка со 128 гигами оперативки и как быстро вы ее достанете? (это не самый страшный случай).
Здравствуйте, mik1, Вы писали:
M>Есть случаи, когда нет железки, соответствующей имющемуся софту и требованиям. Например, во сколько вам обойдется железка со 128 гигами оперативки и как быстро вы ее достанете? (это не самый страшный случай).
Пограничные случаи всегда были и всегда будут, я же говорю о mainstream'е
Здравствуйте, mik1, Вы писали:
RSA>>Пограничные случаи всегда были и всегда будут, я же говорю о mainstream'е
M>В mainstream — конечно Вот поэтому оптимизаторы крутятся в основном в финансах.
ned>Centrelink половину возвращает и средняя цена все-таки немного ниже $100, но все равно очень дорого, да.
Ха-ха. Нам две недели назад из садика пришло письмо: "Centerlink больше не оплачивает половину садика, потому что вы достигли предела по выплатам Centerlink'а, поэтому теперь мы с вас возьмем то, что центрлинк недодал, и вообще до конца финансового года будем брать полную сумму".
Зашел на сайт центрлинка, — там лимит — в год — $7.500. Однако! В год-то на садик надо нефиговых 27.000 (из расчета 54 недели по $100 в день). Иными словами, Centerlink вернет _ЧЕТВЕРТЬ_ — и в среднем самому платить нефиговые $75 в день.
И так не один год
Здравствуйте, SkyDance, Вы писали:
SD>Зашел на сайт центрлинка, — там лимит — в год — $7.500. Однако! В год-то на садик надо нефиговых 27.000 (из расчета 54 недели по $100 в день). Иными словами, Centerlink вернет _ЧЕТВЕРТЬ_ — и в среднем самому платить нефиговые $75 в день.
Ого. Не знал, что там лимит есть. За $30K в год проще бабушек привозить по очереди на полгода по туристической.
Здравствуйте, SkyDance, Вы писали:
ned>>Centrelink половину возвращает и средняя цена все-таки немного ниже $100, но все равно очень дорого, да.
SD>Ха-ха. Нам две недели назад из садика пришло письмо: "Centerlink больше не оплачивает половину садика, потому что вы достигли предела по выплатам Centerlink'а, поэтому теперь мы с вас возьмем то, что центрлинк недодал, и вообще до конца финансового года будем брать полную сумму". SD>Зашел на сайт центрлинка, — там лимит — в год — $7.500. Однако! В год-то на садик надо нефиговых 27.000 (из расчета 54 недели по $100 в день). Иными словами, Centerlink вернет _ЧЕТВЕРТЬ_ — и в среднем самому платить нефиговые $75 в день. SD>И так не один год
Чорт! И плюсовых и в году недель больше, чем у нас
Здравствуйте, RSATom, Вы писали:
RSA>>Хорошо, допустим я решил двигаться в сторону Java. С чего начать? Я не про "что почитать", а про "что попытаться сделать" (в рассчете на то, что в процессе создания этого самого "что", можно будет ознакомится с ключевыми моментами разработки на Java)?
RSA>Кстати, вот например всякие "облачные" технологии типа Google App Engine и Amazon Web Services — насколько они востребованы? Там же тоже Ява...
Java?
Google App Engine — Java or Python.
Amazon Web Services — RESTful API, т.е. пофиг что.
Здравствуйте, SkyDance, Вы писали:
A>>Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
SD>Хех. Я как раз недавно на практике замерял. Ethernet-кабель длиной 30 метров на фреймах длиной 128 байт payload (+издержки самого ethernet) идут на 1 мкс длиннее, чем с кабелем 0.3 метра. Так что, чувакам стенку-то пробурить бы
Чорт! Похоже вблизи черной дыры замер производился, там где скорость света только 30.000 км/ч
Здравствуйте, SkyDance, Вы писали:
SD>Хех. Я как раз недавно на практике замерял. Ethernet-кабель длиной 30 метров на фреймах длиной 128 байт payload (+издержки самого ethernet) идут на 1 мкс длиннее, чем с кабелем 0.3 метра. Так что, чувакам стенку-то пробурить бы
Это время от первого до последниго байта в одном пакете- чем больше длина кабеля, тем больше сопротивление ? Сколько Ом сопротивление у короткого кабеля и у длинного? Или здесь что-то другое
ОК>Да знаю я прекрасно этих игроков. Какое-то нелепое поверье что чем ближе к бирже тем у них больше преимущества. Да, я понимаю что Япониии с ними, конечно же, не соперничать но в пределах Манхеттена уж вряд ли можно говорить о каких либо преимуществах. Ну и сам код тоже г. Только понты одни.
Близость к бирже серьезный фактор. Понятно что лишний километр ничего не решает, но тысяча километров от биржи — это уже фактор
Здравствуйте, Олег К., Вы писали:
ОК>>>Твои фантазии.
A>>Медицинский факт. Лично видел.
ОК>Ты не в стране эльфов случайно живешь?
Ну вон в соседнем сообщении SkyDance даже конкретные цифры привел. А то, что видел, это как человек переписывал работу со строками, умными указателями и вообще с памятью. Порядок выиграл.
A>>Сам себе противоречишь этими двумя фразами. Если код — дерьмо, то его есть куда улучшать, ну или переписать накрайняк.
ОК>Уж не знаю как я себе противоречу. Ты знаешь пословицу "что написанно пером не вырубишь топором?" Если код дерьмо с самого начала, то его не так и просто улучшить. Переписать — это маловероятно т.к. лишние расходы и, самое главное, где гарантия что не получится очередное г.? Иногда-таки переписывают, когда меняется начальство, но обычно результат не лучше существующего. А обычно людям приходится работать в рамках того, что набангалорили их предшественники.
Т.е. ты отрицаешь возможность наличия грамотных спецов? Странно. Пепеписывать можно и по частям, а шанс, что получится г-но сильно зависит от уровня человека, подходов желания. Единственное с чем соглашусь, так это с тем, что хороший код последнее время встретить все сложнее.
Здравствуйте, Олег К., Вы писали:
A>>За весь НЙ не скажу, но у пары очень крупных игроков плюсы никуда не деваются. Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
ОК>Да знаю я прекрасно этих игроков. Какое-то нелепое поверье что чем ближе к бирже тем у них больше преимущества. Да, я понимаю что Япониии с ними, конечно же, не соперничать но в пределах Манхеттена уж вряд ли можно говорить о каких либо преимуществах. Ну и сам код тоже г. Только понты одни.
Здравствуйте, RSATom, Вы писали:
RSA>Я не спорю с тем что все что можно сделать на C/C++ можно сделать на C# — я говорю только про "удобней", в контексте работы с сокетами, и ничего более.
Было бы кстати очень интересно если бы языки сравнить так: запретить использовать все стандартные библиотеки. Оставить только то, что необходимо для нормальной работы встроенных типов. Дать задачу. И потом посмотреть с кого больше потов сойдёт.
Здравствуйте, RSATom, Вы писали:
RSA>Здравствуйте, kaa.python, Вы писали:
KP>>Лично я знаю только о случаях перехода на Java (сам вынужденно перешел). RSA>А вот кстати вопрос, а как получилось перескочить на Java? Работодатели же косо смотрят на людей без опыта?
Я, например, ушел на java-проект, интересный для меня по разным причинам. Занимаюсь на проекте такими вещами, где нужна практически только core java плюс парочка библиотек (jasperreports, antlr), что особых проблем не вызвало. Если надо будет вернуться на с++, с удовольствием это сделаю, благо работы на с++ вроде бы хватает.
Здравствуйте, Abalak, Вы писали:
lpc>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). A>А потом приходят спецы по плюсам и увеличивают производительность на порядок
Ха-ха, а мы и есть спецы по плюсам, которых попросили сделать на java так же быстро как на плюсах Получилось.
Здравствуйте, Олег К., Вы писали:
ОК>Новые проекты на плюсах никто не пишет в финансовой индустрии ибо дорого и хотят как всегда вчера. На плюсах остается только поддержка легаси проектов. Все новые проекты на дот нете и джаве. ОК>На всякий случай повторюсь что речь о финансовой индустрии.
Ага, все так, разве что HFT много где на плюсах и называть это легаси пока рановато. Я сам пару лет назад окончательно свалил с плюсов потому что стало невыносимо ковыряться в 10 летнем коде (да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз).
Здравствуйте, Handie, Вы писали:
ОК>>Да знаю я прекрасно этих игроков. Какое-то нелепое поверье что чем ближе к бирже тем у них больше преимущества. Да, я понимаю что Япониии с ними, конечно же, не соперничать но в пределах Манхеттена уж вряд ли можно говорить о каких либо преимуществах. Ну и сам код тоже г. Только понты одни.
H>Близость к бирже серьезный фактор. Понятно что лишний километр ничего не решает, но тысяча километров от биржи — это уже фактор
Километр тоже решает — это почти 3.5 микросекунды. В мире HFT и SOR это более чем достаточно чтобы купить-продать первым.
Здравствуйте, SkyDance, Вы писали:
SD> Конечно, все это можно на Java. Только зачем, если все равно disasm читать?
Причин несколько:
— Далеко не все части системы требуют подсчета наносекунд и их написать на java куда проще и быстрей
— Intellij IDEA значительно повышает производительность труда
— Дебажить код в Java на порядок проще чем в плюсах
— Hiring — найти толкового джава девелопера и научить хард-корщине куда проще чем найти вменяемого динозавра С++ девелопера
Здравствуйте, Олег К., Вы писали:
ОК>О Дельфи только в СНГ и знают. Потому и умер.
...А мне всегда было интересно узнать те единицы людей, которые в России еще и лицензией владеют на него. На что только абракадабра до сих пор существует?
Здравствуйте, Handie, Вы писали:
V>>-трейдинговые платформы
H>У меня был переход с C++ на Node.js. H>В результате трудоемкость упала раз в пять при сохранении производительности.
а как вы ее, производительность, меряли?
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
не знаю... меня регулярно бомбят ашеры...
везде где есть слова производительность — используется С++. Обработка звука, видео, изображений, игры, кад системы, трэйдинг системы, встроенные системы — это то о чем пишут hr-ы сейчас. Да, в связке с другими языками, да — не повально. Лично я сейчас работаю с С++ и java. Не могу с вами согласиться, что работы нет.
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
ОК>>На всякий случай повторюсь что речь о финансовой индустрии.
K>Мне финансы не интересны — есть куда более интересные области
Кто еще может соперничать с финансовой индустрией по зарплатам? Впрочем я тебя ничуть не агитирую. Если тебе нравится какая-то область и платят там чтобы не задумываться о деньгах — то почему бы и нет?
ОК>>Новые проекты на плюсах никто не пишет в финансовой индустрии ибо дорого и хотят как всегда вчера. На плюсах остается только поддержка легаси проектов. Все новые проекты на дот нете и джаве. ОК>>На всякий случай повторюсь что речь о финансовой индустрии.
lpc>Ага, все так, разве что HFT много где на плюсах и называть это легаси пока рановато. Я сам пару лет назад окончательно свалил с плюсов потому что стало невыносимо ковыряться в 10 летнем коде (да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз).
Первое. ХФТ — очень маленькая ниша. Второе. Вероятно те проекты что на плюсах, были начаты совсем недавно — лет пару назад и самыми упертыми которые считают что плюсы не побить в производительности (но забывают про боттлнек в виде сети). Третье. Сами рекрутеры говорят что плюсов мало и что то что есть, то в основном легаси. Я, вот, легаси не боюсь но просто работ на плюсах самих по себе исчезающе мало.
Впрочем я не понял согласен ты со мной на счет доли плюсах в финансах или нет.
A>>>За весь НЙ не скажу, но у пары очень крупных игроков плюсы никуда не деваются. Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
ОК>>Да знаю я прекрасно этих игроков. Какое-то нелепое поверье что чем ближе к бирже тем у них больше преимущества. Да, я понимаю что Япониии с ними, конечно же, не соперничать но в пределах Манхеттена уж вряд ли можно говорить о каких либо преимуществах. Ну и сам код тоже г. Только понты одни.
A>И тем не менее. Повторю, код можно и улучшить.
Я не исключаю возможность что где-то есть небольшой проект написанный ориджинал девелопером который его потом же и переписывает. На деле все не так просто.
A>>Чуваки реально тики считают, а сервера торовые ставят за стенкой от найсовских.
SD>Хех. Я как раз недавно на практике замерял. Ethernet-кабель длиной 30 метров на фреймах длиной 128 байт payload (+издержки самого ethernet) идут на 1 мкс длиннее, чем с кабелем 0.3 метра. Так что, чувакам стенку-то пробурить бы
Да чего уж мелочиться. Всем этим биржам надо чарджить огромные бабки за предоставление возможности клиентам ранать их процесы на тех же биржевых серверах где ранаются их собственные процесы, чтобы нетворка избежать. Или вообще загружать динамические библиотеки клиента в свои процесы для еще большего перформанса.
ОК>>>>Твои фантазии.
A>>>Медицинский факт. Лично видел.
ОК>>Ты не в стране эльфов случайно живешь?
A>Ну вон в соседнем сообщении SkyDance даже конкретные цифры привел. А то, что видел, это как человек переписывал работу со строками, умными указателями и вообще с памятью. Порядок выиграл.
Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
А то что ты говоришь — чувак переписал какой-то кусочек код или вообще весь проект? Те проекты над которыми я работал — некоторые даже монстры с начала девяностых — я просто не представляю как их можно переписать. И нужно ли.
Речь тут не о ХФТ, разумеется.
A>>>Сам себе противоречишь этими двумя фразами. Если код — дерьмо, то его есть куда улучшать, ну или переписать накрайняк.
ОК>>Уж не знаю как я себе противоречу. Ты знаешь пословицу "что написанно пером не вырубишь топором?" Если код дерьмо с самого начала, то его не так и просто улучшить. Переписать — это маловероятно т.к. лишние расходы и, самое главное, где гарантия что не получится очередное г.? Иногда-таки переписывают, когда меняется начальство, но обычно результат не лучше существующего. А обычно людям приходится работать в рамках того, что набангалорили их предшественники.
A>Т.е. ты отрицаешь возможность наличия грамотных спецов? Странно. Пепеписывать можно и по частям, а шанс, что получится г-но сильно зависит от уровня человека, подходов желания. Единственное с чем соглашусь, так это с тем, что хороший код последнее время встретить все сложнее.
Ну мы тут все как бы грамотные спецы по умолчанию. Однако я вижу то что вижу. Всем все пофиг как работает и менеджерам и девелоперам. Каждому главное кусок урвать. Побыстрее давай все — менеджерам главное отрепортать своему начальству что работа сделана, а как она сделанна — дело десятое. Ну и про понты не забываем.
Вот меня интервьюировал какое-то время назад чувак. Умные вопросы по плюсам задавал, про оптимизацию говорили, про разницу пре- и пост- инкрементов для итераторов и т.д. и т.п. А как я на код его глянул — так п...ц один. Чувак в tight loop-ах инициализирует гигантские мапы, используют стринги там где можно использовать еньюмы и еще кучи разной гуйни.
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). A>>А потом приходят спецы по плюсам и увеличивают производительность на порядок
lpc>Ха-ха, а мы и есть спецы по плюсам, которых попросили сделать на java так же быстро как на плюсах Получилось.
Это потому что боттлнек не в языке а в сети. (имеется в виду что на плюсах в первую очередь не было каких-нибудь откровенных глупостей вроде линейного поиска в гигантском векторе который делается кучу раз — просто гипотетический пример)
ОК>>О Дельфи только в СНГ и знают. Потому и умер.
T>...А мне всегда было интересно узнать те единицы людей, которые в России еще и лицензией владеют на него. На что только абракадабра до сих пор существует?
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). __>>а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
lpc>P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
Кстати... Вот ты затронул тут чисто технические аспекты. А что там у вас на счет бизнес аспектов? Что с самими стратегиями?
Успех это ведь не только "как можно быстрее передать данные по сети."
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое. lpc>P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
А был смысл так извращаться? Требования делали нежелательными даже minor GC?
Здравствуйте, lpc, Вы писали:
lpc>>>Уже давно многие пишут на Java, в том числе и мы. Если заткнуть GC то производительность мало чем отличается от С++ (если вообше отличается). __>>а как вы это делаете? используете вместо new только предварительно выделенные пулы? какие-то опции виртуальной машины?
lpc>Да, делаем полный pre-allocation и все храним в большом массиве байтов (в реальности массив не один а много, и не только байтов а еще и шортов, интов, лонгов). Чем то похоже на программирование на С, но ООП тоже как ни странно присутствует. Небольшой тюнинг JVM тоже делается. Самое сложное что при таком подходе нельзя использовать никакие (стандартные) библиотеки, даже коллекции, поэтому нам пришлось написать все свое.
lpc>P.S.: для особых случаев можно получить прямой доступ к памяти через sun.misc.Unsafe и разогнаться еше больше.
В мемориз, однозначно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, lpc, Вы писали:
lpc>да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз
Это ты про какие?
Нормальная плюсовая IDE это вижуалка + ассист.
Здравствуйте, Олег К., Вы писали:
ОК>Кстати... Вот ты затронул тут чисто технические аспекты. А что там у вас на счет бизнес аспектов? Что с самими стратегиями? ОК>Успех это ведь не только "как можно быстрее передать данные по сети."
Мы номер 1 в алготрейдинге практически по всем параметрам (согласно Thomson Reuters Extel Survey и ряду других).
Здравствуйте, Трололоша, Вы писали:
lpc>>да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз Т>Это ты про какие? Т>Нормальная плюсовая IDE это вижуалка + ассист.
Про нее любимую. В простом проекте то конечно работает, а если навернуть чуток макросов и шаблонов то капец.
Здравствуйте, Олег К., Вы писали:
lpc>>Ха-ха, а мы и есть спецы по плюсам, которых попросили сделать на java так же быстро как на плюсах Получилось.
ОК>Это потому что боттлнек не в языке а в сети. (имеется в виду что на плюсах в первую очередь не было каких-нибудь откровенных глупостей вроде линейного поиска в гигантском векторе который делается кучу раз — просто гипотетический пример)
У нас уже ровно попалам сеть и CPU — 10GB Solarflare рулит.
Здравствуйте, kaa.python, Вы писали:
KP>Это называется не разогнаться еще больше, а придумать собственный новый велосипед. От Java у вас все равно ничего не осталось, тогда можно использовать C++ и не париться.
Очень дилетантский взгляд. Аргументы я уже приводил в этой ветке.
Здравствуйте, lpc, Вы писали:
lpc>Про нее любимую. В простом проекте то конечно работает, а если навернуть чуток макросов и шаблонов то капец.
Покуда ещё не сталкивался. Можно минимальный пример?
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Т.е. используете неправильный инструмент неправильным способом. Вот что бывает, когда решения о выборе платформы принимают менеджеры.
Обязательно передам ваше экспертное мнение своему боссу. Посмеемся вместе.
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, lpc, Вы писали:
lpc>>Про нее любимую. В простом проекте то конечно работает, а если навернуть чуток макросов и шаблонов то капец. Т>Покуда ещё не сталкивался. Можно минимальный пример?
Пример, к сожалению, не приведу. Студии у меня нет ни дома ни на работе, ровно как и исходников систем своих бывших работодателей.
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>Мне вот еще интересно, перед тем, как делать zero-GC какое-нибудь профилирование проводилось? Дело в том, что специалисты по С++ обычно не очень хорошо понимают, как работает мусоросборник, порой такой фигни от них наслушаешься, и сразу zero-GC да.
О боже... ты серьезно считаешь что топовый инвест банк, который зарабатывает на алготрейдинге миллионы и вкладывает огромные деньги в свои технологии, это куча идиотов которые не догадались проверить а правда ли будет быстрей?
Здравствуйте, lpc, Вы писали:
lpc>О боже... ты серьезно считаешь что топовый инвест банк, который зарабатывает на алготрейдинге миллионы и вкладывает огромные деньги в свои технологии, это куча идиотов которые не догадались проверить а правда ли будет быстрей?
Не исключаю, особенно если это UBS или Дойче. Так профилировали? Информация не секретна? Можно взглянуть на тесты?
И в догонку, есть уверенность, что у вас сейчас действительно zero-GC? Мусоросборник отключен прямо в рантайме (т.е. собран кастомный рантайм джавы, где сборка мусора наглухо вырублена) или вы работаете на стандартном рантайме и думаете, что у вас zero-GC?
Здравствуйте, Паблик Морозов, Вы писали:
ПМ>И в догонку, есть уверенность, что у вас сейчас действительно zero-GC? Мусоросборник отключен прямо в рантайме (т.е. собран кастомный рантайм джавы, где сборка мусора наглухо вырублена) или вы работаете на стандартном рантайме и думаете, что у вас zero-GC?
Нда... ты еще спроси, как мы строки склеиваем, а то вдруг мы не в курсе.
Здравствуйте, Паблик Морозов, Вы писали:
lpc>>О боже... ты серьезно считаешь что топовый инвест банк, который зарабатывает на алготрейдинге миллионы и вкладывает огромные деньги в свои технологии, это куча идиотов которые не догадались проверить а правда ли будет быстрей?
ПМ>Не исключаю, особенно если это UBS или Дойче. Так профилировали? Информация не секретна? Можно взглянуть на тесты?
Ну все понятно, т.е. все вокруг идиоты а ты эксперт, который не знает как узнать стартует ли GC или нет и думает что другие тоже не знают.
Здравствуйте, Олег К., Вы писали:
ОК>Кто еще может соперничать с финансовой индустрией по зарплатам? Впрочем я тебя ничуть не агитирую. Если тебе нравится какая-то область и платят там чтобы не задумываться о деньгах — то почему бы и нет?
Я приехал сюда не за зарплатой (точнее, далеко не только за ней)...
M>Чорт! Похоже вблизи черной дыры замер производился, там где скорость света только 30.000 км/ч
Может и так, не проверял.
Но если головой подумать, и вспомнить, что есть Ethernet, как он работает, и сколько это, 128 байт payload (+накладные расходы ethernet), клоунаду можно было бы и не устраивать.
P>Это время от первого до последниго байта в одном пакете- чем больше длина кабеля, тем больше сопротивление ? Сколько Ом сопротивление у короткого кабеля и у длинного? Или здесь что-то другое
Это замер времени round-trip time, от машины А -> B -> A. Результаты проверены многократно. Напоминаю, скорость распространения электромагнитного сигнала — конечна. В частности, за 1 нс. свет может преодолеть ориентировочно 30 см.. (как раз 0.3 м).
lpc>- Далеко не все части системы требуют подсчета наносекунд и их написать на java куда проще и быстрей
Не вопрос. В таких местах и C#, и любой другой managed-язык годится. Мне они все нравятся, просто по историческим причинам я на Java писал много, а на C# — лишь небольшой автоматизирующий проектик, и то давно уже.
lpc>- Intellij IDEA значительно повышает производительность труда
По сравнению с чем? С Eclipse/CDT? Не вопрос, повышает. А вот в сравнении со Studio под винду, можно и поспорить.
lpc>- Дебажить код в Java на порядок проще чем в плюсах
Проще. На порядок или нет, вопрос, опять же, сомнительный. Да и речь-то не о плюсах. Я уже, кажется, отмечал — я либо за "голый С", когда надо считать latency, либо за managed-язык, когда не так все критично.
lpc>- Hiring — найти толкового джава девелопера и научить хард-корщине куда проще чем найти вменяемого динозавра С++ девелопера
Щаз-з-з-з. Толковые джава-девелоперы все либо с С/С++ бэкграундом (т.е. бывшие плюсовики), либо совсем запредельно денег хотят, еще больше, чем "динозавры". Кроме, понятное дело, России, там вообще страна динозавров
ОК>Это потому что боттлнек не в языке а в сети. (имеется в виду что на плюсах в первую очередь не было каких-нибудь откровенных глупостей вроде линейного поиска в гигантском векторе который делается кучу раз — просто гипотетический пример)
Сеть далеко не всегда боттлнек. Особенно если речь идет о latency, а не о throughput.
ОК>>Это потому что боттлнек не в языке а в сети. (имеется в виду что на плюсах в первую очередь не было каких-нибудь откровенных глупостей вроде линейного поиска в гигантском векторе который делается кучу раз — просто гипотетический пример)
SD>Сеть далеко не всегда боттлнек. Особенно если речь идет о latency, а не о throughput.
К таким конфигурациям даже сами понятия latency (и тем более realtime, с обязательным жестким ограничением на время ответа) неприменимы в общепринятом смысле А главное, что это у вас такое, древний ethernet с коаксиальным кабелем?
Здравствуйте, SkyDance, Вы писали:
ОК>>А если несколько клиентов "вещают в сети?"
SD>К таким конфигурациям даже сами понятия latency (и тем более realtime, с обязательным жестким ограничением на время ответа) неприменимы в общепринятом смысле А главное, что это у вас такое, древний ethernet с коаксиальным кабелем?
Я образно без вдавания в какие-нибудь технологии. В конечном счете на сервера идет трафик от кучи клиентов.
J>Вот у тебя в сетке несколько фидов с разных бирж, все мультикастят — все равно нет latency?
А, я другую картину вообразил. Про мультикаст сразу и не вспомнил. Но это все равно другой случай, и для нормальной real-time все равно не покатит, ибо коллизии. Ну или по православному, через "все со всеми" каналы.
Здравствуйте, Олег К., Вы писали:
ОК>Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
Ха, вообще поразительная реакция аудитории: да вы ваще отключать то его умеете? Вот я то отключу, я д'Артаньян, а вы там в банке своем ...расы криворукие. Вот, то есть был профи, а как пришел в банк и на тебе — руки в зюзю скривились.
Здравствуйте, Kswapd, Вы писали:
SD>>Средняя длина МПХ, согласно опросам, составляет 25 см. SD>>Однако согласно измерениям средняя длина составляет 14 см.
K>В каком состоянии?
Здравствуйте, Олег К., Вы писали:
lpc>>Мы номер 1 в алготрейдинге практически по всем параметрам (согласно Thomson Reuters Extel Survey и ряду других). ОК>Смешно читать такое. Сейчас каждая шарашкина контора является номером один согласно какому-нибудь исследованию, опросу, журналу или сайту.
Прежде чем делать такие глупые заявления, советую разузнять что такое Extel Survey и как именно он проводится.
Здравствуйте, Олег К., Вы писали:
ОК>Копай глубже. Тут вопрос в другом. Насколько вообще это вменяемое требование? А то сделать-то можно но вот нужно ли?
Тебе не кажется что нашему бизнесу видней какое требование вменяемое, а какое нет? Спешу опередить твой следующий вопрос — наш бизнес знает что такое GC и что свет проходит 30 см за 1 наносекунду.
P.S.: Когда приходит market order и система залипает на пол-секунды из-за GC то за это время цена может значительно просесть и клиент нам предъявит убытки (а еще хуже если будет как с насдаком по время IPO фейсбука). Реально смешно читать про советы такие советы...
Здравствуйте, Олег К., Вы писали:
ОК>Для тех кто в танке, можно объяснить на пальцах что же вы там все-таки набангалорили?
Не стоит думать что все такие же бангалорцы как у вас на проекте. У нас все хорошо.
ОК>Я не понимаю. Как можно преаллокейтать все объекты когда их количество неизвестно до рантайма ровно также как и не известно какие "пути будут следоваться в коде." И всех этих объектов, мягко говоря, дохрена.
ОК>Или вы написали свой аллокатор? В таком случае чем он лучше сановского? И что происходит с объектами которые больше не нужны? Где берется память когда закончилась существующая?
Обычно курс молодого бойца занимает 2-3 месяца и я как то не вижу особого смысла рассказыват о всех деталях на открытом форуме, тем более людям с таким негативным настроем как у тебя.
P.S.: когда заканчивается память то делаем new (который не вызывает GC потому что у нас всегда есть запас в young generation).
Здравствуйте, Олег К., Вы писали:
ОК>А не нужны эти макросы и шаблоны в нормальном коде. (Эти слова не следует понимать что нужно отказаться от СТЛ — их следует понимать что не надо писать в стиле "меня Александреску в полнолуние укусил.")
Определи что такое 1) нормальный код и что такое 2) макросы и шаблоны в смысле СТЛ но не в смысле александерску. Потом поговорим.
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, Олег К., Вы писали:
ОК>>Копай глубже. Тут вопрос в другом. Насколько вообще это вменяемое требование? А то сделать-то можно но вот нужно ли?
lpc>Тебе не кажется что нашему бизнесу видней какое требование вменяемое, а какое нет? Спешу опередить твой следующий вопрос — наш бизнес знает что такое GC и что свет проходит 30 см за 1 наносекунду.
lpc>P.S.: Когда приходит market order и система залипает на пол-секунды из-за GC то за это время цена может значительно просесть и клиент нам предъявит убытки (а еще хуже если будет как с насдаком по время IPO фейсбука). Реально смешно читать про советы такие советы...
Интересно таки, почему стоит оставлять от Явы одно название, но пользоваться ею.
Если маркет не 24-часовой, то в окнах можно чистить память/перезапускать процесс.
Следующий интересный вопрос — размер working set. Minor GC с || коллектором занимают > 0.1 секунды на несколько гигабайтных объёмах (причем тут есть шансы пошаманить, использовать G1 или машину от Azul).
Если же память вручную аллокировать, то возвращаемся к вопросу о фрагментации, компактированию и прочим около сборочно-мусорным вещам... Тут можно предположить, что памяти до фига и вы дотягиваете до окна в торгах. Только с дофига памяти можно и не городить такой огород...
lpc>>>Мы номер 1 в алготрейдинге практически по всем параметрам (согласно Thomson Reuters Extel Survey и ряду других). ОК>>Смешно читать такое. Сейчас каждая шарашкина контора является номером один согласно какому-нибудь исследованию, опросу, журналу или сайту.
lpc>Прежде чем делать такие глупые заявления, советую разузнять что такое Extel Survey и как именно он проводится.
Да мне и читать ничего не надо. Я тебе и так все скажу. Там везде свои люди. Большой дядя звонит своему дружбану и говорит что хочет такую-то статью. Дальше дело денег.
ОК>>Копай глубже. Тут вопрос в другом. Насколько вообще это вменяемое требование? А то сделать-то можно но вот нужно ли?
lpc>Тебе не кажется что нашему бизнесу видней какое требование вменяемое, а какое нет? Спешу опередить твой следующий вопрос — наш бизнес знает что такое GC и что свет проходит 30 см за 1 наносекунду.
Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем.
С опережением ты поспешил. Я это и не собирался спрашивать. Спрошу другое. Допустим вы выжали целую секунду с вашим решением. Теперь следуя этой логике имеет смысл оптимизировать драйвера и/или планировщик Линукса (Линукс чисто как пример). Вы не собираетесь там этим в ближайшее время заняться?
lpc>P.S.: Когда приходит market order и система залипает на пол-секунды из-за GC то за это время цена может значительно просесть и клиент нам предъявит убытки (а еще хуже если будет как с насдаком по время IPO фейсбука). Реально смешно читать про советы такие советы...
ОК>>Для тех кто в танке, можно объяснить на пальцах что же вы там все-таки набангалорили?
lpc>Не стоит думать что все такие же бангалорцы как у вас на проекте. У нас все хорошо.
Тут уже несколько человек раскритиковали ваше решение. Так уж и хорошо?
ОК>>Я не понимаю. Как можно преаллокейтать все объекты когда их количество неизвестно до рантайма ровно также как и не известно какие "пути будут следоваться в коде." И всех этих объектов, мягко говоря, дохрена.
ОК>>Или вы написали свой аллокатор? В таком случае чем он лучше сановского? И что происходит с объектами которые больше не нужны? Где берется память когда закончилась существующая?
lpc>Обычно курс молодого бойца занимает 2-3 месяца и я как то не вижу особого смысла рассказыват о всех деталях на открытом форуме, тем более людям с таким негативным настроем как у тебя.
Да нормальный у меня настрой и у других тоже нормальный. Ты лучше уж поделись деталями (раз сам затронул тему что вы там сделали) сколько человек это пилило, обсуждало и неужели там не было никого кто бы воспротивился этому решению?
lpc>P.S.: когда заканчивается память то делаем new (который не вызывает GC потому что у нас всегда есть запас в young generation).
У вас память что ли бесконечна?
Давай уж, не говори про курс молодого бойца и два-три месяца. Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
ОК>>А не нужны эти макросы и шаблоны в нормальном коде. (Эти слова не следует понимать что нужно отказаться от СТЛ — их следует понимать что не надо писать в стиле "меня Александреску в полнолуние укусил.")
lpc>Определи что такое 1) нормальный код и что такое 2) макросы и шаблоны в смысле СТЛ но не в смысле александерску. Потом поговорим.
Ну начинается. Простой, лаконичный код который можно понять сходу и/или пройтись отладчиком если надо. Так чтобы плеваться не приходилось. На счет 2). Вместо #define MY_CONST 7 пишешь const int MyConst = 7; или енумы, вместо #define SQUARE(x) ((x) * (x)) пишешь соответсвенно инлайн функцию, на счет темплейтов — пользуешься стандартными контейнерами и смарт пойнтерами и очень редко когда сам пишешь темплейтные функции и классы. Большего и не нужно.
Здравствуйте, Олег К., Вы писали:
ОК>У вас память что ли бесконечна?
Кстати, это вариант. Тогда аллокатор будет реально быстрым
ОК>Давай уж, не говори про курс молодого бойца и два-три месяца. Расскажи на пальцах в течении пяти минут подробнее. А то у меня до сих пор непонимание как можно преаллокейтить все объекты когда ты не знаешь даже в рантайме сколько их у тебя еще будет да и каких типов.
Чую, что все 'объекты' у них — это одноуровневые структуры с методами, сильно напоминающими ByteBuffer: getInt(offset), getByte(offset) и т.д.
Но вот как они их вычищают???
ОК>>Успех торговли это еще не только возможность первым купить, но еще и сама стратегия. Только закладываются почему-то на первое.
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 все, впрочем, много проще — хорошей персоналки хватит.
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 очень нравилась, после борланда под досом.
Здравствуйте, lpc, Вы писали:
ОК>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем. lpc>Не тяжело жить с мыслью что вокруг одни идиоты?
Его греет мысль что он сам — Д'Артаньян.
Здравствуйте, lpc, Вы писали:
lpc>Памяти ессно жрем дофига, никакой фрагментации не возникает т.к. память никогда не освобождается (но и не растет, за редким исключением). Без "городить огород" будет еще больше памяти жрать т.к. между объектами есть "дыры" (со всякими служебными полями), которые к тому же сильно увеличивают количество кэш миссов — перформанс тесты это очень хорошо показывают. Далее, чем больше объектов тем больше jvm/gc тратит ресурсов для поддержки card table. Разница между 1000000 объектов и 2000 может быть весьма ощутимая.
Да, в чистой Яве попадать в кэш иногда мучительно непросто. Вкупе с сообщением о 48 гигах и знанием размеров рынков мне теперь практически все понятно
Меня с моими задачами пока что от major сборок сильно спасают коллекции примитивов, типа trove, но если нужно от них нужно избавиться с гарантией, то да, подход неплохой. Опять же, в моем случае можно подкрутить параметры сборщика, чтобы протянуть достаточное (для меня!) время.
Здравствуйте, 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.
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 с "обычным линуксом", извините, колоссальная.
Здравствуйте, Олег К., Вы писали:
ОК>Не тяжело. Уж точно не идиоты стояли во главе (ну и вниз по цепочке) в Bear Stearns, Lehman Brothers, Washington Mutual и что там еще.
Ну и где щас тот Lehman Brothers?
Довелось с ними поработать, незадолго до их бесславной кончины. Редкостные дебилы там попадались. Кубло индусов, с подковёрными дрязгами.
ОК>Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в kernel mode залезут программисты из инвестмент банка, то это вообще жесть будет.
Да они и в прикладуе творили адЪ. Вша из из кода лезла просто табунами.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Олег К., Вы писали:
ОК>>Не тяжело. Уж точно не идиоты стояли во главе (ну и вниз по цепочке) в Bear Stearns, Lehman Brothers, Washington Mutual и что там еще. CC>Ну и где щас тот Lehman Brothers? CC>Довелось с ними поработать, незадолго до их бесславной кончины. Редкостные дебилы там попадались. Кубло индусов, с подковёрными дрязгами.
Подозреваю, что это был сарказм со стороны Олега К.
Здравствуйте, Олег К., Вы писали:
ОК>А вот ты не только трололо, но еще и школоло. А лпц и остальные лица у него на работе — сто процентные Дон Кихоты.
Ну я ж говорю: Д'Артаньян.
У тебя один ты светоч разума и носитель сакрального знания. А всех вокруг считаешь кем полагается считать Д'Артаньяну окружающих.
ОК>Какой же я Д'Артаньян?
Да классический же!
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, Олег К., Вы писали:
ОК>>Мне все равно что там у вас и я очень хорошо знаю какие идиоты могут встречаться во всех этих компаниях. На всех ступеньках карьерной лестницы. "Чем бы дитя не тешилось лишь бы не плакало," в общем.
lpc>Не тяжело жить с мыслью что вокруг одни идиоты?
Я не думаю, что Олег К. считает идиотом тебя и твоих коллег.
Я лично преклоняюсь перед вашим мастерством.
Выжать скорость из непредназначенной для этого платформы, используя ее непредназначенным способом — это, безусловно, потребовало нескольких лет усилий очень талантливых людей.
Что не отменяет идиотизма изначально принятого кем-то решения вырезать гланды через об использовании этой платформы.
Здравствуйте, Олег К., Вы писали:
ОК>А тут и не надо является экспертом в хфт чтобы понимать что вы там наделали (скорее всего по приказу сверху).
Все твои вопросы в этом и других ответах показывают, что таки надо. Уж если не экспертом, но хотя бы иметь опыт работы с подобными системами. Иначе — шквал очень глупых и смешных вопросов, отвечать на которые нет никакого желания.
Здравствуйте, jazzer, Вы писали:
ОК>>Ну и потом. Допустим они заранее создали все объекты которые только возможно. Зачем им тогда писать свой аллокатор? J>Ну, судя по тому, что он еще писал, у них блочный аллокатор, т.е. они преаллокировали здоровый кусок памяти на, скажем, 100000 ордеров, и пока у них меньше 10000 ордеров, никаких больше аллокаций не происходит. Но если рынок колбасит и ордеров нужно больше, то выделяется еще один блок на следуюшую сотню тысяч ордеров, и дальше опять никаких аллокаций.
Да, все примерно так (только расти x2 нет смысла, +25% обычно хватит чтобы дожить до конца дня). Назвать это "аллокатором" у меня язык не поворачивается, слишком уж все это тривиально. Но некоторым товарищам здесь этого не понять и они будут с пеной у рта доказывать что они там наговнокодили.
Здравствуйте, Олег К., Вы писали:
ОК>Боюсь тут дело в лпц а не в студии. Если лпц каждый раз пишет что-то вроде ОК>
ОК>#define MY_COOL_MACRO(a, b, c) \
ОК>do \
ОК>{ \
ОК> // Тут дохрена кода
ОК>} \
ОК>while (false)
ОК>
ОК>вместо того чтобы написать инлайн функцию, то, разумеется, студия ему не поможет.
Ёклмн... иди учись читать! И думать головой.
lpc>Я сам пару лет назад окончательно свалил с плюсов потому что стало невыносимо ковыряться в 10 летнем коде (да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз).
Для тех кто в танке разжевываю по буквами — речь шла о том, что С++ позволяет написать такой код, что ни одна C++ IDE не в состоянии это разобрать. В Java такой проблемы не существует.
Здравствуйте, lpc, Вы писали:
lpc>Здравствуйте, Паблик Морозов, Вы писали:
ПМ>>При этом не ответил ни на один технический вопрос, зато повыпендривался на отличненько.
lpc>На технические вопросы я отвечаю либо когда вижу подленный интерес, либо на job interview. Перед "Паблик Морозов" метать бисер я не намерен.
Здравствуйте, licedey, Вы писали:
L>Простите, а на чем пишут бэк-энд мэйн-стрима? Гугл, бинг, фэйсбук, яндекс, касперски, паралелс и прочее...Понимаю не все там работают, однако же.
Здравствуйте, lpc, Вы писали:
lpc>Ох устал я пытаться доказывать непонятно что и непонятно зачем... Но сделаю очень маленькую последнюю попытку.
Дык сразу бы так написал. На самом деле этот пост многие вопросы проясняет.
Здравствуйте, lpc, Вы писали:
lpc>Да, все примерно так (только расти x2 нет смысла, +25% обычно хватит чтобы дожить до конца дня).
Т.е. всплеска оно не переживёт?
lpc> Назвать это "аллокатором" у меня язык не поворачивается, слишком уж все это тривиально. Но некоторым товарищам здесь этого не понять и они будут с пеной у рта доказывать что они там наговнокодили.
Ну, прочитав описания и сложив картину у меня тоже лезет на язык "говнокод!".
Но у тебя есть индульгенция в виде специфики области применения (я в HFT чуток имел возможность нос сунуть. Попробовал, но больше почему то не хочется) + факт, что оно таки как надо работает.
Поэтому моя оценка: "Ничего не трогай, ничего не меняй. Но продолжение начни лучше писать с нуля." (С)
Здравствуйте, lpc, Вы писали:
lpc>>Я сам пару лет назад окончательно свалил с плюсов потому что стало невыносимо ковыряться в 10 летнем коде (да еще и убогие плюсовые IDE остались на том же уровне что и 10 лет назад — rename работает правильно лишь через раз). lpc>Для тех кто в танке разжевываю по буквами — речь шла о том, что С++ позволяет написать такой код, что ни одна C++ IDE не в состоянии это разобрать. В Java такой проблемы не существует.
Вернёмся с небес на землю.
А в реале написавший в production код, который ни один IDE не могёт разжевать, сначала одаривается скипидарной клизмой и ЦУ "переделать нахрен сейчас же!". В случае хронического рецидива применяется живительная эвтаназия — персонаж выпинывается с конторы, никому вредители не нужны.
Поэтому о каком "позволяет написать" может вестись речь?
Здравствуйте, Олег К., Вы писали:
ОК>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло.
Аналогично. Кванты просто адова тоска.
Здравствуйте, Трололоша, Вы писали:
Т>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>Развидеть невозможно!
это obfuscated perl, не надо его за нормальынй перл выдавать.
Почему то перловые скрипты, которые пишу я, ни у кого в команде вопросов не вызывают, хотя перл, кроме меня, знает от силы полтора человека.
На всякий случай процитирую ман перла:
Perl is designed to give you several ways to do anything, so consider picking the most readable one.
Здравствуйте, jazzer, Вы писали:
Т>>ЗЫ: Вы таки видимо примеры перловарения не видели. Т>>Увидеть можно тут: http://cs.usu.edu.ru/langs/perl/obfuperl.htm Т>>Развидеть невозможно!
J>это obfuscated perl, не надо его за нормальынй перл выдавать.
Дык язык позволяет жеж.
Давай тогда и С++ делить на obfuscated и "нормальный".
J>Почему то перловые скрипты, которые пишу я, ни у кого в команде вопросов не вызывают, хотя перл, кроме меня, знает от силы полтора человека.
Наверное потому, почему С++ который я пишу тоже вопросов не вызывает как у коллег так и у IDE?
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, 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. Это ж своего рода искусство и делается такое специально, но только для демонстрации.
Здравствуйте, Трололоша, Вы писали:
A>>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации. Т>Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
«Не так прикольно оформленные очень похожие кусочки» и JAPH-скрипты — это совершенно разные вещи, уровень владения языком в этих двух случаях различается на порядок.
Здравствуйте, anonymous, Вы писали:
A>>>Такого практически невозможно встретить в production. Это ж своего рода искусство и делается такое специально, но только для демонстрации. Т>>Да ты шо! А вот в перловых скриптах одного почившего крупного банка я очень похожие кусочки встречал. Не так прикольно оформленные правда.
A>«Не так прикольно оформленные очень похожие кусочки» и JAPH-скрипты — это совершенно разные вещи, уровень владения языком в этих двух случаях различается на порядок.
Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода.
Мне похрен какой там уровень владения языком у автора, но если он пишет сразу обфусцированный код то и его и код исключительно фтопку.
Здравствуйте, Трололоша, Вы писали:
Т>Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода.
Ещё раз, для непонятливых: подобные кусочки для того и пишутся, чтобы было сложно понять, как они работают.
Т>Мне похрен какой там уровень владения языком у автора, но если он пишет сразу обфусцированный код то и его и код исключительно фтопку.
JAPH-код не пишут для production, в production часто попадает говнокод, но его то как раз пишут на любом языке.
Здравствуйте, anonymous, Вы писали:
Т>>Ещё раз, для непонятливых: подобные кусочки крайне сильно затрудняют чтение и правку кода. A>Ещё раз, для непонятливых: подобные кусочки для того и пишутся, чтобы было сложно понять, как они работают.
Ты ничего не понял.
Отдельные идиоты всегда в таком стиле пишут свой код. Потому что могут и хотят.
Перечитай с чего мы в этой ветке на перл вышли.
ОК>>Ну если ОСь и железо тьюнают Юниксовские администраторы, то это нормально. Но вот если в 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, сами понять не в состоянии. И интереснее и меньшее зло. Т>>Аналогично. Кванты просто адова тоска.
зиг>математику зато можно было бы вспомнить, тряхнуть стариной
Зиг, математика та что в книжке отличается от той что в коде. Поверь мне, ты не хочешь иметь дело с существующим квантовским кодом который они сами понять не в состоянии.
Здравствуйте, Олег К., Вы писали:
J>>Плюс в отличие от кривого протокола, кривизну квантовского кода ты исправить можешь, а с кривизной протокола тебе жить, со всеми сопутствующими граблями и велосипедами типа таких: http://www.rsdn.ru/forum/cpp/2899831.1.aspx
(хотя не спорю, тот велосипед было прикольно изобрести, но это удовольствие, сравнимое с тем, что получает уважаемый lpc — преодоление трудностей изначально кривого решения)
ОК>И опять ты исходишь из того что уже существует кривой протокол но квантовский код пишется с нуля и ты можешь подправить его если что. На деле я видел такой код на который страшно смотреть и который не понимали сами кванты. Об эффективности того кода даже речь и не шла.
Ну это уже какие-то крайние случаи, когда в проекте есть боевой код, который никто не понимает, при том что от него зависит вообще существование проекта.
Имхо, такой код должен быть немедленно переписан как несущий огромный риск — в случае чего его никто не сможет поправить.
А обычно квантовский код — это "свой" легаси-код, и ты его можешь менять и переписывать как и любой другой легаси-код, ессно, при условии понимания его.
В отличие от кривого протокола, который тебе дает биржа или брокер и с который ты можешь только при помощи такой-то матери реализовать и забыть как страшный сон (до следующего апгрейда, который может сделать протокол еще кривее).
ОК>Да как случится. Я знаю об одной группе. Написали но денег которые зарабатывали только и хватало чтобы оплатить помещение, зарплату и т.д. Инвесторам это потом надоело и дело закрылось. Но они, конечно же, тоже считали что написали мега ультра хай фриквенси трейдинг систему.
ОК>Опять вода. Ты можешь привести мне конкретные примеры что программисты банков программируют в kernel mode? А не какие-то заказы на стороне и существующие решения.
Опять двадцать пять. Зачем в kernel-то, если дырка в железяку напрямую пробурена? Мне _не нужен_ ни kernel, ни его mode. Железяку, говорю же, впрямую пользую. Но до этого, действительно, писал в kernel.
Хотя, формально, я не работаю в банке. Просто задачи практически идентичные.
Здравствуйте, Олег К., Вы писали:
ОК>>>>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло. Т>>>Аналогично. Кванты просто адова тоска.
зиг>>математику зато можно было бы вспомнить, тряхнуть стариной
ОК>Зиг, математика та что в книжке отличается от той что в коде. Поверь мне, ты не хочешь иметь дело с существующим квантовским кодом который они сами понять не в состоянии.
так это же тоже интересно может быть — раскопать, применить шаблоны, best practice , упорядочить чтобы стало всем все понятно
нет?
Здравствуйте, Олег К., Вы писали:
ОК>Потому что каждый должен заниматься своими вещами. Булочники пекут хлеб, производители железок делают железо и пишут драйвера к ним, Линус и Ко занимается Линуксом а разработчики компиляторов занимаются компиляторами. Что вообще от банка будет если он залезет во все эти области (только потому что они посчитают что сделают лучше)? По-моему это очевидно.
А по-моему это большое заблуждение. А на досуге почитай про slang и kdb (вместо с k & q).
Здравствуйте, Олег К., Вы писали:
ОК>Если вы уж занялись тем чем вы занялись, то вот решение в лоб. На старте имеем большой массив — нашу кучу. Каждый новый объект создаем вконце массива (при вызове new) — операция мгновенная и где-то тут ты говорил что не удаляете объекты. К чему эти 10000 ордеров и +25% — .
1. Можно сколько угодно фантазировать что мы там понаделали, но все это будет очень далеко от реальности.
2. New не бесплатное даже в C++.
Здравствуйте, Олег К., Вы писали:
lpc>>Все твои вопросы в этом и других ответах показывают, что таки надо. Уж если не экспертом, но хотя бы иметь опыт работы с подобными системами. Иначе — шквал очень глупых и смешных вопросов, отвечать на которые нет никакого желания. ОК>Ну еще бы! Ваше решение настолько гениально что куда уж мне понять его?
Вот в этом и корень твоей проблемы — думать что "гениальное" значит сложное.
человек имеет аналогичное мнение об одной из этих финансовых компаний.
Ничо что там про других идиотов? По ссылке мнение про разработку а тут речь о людях, принимающих решения.
ОК>>Опять вода. Ты можешь привести мне конкретные примеры что программисты банков программируют в kernel mode? А не какие-то заказы на стороне и существующие решения.
SD>Опять двадцать пять. Зачем в kernel-то,
Что значит зачем? Я написал что программисты в этих банках залезут скоро-таки в режим ядра. Ты мне на это ответил что уже давно залезли. Я тебя попросил привести примеры того что делают банковские программисты в режиме ядра и сейчас ты возмущаешься "зачем?"
SD>если дырка в железяку напрямую пробурена? Мне _не нужен_ ни kernel, ни его mode.
Ну пробурена и пробурена. Какой интерфейс к этой дырке из юзермодных приложений? Сдается мне что все те же самые сокеты.
High Frequency Trading
Solarflare offers customers the lowest latency networking solutions for high frequency trading and other financial services applications with its high-performance 10GbE server adapters and OpenOnload application acceleration middleware. These products enable customers to leverage their existing Ethernet and IP infrastructures while achieving the absolute lowest latency with no need to modify applications.
Смотри выделенное. То есть получается что те же самые сокеты.
SD>Железяку, говорю же, впрямую пользую. Но до этого, действительно, писал в kernel.
Я не совсем понял как ты используешь железяку напрямую и где ты ее используешь (ядро или юзермод). Считать кадры с железяки это одно но есть еще TCP/IP stack, нужно собрать полученные данные в правильной последовательности, запросить неполученные сегменты и т.д. и т.п. Работы поболее чем просто считать данные с железяки через, возможно, какой-то другой интерфейс в юзермоде.
SD>Хотя, формально, я не работаю в банке. Просто задачи практически идентичные.
Уж не знаю где ты работаешь, но я ни разу не слышал чтобы программисты в банках лезли ниже сокетов.
ОК>>Потому что каждый должен заниматься своими вещами. Булочники пекут хлеб, производители железок делают железо и пишут драйвера к ним, Линус и Ко занимается Линуксом а разработчики компиляторов занимаются компиляторами. Что вообще от банка будет если он залезет во все эти области (только потому что они посчитают что сделают лучше)? По-моему это очевидно.
lpc>А по-моему это большое заблуждение. А на досуге почитай про slang и kdb (вместо с k & q).
Хорошо. Зуб заболит — приходи ко мне, вылечу по старой дружбе. (Я в свободное время практикую еще general dentistry.)
ОК>>Если вы уж занялись тем чем вы занялись, то вот решение в лоб. На старте имеем большой массив — нашу кучу. Каждый новый объект создаем вконце массива (при вызове new) — операция мгновенная и где-то тут ты говорил что не удаляете объекты. К чему эти 10000 ордеров и +25% — .
lpc>1. Можно сколько угодно фантазировать что мы там понаделали, но все это будет очень далеко от реальности.
Да мы и так тут все уже поняли что вы там понаделали.
lpc>2. New не бесплатное даже в C++.
Ты прикидываешься что ли? Я тебе явно не о плюсах сказал сейчас. На всякий случай повторюсь. В рамкой спущенной вам сверху задачи, предложенное решение для new будет мгновенно для всех случаев или O(1) если тебе так угодно. И не нужны тут никакие преаллокейшны и прочие 25 процентов.
lpc>>>Все твои вопросы в этом и других ответах показывают, что таки надо. Уж если не экспертом, но хотя бы иметь опыт работы с подобными системами. Иначе — шквал очень глупых и смешных вопросов, отвечать на которые нет никакого желания. ОК>>Ну еще бы! Ваше решение настолько гениально что куда уж мне понять его?
lpc>Вот в этом и корень твоей проблемы — думать что "гениальное" значит сложное.
Наоборот, я отлично понимаю что "все гениальное просто." А вот вы там нагениалили.
J>Ну это уже какие-то крайние случаи, когда в проекте есть боевой код, который никто не понимает, при том что от него зависит вообще существование проекта. J>Имхо, такой код должен быть немедленно переписан как несущий огромный риск — в случае чего его никто не сможет поправить.
Код живет дольше чем мы думаем он будет жить, хотим мы этого или нет.
J>А обычно квантовский код — это "свой" легаси-код, и ты его можешь менять и переписывать как и любой другой легаси-код, ессно, при условии понимания его.
Мы видимо говорим о разном коде, его качестве и количестве. У нас есть тут Сишные библиотеки с 80-х годов так туда даже кванты без страха смотреть не могут. Мне иногда тоже приходится но сам добровольно я туда не полезу.
J>В отличие от кривого протокола, который тебе дает биржа или брокер и с который ты можешь только при помощи такой-то матери реализовать и забыть как страшный сон (до следующего апгрейда, который может сделать протокол еще кривее).
С этим согласен. С чужим протоколом точно ничего не поделать.
ОК>>>>>Ну неужели рутины нет в квантовском коде? По мне, так уж лучше все-таки копаться в "кривизне очередного непродуманног протокола" чем в кривизне квантовского кода который они, PhDs, сами понять не в состоянии. И интереснее и меньшее зло. Т>>>>Аналогично. Кванты просто адова тоска.
зиг>>>математику зато можно было бы вспомнить, тряхнуть стариной
ОК>>Зиг, математика та что в книжке отличается от той что в коде. Поверь мне, ты не хочешь иметь дело с существующим квантовским кодом который они сами понять не в состоянии.
зиг>так это же тоже интересно может быть — раскопать, применить шаблоны, best practice , упорядочить чтобы стало всем все понятно зиг>нет?
В теории да, на практике нет. Наш сишный код с 80-х годов, к примеру, у меня никакого желания что-либо там менять не вызывает. Переписывать и разбираться тоже. У других аналогично. Так и живем.
Здравствуйте, Олег К., Вы писали:
ОК>Код живет дольше чем мы думаем он будет жить, хотим мы этого или нет.
+1
ОК>Мы видимо говорим о разном коде, его качестве и количестве. У нас есть тут Сишные библиотеки с 80-х годов так туда даже кванты без страха смотреть не могут. Мне иногда тоже приходится но сам добровольно я туда не полезу.
+1
Поэтому у нас (в банке, не в нашей группе) есть супер-DSL
Он, конечно, тоже страшный, но не настолько, насколько страшен Си, поскольку все-таки заточен под задачу
Здравствуйте, Олег К., Вы писали:
lpc>>1. Можно сколько угодно фантазировать что мы там понаделали, но все это будет очень далеко от реальности. ОК>Да мы и так тут все уже поняли что вы там понаделали.
Ты о себе во множественном числе? Еще раз советую перестать фантазировать и выдавать действительное за желаемое. Поможет не только в этой дискуссии.
lpc>>2. New не бесплатное даже в C++.
ОК>Ты прикидываешься что ли? Я тебе явно не о плюсах сказал сейчас. На всякий случай повторюсь. В рамкой спущенной вам сверху задачи, предложенное решение для new будет мгновенно для всех случаев или O(1) если тебе так угодно. И не нужны тут никакие преаллокейшны и прочие 25 процентов.
Я даже не знаю как тут комментировать... Ты очень и очень слабо понимаешь о чем шла речь и предлагаешь какую то чепуху. Я правда не знаю что еще ответить.
Здравствуйте, Олег К., Вы писали:
lpc>>Вот в этом и корень твоей проблемы — думать что "гениальное" значит сложное. ОК>Наоборот, я отлично понимаю что "все гениальное просто." А вот вы там нагениалили.
Здравствуйте, lpc, Вы писали:
lpc>Я даже не знаю как тут комментировать... Ты очень и очень слабо понимаешь о чем шла речь и предлагаешь какую то чепуху. Я правда не знаю что еще ответить.
Здравствуйте, licedey, Вы писали:
L>Здравствуйте, RSATom, Вы писали:
RSA>>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
L>Простите, а на чем пишут бэк-энд мэйн-стрима? Гугл, бинг, фэйсбук, яндекс, касперски, паралелс и прочее...Понимаю не все там работают, однако же.
У фейсбука на PHP....с Hiphop-ом конечно, но на PHP
У гугла внутрях есть как и C++, так и Java
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>Программисту все равно на каком языке писать... привязка к языку говорит о низкой квалификации...
Неправда. Во-первых так думают часто те, кто пишет исключительно на Си-подобных языках (то есть C/C++/C#/Java/JavaScript)
Напишите что-нибудь на Fortran, Cobol, Smalltalk, Forth — посмотрю как лихо Вы сразу и лихо начнете на них писать. Да даже на том же Pascal/Delphi (обычно сишники начинают ныть, что там все убого и не так — а секрет в том, что они попросту не разобрались и не изучили язык и его возможности, а ткаже не въехали в философию языка — что очень важно для интуитивной и продуктивной работы).
Во-вторых — у каждого языка (и даже бывает, — среды/компилятора) свои библиотеки, которые нужно изучить, чтобы хотя-бы знать чем сможешь оперировать. А это — довольно много информации. Больше, чем просто язык.
Так что не надо приуменьшать сложности.
П>Напишите что-нибудь на Fortran, Cobol, Smalltalk, Forth — посмотрю как лихо Вы сразу и лихо начнете на них писать.
Ээээ.... И в чем проблема? Пишется так же лихо, просто медленно — потому что сами языки такие, вдумчивые. Хотя, кобол не пробовал, и форт давно уж тоже не видел.
П>>Напишите что-нибудь на Fortran, Cobol, Smalltalk, Forth — посмотрю как лихо Вы сразу и лихо начнете на них писать.
SD>Ээээ.... И в чем проблема? Пишется так же лихо, просто медленно — потому что сами языки такие, вдумчивые. Хотя, кобол не пробовал, и форт давно уж тоже не видел.
Да, вот если бы программист был Богом (у него высокая квалификация), то есму действительно было бы все равно на каком языке писать.
Но прежде чем писать — нучно изучить язык И библиотеки. А вот это все на качественном уровне помнить невозможно. Поэтому либо работа будет поверхностной и неквалифицированной, либо программист будет долго разбираться (что тоже трудно назвать квалифицированной работой), либо он квалифицированно сможет работать только в узкой области. Так что высказывание было явной спекуляцией
Здравствуйте, Почемучкин, Вы писали:
П>>>Напишите что-нибудь на Fortran, Cobol, Smalltalk, Forth — посмотрю как лихо Вы сразу и лихо начнете на них писать.
SD>>Ээээ.... И в чем проблема? Пишется так же лихо, просто медленно — потому что сами языки такие, вдумчивые. Хотя, кобол не пробовал, и форт давно уж тоже не видел.
П>Да, вот если бы программист был Богом (у него высокая квалификация), то есму действительно было бы все равно на каком языке писать. П>Но прежде чем писать — нучно изучить язык И библиотеки. А вот это все на качественном уровне помнить невозможно. Поэтому либо работа будет поверхностной и неквалифицированной, либо программист будет долго разбираться (что тоже трудно назвать квалифицированной работой), либо он квалифицированно сможет работать только в узкой области. Так что высказывание было явной спекуляцией
Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в использовании твоего языка и библиотек. Опыт подсказывает, что в пределах полугода максимум. А дальше пойдет знание алгоритмов, предметной области и прочая и прочая...
M>Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в использовании твоего языка и библиотек. Опыт подсказывает, что в пределах полугода максимум. А дальше пойдет знание алгоритмов, предметной области и прочая и прочая...
У универсалов есть одна проблема — идти по тропинке, которая будет максимально похожа на то, что они уже знают. То есть они в теории не вникают в суть языка, не используют его особенностей и преимуществ. Пишут простым и не самым эффективным для языка способом — способом, которым можно написать на любом другом языке. ИМХО. Особенно, если нужно писать на нескольких языках параллельно.
FFF>Вы просто не умеете работать с информацией... Любой язык отличается синтаксисом и немного семантикой. Базовые алгоритмические принципы едины везде... везде есть условные переменные и массивы, везде есть условные операторы циклов и условий, все современные языки имеют структуры. Все библиотеки завязаны на платформенных особенностях — практически везде есть память, везде где есть многопоточность — есть объекты синхронизации,.. файлы, сокеты и другие объекты системы, к которым можно получить доступ посредством языка, за исключением случаев накладываемых VM.
Ага, вот об этом я и говорю — особенностей языка такой универсал использовать не будет. Будет пользоваться только тем, что безопасно совпадает с возможностями его основного языка (например C++).
M>>Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в использовании твоего языка и библиотек. Опыт подсказывает, что в пределах полугода максимум. А дальше пойдет знание алгоритмов, предметной области и прочая и прочая...
П>У универсалов есть одна проблема — идти по тропинке, которая будет максимально похожа на то, что они уже знают. То есть они в теории не вникают в суть языка, не используют его особенностей и преимуществ. Пишут простым и не самым эффективным для языка способом — способом, которым можно написать на любом другом языке. ИМХО. Особенно, если нужно писать на нескольких языках параллельно.
На "выучить грамматику" надо день-два, но не полгода. И через день-два, да, буду писать в рамках известных мне конструкций и парадигм. А через полгода — простите, другой уровень. А парадигм сейчас, по сути, всего две — ООП и функциональщина. Как только на immutable данных работать научился — в функциональном стиле уже писать сможешь.
Здравствуйте, mik1, Вы писали:
M>Здравствуйте, Почемучкин, Вы писали:
M>>>Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в использовании твоего языка и библиотек. Опыт подсказывает, что в пределах полугода максимум. А дальше пойдет знание алгоритмов, предметной области и прочая и прочая...
П>>У универсалов есть одна проблема — идти по тропинке, которая будет максимально похожа на то, что они уже знают. То есть они в теории не вникают в суть языка, не используют его особенностей и преимуществ. Пишут простым и не самым эффективным для языка способом — способом, которым можно написать на любом другом языке. ИМХО. Особенно, если нужно писать на нескольких языках параллельно.
M>На "выучить грамматику" надо день-два, но не полгода. И через день-два, да, буду писать в рамках известных мне конструкций и парадигм.
Это мне напоминает фразы, бросаемые походя вроде "да что там писать — за десять минут, от силы полчаса" — а на самом деле минимум несколько часов, а то и недель... Зачем зря болтать?...
За день-два ты сможешь выучить грамматику языка, который похож на C++. Вот потому, что такие языки наиболее распространенные, ты и думаешь, что выучить другой язык легко. На самом деле, если язык не очень похож на Си и будет для тебя новым — ты обломаешься. Чтобы пользоваться грамматикой нужно ее впитать. Это легко когда язык почти копия тех, что ты уже знаешь, но если он другой — за два дня ты не сможешь ее "впитать" на подсознательном уровне. Так что не надо ля-ля... (нет, конечно ты лично суперпрограммист и исключение — второй после Бога )
M>А через полгода — простите, другой уровень.
Вот через полгода, да, — ты его точно освоишь. Даже верю, что через месяц, если настолько хорош.
M>А парадигм сейчас, по сути, всего две — ООП и функциональщина. Как только на immutable данных работать научился — в функциональном стиле уже писать сможешь.
Дело не только в парадигмах, а в сочетании ВСЕГО — парадигм, особенностей языка, сложившихся исторически и отсутствующих в других языках, библиотеках и особенностях модели этих библиотек и подходов работы с ними. Всё это за 2 дня не осилить. За месяц упорного изучения очень опытным программистом — верю.
Здравствуйте, mik1, Вы писали:
M>Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в использовании твоего языка и библиотек. Опыт подсказывает, что в пределах полугода максимум. А дальше пойдет знание алгоритмов, предметной области и прочая и прочая...
Вопрос в том, сколько времени мне понадобится, чтобы тебя догнать в предметной области и алгоритмах... ну, ты понял
Здравствуйте, Young, Вы писали:
Y>Здравствуйте, 0x8000FFFF, Вы писали:
FFF>>Вы просто не умеете работать с информацией... Любой язык отличается синтаксисом и немного семантикой. Базовые алгоритмические принципы едины везде... везде есть условные переменные и массивы, везде есть условные операторы циклов и условий, все современные языки имеют структуры. Все библиотеки завязаны на платформенных особенностях — практически везде есть память, везде где есть многопоточность — есть объекты синхронизации,.. файлы, сокеты и другие объекты системы, к которым можно получить доступ посредством языка, за исключением случаев накладываемых VM.
Y>Вы прямо сделали мне больно, базовые алгоритмические принципе едины везде — только вот почему так мучительно больно иногда (хотя и приятно) писать на хаскеле с эрлангом после десяти лет С++ с Java?
Я пишу и на C/C++ и на Java и на Erlang под ejabberd.
Y>Проблема не в синтаксисе, и не в семантике. Проблема с парадигме.
Хм... проблемы нет — я не вижу разницы в парадигме.
Y>Процедурное программирование, логическое программирование, объектно-ориентированое программирование, аспектно-ориентированное программирование, функционально программирование, метопрограммирвоание — любой язык навязывает определенную парадигму, и сменить ее не очень просто — это не синтаксис и не семантика, зачастую — алгоритмы которые были плохи в предыдушей парадигме становятся хороши в новой и т.п.
Одно из другого вытекает... Просто надо мыслить в нескольких измерениях одновременно, и вообще мыслить категориями языка по мне так — это глупо — я мыслю потоками, блоками памяти, хендлами обеъектов ядра и объектами синхронизации, а язык лишь инструмент предоставляющий представление памяти и механизмов вызовов в человеко-понятном формате.
Y>Да блин, да просто любой язык с иммутабельными данными может местами взорвать могз на совершенно ровном месте.
Здравствуйте, RSATom, Вы писали:
RSA>Что то у меня складывается ощущение что количество работы связанной с С++ резко уменьшилось в последнее время...
Аналогично. Последние два проекта (оба связаны с сотовой связью) — на чистом Си. Хотя в обоих случаях собеседовался на предмет знания C++.
Более того, если зарплаты джавистов и дотнетчиков стабильно растут, то у плюсовиков в среднем они стоят на месте (а уже если проект специфично завязан на "железо", то всё, суши сухари). Не ценят у нас ни сишников, ни плюсовиков.
Уж как мне импонируют плюсы, но, я так думаю, пришло время уходить на интерпрайзную джаву.
Здравствуйте, RHuB, Вы писали:
RHB>Не ценят у нас ни сишников, ни плюсовиков. RHB>Уж как мне импонируют плюсы, но, я так думаю, пришло время уходить на интерпрайзную джаву.
Мне кажется что лучше будет уйти "от нас" к "ним".
Разве что в тысячах и в год.
? Сколько Ом сопротивление у короткого кабеля и у длинного? Или здесь что-то другое 
.
