Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, ·, Вы писали:
I>>>Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов. I>·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится? I>Магически — никак. off-heap в java(и .Net) это переизобретение аллокаторов из C++. I>Такую стратегию управления памятью надо откалибровать во время разработки.
Верно! Иначе потребуется тот же перезапуск во время торговой сессии.
I>Это демонстрация заблуждения "Сборка молодого поколения практически бесплатна."
Если откалибровать во время разработки.
Почему аллокаторы калибровать можно, а параметры gc вдруг нельзя?
I>Она бесплатна сильно условно, гарантии обеспечиваешь ты сам, как вариант — с помощью off-heap решений в менеджед, или аллокаторов — в С++.
Не понимаю к чему ты клонишь. Конечно, гарантии реализации метода doEverythingAsPerBusinessRequirements() тебе придётся обеспечивать самому. В этом никакие ни языки, ни аллокаторы не хуже и не лучше.
I>>>Это и есть "исключить GC". Граф объектов есть, а проходов GC по ём нет. I>·>Не "исключить", а уменьшить интенсивность его использования. Вот в dotnet Sustained LL gc mode — да, это "исключить". И ещё раз повторюсь, с развитием качества gc и других алгоритмов (pauseless gc) необходимость offheap падает. I>Разница в частоте срабатываний примерно 2-3 порядка. Это и есть "исключить". Необходимость не только offheap падает, но и растёт Объемы данных растут быстрее, чем улучшаются алгоритмы и соответсвенно качество работы GC. I>Сейчас вобщем не редкость, когда приходится хранить миллиарды объектов в памяти. Самый распрекрасный GC сосёт не нагибаясь.
Отношение количества таких специфичных задач к общему числу задач падает, могу смело предположить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>Ты не заметил, что здесь противоречие ? quicksort в чистом виде числодробилка. Отсюда ясно, что сколько перформанса не дай, всё равно мало. Ассемблерными вставками вылизать трудно прежде всего потому, что это надо делать под разные процессоры, не говоря про семейства процессоров. I>Кроме того, сишный компилер справится с оптимизацией гораздо лучше, нежели ты со своими ассемблерными вставками.
Верно. И судя по тому как sort реализован в java и в c# — jvm справляется лучше (обошлись без native) чем dotnet (написано с unsafe).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ikemefula, Вы писали:
I>·>В большинстве задач хвататет и производительности PHP. I>·>Суть в том, что чем меньше таких задач, когда не хватает производительности managed и приходится использовать native — тем лучше. I>Вот здесь подробнее. Вот надо за доли секунды обработать пару миллиардов строчек статистики, потому что бизнесу это даёт один доллар каждую миликунду. Ты пойдешь к бизнесу и скажешь "чем меньше таких задач ...тем лучше" ?
Хз, ты же сам понимаешь что тут нет однозначного ответа. Надо сравнивать ("цена для реализации проекта на managed" — "потери от проседания производительности") с "цена реализации на native". Нередко левая часть неравенства оказывается меньше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
I>>·>Ну почти, если тормоза будут упущены на этапе perf tests, то можно будет прод-сервак перезапустить с другими параметрами gc (изменить размер YG или возраст отправки в OG, например). I>>Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов. ·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится?
Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом", вот так и в самописном аллокаторе С++ объекты такого размера можно сопровождать на какой-нить fall-back сценарий.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, ·, Вы писали:
V>>>Еще раз. Гибридные появились из-за того, что уделывают расово-чистые. V>>>Никаких других причин тут нет, ес-но. V>·>Плохая отмаза. Расово-чистое C++ решение уделает любое гибридное. V>Ну мы же не для себя софт пишем, а для клиентов. V>Клиенты есть не только под нейтив.
Клиенты — дураки что-ли? Писали бы всё на нейтиве и уделывали бы всех.
V>·>А я не совсем понимаю как же ещё-то можно системные вещи писать? Ну там к железке какой обратиться или файлик записать... но обработка fix-протокола не системная вещь, ни разу. V>Системный или не системный — это спекуляции.
Системный — платформозависимый, связанный с железом. Фин-данные тут причём?
V>FIX-протокол содержит внутри себя транспортный + сеансовый уровень по OSI, ну типа как SSL, VPN и т.д.
А вот HTTP протокол тебе захочется так же гибридно имплементировать? Он того же уровня, что и FIX.
V>·>Не я к личности стал прикапываться. Какая разница когда и какую я искал работу? V>Разница есть когда тебя малость заносит: V>
V>Даю совет: вежливо признать свою неправоту и поблагодарить собеседника гораздо полезнее не только для поднятия своей репутации, но и для собственного развития.
Ок, заносит. Но это был ответ на хамство и пустых обвинениях во лжи.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
I>>>Так и вижу — во время торговой сессии сервак решил перезапуститься из за того, что появилось лишнее поколение объектов. V>·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится? V>Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом", вот так и в самописном аллокаторе С++ объекты такого размера можно сопровождать на какой-нить fall-back сценарий.
Ну т.е. сабж, переизобретём gc ручками.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>Чтобы не утекло, используется специфическая типизация. Например, ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса. V>>·>Причём тут типизация? V>>Чтобы не утекло. ·>Блин, я, видимо, неоднозначно выразился. Под утечкой я не утечку памяти имел в виду, а логическую утечку данных или ссылок на них из контекста.
Я прекрасно понял и поэтому сослался на статическую типизацию того же std::vector<>.
В общем, поскольку ты не захотел на него посмотреть, скопирую его объявление сюда сугубо для истории аргументов:
template<class _Ty, class _Ax = allocator<_Ty> >
class vector;
Т.е., определив через typedef некий "региональные вектор":
ты не сможешь передать его как ссылку/указатель туда, где ожидается дефолтный std::vector<int, allocator<int> >.
Такая техника работает для любых пользовательских типов в т.ч.
·>Вначале данные использовались только в рамках контекста, а теперь вдруг они нам понадобились вне контекста — и вроде бы небольшое изменение ВНЕЗАПНО становится ломающим, сложным, требующим пересмотреть архитектуру.
Описанная техника заведомо используется там, где никакого ВНЕЗАПНО быть не может.
Увы, увы, никакой "true agile" в таких областях IT не живет, там обитает только водопад и отсутствие внезапности.
Там когда что-то меняется — то это совсем из-за сдвигов тектонического масштаба. Например, в Windows 8 и Server 2012 появилось новое АПИ Registered IO. Но это в любом случае голову включать надо и смотреть/экспериментировать — будут ли полезные плюшки для конкретного кейза или нет.
·>Согласен. Но я, надеюсь, что ты не будешь спорить с тем, что управление памятью значительно влияет на структуру приложения?
Если речь об эффективности? Ес-но.
Остальное ложно, бо есть такая подмеченная фигня — люди с опытом в управляемых средах поначалу испытывают трудности в С++ в определении иерархии владения. )) Городят много shared_ptr на ровном месте, ну просто тоннами. Через год уже смотришь — всё прошло. Нужные навыки въедаются в мозжечок и более не требуют мыслительных затрат.
·>Даже в Яве управление любыми ресурсами (всякими там соединениями, открытыми файлами, транзакциями, етс) вечная беда
В C# есть using(IDisposable), а в плюсах так и вовсе RAII — наше фсё. ))
V>>·>в каком именно месте можно вернуть в пул (а если мы внезапно что-то решили обработать асинхронно?) V>>Асинхронно означает "долгий процесс". В долгих процессах другие алгоритмы работы с памятью (пулы объектов, например). ·>Вот... А java — пофиг, пиши как пишется и не надо заботиться об этих алгоритмах, ибо он один единственный — gc.
Но именно в Джава пулы объектов сверх-популярны. Как так?
V>>·>Согласен, но это надо далеко не всегда. В подавляющем числе приложений компьютер прибирает достаточно хорошо, чтобы стоило заморачивать себе этим голову. V>>Я тебе больше скажу. Даже в нейтиве описанную технику применяют ОЧЕНЬ редко. ·>А в яве — никогда
О чем и речь. Потому что низзя.
·>Но, насколько я слышал, аллокация памяти в Java операция быстрее, чем в С++ (по крайней мере в универсальном аллокаторе, а не в заточенном под конкретный юзкейс).
Конечно быстрее, тем более, что дефолный хип в С++ — он многопоточный и вызывает конфликты при аллокации/деаллокации. Но как раз спасает то, что в типичном С++-приложении во многие разы меньше операций выделений памяти (я же уже расписывал — почему).
Большинство операций по выделению памяти в С++ можно отнести к разряду "однократных". Вот, подключились к бирже, у нас образовался объект "Сессия", отключились — исчез. По сравнению с десятками тыщ перемалываемых этой сессией событий в секунду (одиночный фид даёт до 40 тыс событий в секунду на некоторых биржах, а фидов может быть много), частоту событий создания/удаления объектов верхнего уровня (Сессий) можно принять нулевой.
В общем, в специфике С++ для 99% сценариев самописные аллокаторы нафик не нужны (для объекта-Сессии), но иногда возможность их использовать очень даже в кассу (для объектов-сообщений).
·>TLS это публичное API для хранилища юзерских данных, целый контейнер. А TLAB-указатель это просто поле во внутренней структуре контекста thread, невероятно удивлюсь, если использование этого указателя занимает более пары машинных инструкций.
Весь твой TLAB — это один из объектов, хранимых в TLS, не более того.
Вернее, в TLS хранится указатель на TLAB.
Здравствуйте, ·, Вы писали:
·>Так тут меня убеждают, что c# это супер-пупер-мега-экста-максимум, голов эдак на 100 выше Java по всем фронтам. Там и великолепнейший gc есть с гениальным sustained LL mode, и struct types, и Expression Trees, linq, и stackalloc, и с 1C интегрируется, и c++/clr, чуть ли не паузы приходится расставлять, иначе производительнось c# получается выше натива; вообще: "Эй, птичка, летим со мной, там столько вкусного!!!".
Так и есть. Осталось ко всему этому опенсорсные винды и ву а ля!
Здравствуйте, alex_public, Вы писали:
_>Я смотрю тут дискуссия упёрлась во вроде как парадокс. С одной стороны C# как язык очевидно лучше Java, и просто сам по себе и с точки зрения потенциальной оптимизации. Это факт. А с другой стороны на практике Java показывает лучшие результаты и индустрия явно выбирает Java. Это тоже факт. Казалось бы какое-то противоречие.
Нет никакого противоречия. Виндовый дотнет быстрее джавы, но линуховый не быстрее. Поэтому, если брать линуха, то дотнет не даёт никаких плюшек.
_>Тут в дискуссии многие похоже забывают, что речь не о нативном коде, а об управляемом, по сути работающим под контролем ВМ. В особенности это касается Java с её escape-анализом
Скажи, ты давно всерьез экспериментировал с тем, что даёт дотнет на value-types и джава со своим хот-спот?
Я уже лет 5-6 не экспериментирую, потому что интересных новостей об улучшении JIT в джава НЕ было. А когда экспериментировал, то там приговор однозначный — value-типы дают серьезный буст.
И тут как раз обсуждали с коллегой со стороны баррикад джавы, так он делился теми подробностями, что в джава на ByteBuffer порой делают "плоскую" разметку памяти ручками, коль value-типы отсутствуют в самой машинке.
_>который при срабатывание (абсолютно не гарантированном, но всё же) позволяет достигать даже большей чем у C# локальности (прямо как у правильного C++ кода).
Это рассуждения вникуда. Дотнет изначально поставлялся с офф-лайн компилятором в нейтив. Тут вся претензия к нему, что хороший оптимизатор этому компилятору прикрутили вот только в 2012-м.
_>Более того, там даже есть парочка мелких забавных трюков, которые не реализуемы (в смысле автоматически, компилятором, — руками то можно что угодно) даже на C++.
Ну это грубая реклама уже. ))
На С++ реализуемы очень многие трюки, которые никакому хот-споту и не снились.
Просто потому, что на сегодня во всей индустрии не существует более продвинутых в плане оптимизации компиляторов, чем компиляторы С++.
_>Естественно в целом это не позволяет Java коду обходить C++, но сам факт любопытен. Ну а уж помочь обогнать обычный (не оптимизированный специально) C# код это позволяет без проблем.
А мужики-то и не знают! ))
И где ты эту фантастику берешь?
_>Т.е. в итоге у нас получается такой расклад:
_>1. Пишем канонический код на C++ и получаем бесплатно гарантированное (ну если правильные опции компилятора стоят) максимальной быстродействие. _>2. Пишем канонический код на Java и есть шанс, что после прогрева он тоже будет работать довольно шустро. Ну а если нужны гарантии, то надо уже писать свою ВМ под конкретную узкую задачу. Что впрочем тоже не проблема в Java мире, благодаря открытости данной платформы, и вполне применяется (в той теме были ссылки). _>3. Пишем канонический код на C# и получаем тормознутый результат. Плюс есть возможность заморочиться и написать более менее оптимизированный код (только структуры, unsafe операции, своё выделение памяти и т.п.), но тогда требуется соответствующая квалификация и теряется большая часть смысла от управляемой платформы (тогда уж лучше сразу на C++ писать).
Ясно, смешались в кучу кони-люди. ))
На самом деле в итоге у нас получается такой расклад:
— хейтеры MS;
— все остальные.
Хейтеры MS согласны работать только на Linux, все остальные согласны на что угодно, даже на FreeBSD, Windows, iOS или SunOS.
Потому что хейтеры MS собрались в кучку сугубо из любителей Linux, ну вот просто Windows у них исторический враг #1, бо если бы не Windows, вот уж они бы тогда показали! ))
_>Так что выбор индустрии вполне понятен и логичен
Да, выбор индустрии понятен и логичен — на сервере linux, на клиенте Windows/iOS/Андроид.
(И не говорите мне, что Андроид, это Linux, это отдельная экосистема, не имеющая с Linux ничего общего, кроме ядра).
_>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
Никакому Net Native никакой JS никуда не наступает и близко. И не наступит никогда, ес-но, пока речь будет идти о JIT-компиляции.
Здравствуйте, ·, Вы писали:
V>>Ну и клиентское биржевое приложение не сильно в плане многопоточности отличается от серверного — у нас есть клиенты, которые создают многие десятки (до двух-трех сотен) подключений одновременно. ·>Да, но микросекундные задержки рояли не играют, всё что меньше 1 секунды — никто не заметит. Да и подключения, как правило, куда угодно по миру, вплоть до пингов в сотни миллисекунд.
Я рядом уже давал ту инфу, что крупнейшие брокеры размещены физически близко в бирже. Чаще всего — в одном здании и имеют доступ по локальной сетке к торгам. Там +- одна микросекунда уже влияет, а не секунда. ))
V>>·>А любые клиентские проги в HFT не важнее как Оутлука. V>>Важность для каждого отдельного клиента просто катастрофическая. ·>Как и Оутлука или какого-нибудь news-фида.
Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто.
V>>·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера. V>>Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются. ·>Когда последний раз менялся стандарт JPEG? И сколько раз за свою жизнь?
JPEG-LS, JPEG XR — относительно новые.
V>>В третьих, ЛЮБЫЕ "алгофичи" торговых роботов задаются как композиция базовых стратегий/операций/условий, т.е. фактически декларативно из небольшого набора простых отлаженных кирпичиков. ·>Сам ведь знаешь, что сложность композиции компонент не означает простое сложение их сложности.
Когда речь идёт о выходе за границы диапазона неких массивов, то это не важно. ))
V>>По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде. ·>Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры.
Ну вот как раз в данных и патчат более всего.
V>>Та блин, я тебе как раз привел именно такой пример — необходимо снять ордера с торгов, а операция совершается с ошибкой. ·>А я имею в виду, что гораздо хуже, когда операция завершается "успешно", но делает хрен знает что, из-за того, что итератор куда-то не туда убежал. И обнаруживается это сильно потом.
Возможно. Но на практике проход по памяти в С++ случается на порядки реже, чем ошибки типизации в сильно динамическом джавовском коде.
V>>Я ж не думал, что мне надо всё пояснять до самого конца, а именно — если ты вышел из клиентского приложения (джавовское fail-fast), это НЕ значит, что твои ордера перестали торговаться на бирже (для системы в целом нет никакого fail-fast). ·>Если GUI глючит, обычно можно позвонить в саппорт и попросить снять ордера. ·>В общем какая-то гипотетическая ситуация с гипотетическими проблемами, не хочу фантазировать и спекулировать.
Ну а я тебе случай из реальной жизни привожу.
Ты еще попробуй дозвонись, когда на бирже паника.
V>>Убежать за границы сильно сложнее. ·>Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*.
На практике отличается сильно.
— пробежка "ручками" обычно идёт по итераторам;
— 99% алгоритмов над вектором никакими ручками не делаются, заполнение через всякие input_iterator, обработка через пару итераторов (раньше) или напрямую сейчас (boost::range).
Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее.
V>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end(). ·>В каких? Кто сравнивает? std::vector — не сравнивает.
Любой алгоритм сравнивает два итератора.
·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
Дык, уровень косвенности на единицу меньше.
·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.
90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды.
А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но.
V>>·>HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач. V>>Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность. ·>И даже с этой полусотней работать проще из Java чем из native.
Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. ))
Сейчас библиотек под С++ уже просто тонны под все случаи жизни.
Здравствуйте, ·, Вы писали:
V>>Ну мы же не для себя софт пишем, а для клиентов. V>>Клиенты есть не только под нейтив. ·>Клиенты — дураки что-ли? Писали бы всё на нейтиве и уделывали бы всех.
Абсолютное большинство клиентов так и делают, ес-но.
Я же грю — есть еще HFT для бедных.
V>>·>А я не совсем понимаю как же ещё-то можно системные вещи писать? Ну там к железке какой обратиться или файлик записать... но обработка fix-протокола не системная вещь, ни разу. V>>Системный или не системный — это спекуляции. ·>Системный — платформозависимый, связанный с железом. Фин-данные тут причём?
Сейчас никакая ОС не связана с железом, они все построены на HAL.
V>>FIX-протокол содержит внутри себя транспортный + сеансовый уровень по OSI, ну типа как SSL, VPN и т.д. ·>А вот HTTP протокол тебе захочется так же гибридно имплементировать? Он того же уровня, что и FIX.
Если требуется шустрость, то берут нейтивные HTTP-серваки, ес-но.
Что сказать-то хотел?
V>>·>Не я к личности стал прикапываться. Какая разница когда и какую я искал работу? V>>Разница есть когда тебя малость заносит: ·>Ок, заносит. Но это был ответ на хамство и пустых обвинениях во лжи.
За хамство ты счел моё несогласие с тем, что Джава рулит.
Ты эта, мух от котлет отделяй, плиз.
Здравствуйте, ·, Вы писали:
V>>·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится? V>>Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом", вот так и в самописном аллокаторе С++ объекты такого размера можно сопровождать на какой-нить fall-back сценарий. ·>Ну т.е. сабж, переизобретём gc ручками.
Ну т.е. твой вопрос был неглубокий, прямо скажем. Сведения о том, как GC выделяет память под большие объекты относится к базовым по той же Джаве.
Здравствуйте, vdimas, Вы писали:
V>·>Блин, я, видимо, неоднозначно выразился. Под утечкой я не утечку памяти имел в виду, а логическую утечку данных или ссылок на них из контекста. V>Я прекрасно понял и поэтому сослался на статическую типизацию того же std::vector<>. V>В общем, поскольку ты не захотел на него посмотреть, скопирую его объявление сюда сугубо для истории аргументов:
Я знаю об аллокаторах. Говорил бы прямо, а всё то какими-то загадками и увёртками, подловить пытаешься.
V>Т.е., определив через typedef некий "региональные вектор":
А что мне помешает, передать, например, ссылку/указатель на элемент вектора куда-нибудь?
V>·>Вначале данные использовались только в рамках контекста, а теперь вдруг они нам понадобились вне контекста — и вроде бы небольшое изменение ВНЕЗАПНО становится ломающим, сложным, требующим пересмотреть архитектуру. V>Описанная техника заведомо используется там, где никакого ВНЕЗАПНО быть не может. V>Увы, увы, никакой "true agile" в таких областях IT не живет, там обитает только водопад и отсутствие внезапности.
В LMAX живёт. Релизы каждые две недели, все всё коммитят сразу в master. Кстати, java как раз очень способствует agile.
V>Там когда что-то меняется — то это совсем из-за сдвигов тектонического масштаба. Например, в Windows 8 и Server 2012 появилось новое АПИ Registered IO. Но это в любом случае голову включать надо и смотреть/экспериментировать — будут ли полезные плюшки для конкретного кейза или нет.
Причём тут API. Может поменяться бизнес-логика.
Кстати, я не даром поменял сабж. Я говорю о разных приложениях, не только HFT.
V>·>Согласен. Но я, надеюсь, что ты не будешь спорить с тем, что управление памятью значительно влияет на структуру приложения? V>Если речь об эффективности? Ес-но.
Эффективности чего? Проиводительности — нет, пусть это не будет первоочередным приоритетом.
V>Остальное ложно, бо есть такая подмеченная фигня — люди с опытом в управляемых средах поначалу испытывают трудности в С++ в определении иерархии владения. )) Городят много shared_ptr на ровном месте, ну просто тоннами. Через год уже смотришь — всё прошло. Нужные навыки въедаются в мозжечок и более не требуют мыслительных затрат.
Может быть. Именно потому что думает только мозжечок, мало кто пишет, скажем, веб-приложение на Плюсах.
V>·>Даже в Яве управление любыми ресурсами (всякими там соединениями, открытыми файлами, транзакциями, етс) вечная беда V>В C# есть using(IDisposable), а в плюсах так и вовсе RAII — наше фсё. ))
Ну в java есть try(AutoCloseable), не велика разница. Это тривиальный случай, если ресурс хорошо укладывается в синтаксический скоуп. Но когда создание отделено от освобождения (т.е. не on-stack переменная в терминах C++), то начинается шаманство.
V>>>·>в каком именно месте можно вернуть в пул (а если мы внезапно что-то решили обработать асинхронно?) V>>>Асинхронно означает "долгий процесс". В долгих процессах другие алгоритмы работы с памятью (пулы объектов, например). V>·>Вот... А java — пофиг, пиши как пишется и не надо заботиться об этих алгоритмах, ибо он один единственный — gc. V>Но именно в Джава пулы объектов сверх-популярны. Как так?
Кто тебе это сказал, что популярны?
V>>>·>Согласен, но это надо далеко не всегда. В подавляющем числе приложений компьютер прибирает достаточно хорошо, чтобы стоило заморачивать себе этим голову. V>>>Я тебе больше скажу. Даже в нейтиве описанную технику применяют ОЧЕНЬ редко. V>·>А в яве — никогда V>О чем и речь. Потому что низзя.
Можно, но нафиг нужно?
V>·>Но, насколько я слышал, аллокация памяти в Java операция быстрее, чем в С++ (по крайней мере в универсальном аллокаторе, а не в заточенном под конкретный юзкейс). V>Конечно быстрее, тем более, что дефолный хип в С++ — он многопоточный и вызывает конфликты при аллокации/деаллокации. Но как раз спасает то, что в типичном С++-приложении во многие разы меньше операций выделений памяти (я же уже расписывал — почему).
Практически любой контейнер — выделение памяти в куче. А если попытаться замутить что-то с иммутабельными объектами...
V>Большинство операций по выделению памяти в С++ можно отнести к разряду "однократных". Вот, подключились к бирже, у нас образовался объект "Сессия", отключились — исчез. По сравнению с десятками тыщ перемалываемых этой сессией событий в секунду (одиночный фид даёт до 40 тыс событий в секунду на некоторых биржах, а фидов может быть много), частоту событий создания/удаления объектов верхнего уровня (Сессий) можно принять нулевой.
На Java пишут точно так же. Не понимаю что тут особого.
V>В общем, в специфике С++ для 99% сценариев самописные аллокаторы нафик не нужны (для объекта-Сессии), но иногда возможность их использовать очень даже в кассу (для объектов-сообщений).
Ээээ. Зачем? Чем что-то типа преаллоцированного во время создания сессии List<Message> плохо?
V>·>TLS это публичное API для хранилища юзерских данных, целый контейнер. А TLAB-указатель это просто поле во внутренней структуре контекста thread, невероятно удивлюсь, если использование этого указателя занимает более пары машинных инструкций. V>Весь твой TLAB — это один из объектов, хранимых в TLS, не более того. V>Вернее, в TLS хранится указатель на TLAB.
Который именно TLS? Доказать можешь свою фантазию?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>·>Так тут меня убеждают, что c# это супер-пупер-мега-экста-максимум, голов эдак на 100 выше Java по всем фронтам. Там и великолепнейший gc есть с гениальным sustained LL mode, и struct types, и Expression Trees, linq, и stackalloc, и с 1C интегрируется, и c++/clr, чуть ли не паузы приходится расставлять, иначе производительнось c# получается выше натива; вообще: "Эй, птичка, летим со мной, там столько вкусного!!!". V>Так и есть. Осталось ко всему этому опенсорсные винды и ву а ля!
Джавекапец. Всем бояться!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>>>Ну и клиентское биржевое приложение не сильно в плане многопоточности отличается от серверного — у нас есть клиенты, которые создают многие десятки (до двух-трех сотен) подключений одновременно. V>·>Да, но микросекундные задержки рояли не играют, всё что меньше 1 секунды — никто не заметит. Да и подключения, как правило, куда угодно по миру, вплоть до пингов в сотни миллисекунд. V>Я рядом уже давал ту инфу, что крупнейшие брокеры размещены физически близко в бирже. Чаще всего — в одном здании и имеют доступ по локальной сетке к торгам. Там +- одна микросекунда уже влияет, а не секунда. ))
К физически близкой бирже две-три сотни соединений? Интересно у вас там...
V>>>Важность для каждого отдельного клиента просто катастрофическая. V>·>Как и Оутлука или какого-нибудь news-фида. V>Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто.
Но не из-за JPG иконки, инфа 146%.
V>>>·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера. V>>>Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются. V>·>Когда последний раз менялся стандарт JPEG? И сколько раз за свою жизнь? V>JPEG-LS, JPEG XR — относительно новые.
Цифирки назови. И сравни хотя бы с количеством композиций базовых стратегий/операций/условий и как часто они меняются.
V>>>По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде. V>·>Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры. V>Ну вот как раз в данных и патчат более всего.
Хотя да, согласен. В игромире тоже десяток игровых движков, а игра это по сути скрипты, да текстуры, а нативного кода пишут всё меньше, везде дураки — нет бы написали на Плюсах и порвали бы всех, ведь там библиотеки под все случаи жизни.
V>>>Та блин, я тебе как раз привел именно такой пример — необходимо снять ордера с торгов, а операция совершается с ошибкой. V>·>А я имею в виду, что гораздо хуже, когда операция завершается "успешно", но делает хрен знает что, из-за того, что итератор куда-то не туда убежал. И обнаруживается это сильно потом. V>Возможно. Но на практике проход по памяти в С++ случается на порядки реже, чем ошибки типизации в сильно динамическом джавовском коде.
Мнение. С док-вами этого фактоида возникнут трудности, не так ли?
V>>>Я ж не думал, что мне надо всё пояснять до самого конца, а именно — если ты вышел из клиентского приложения (джавовское fail-fast), это НЕ значит, что твои ордера перестали торговаться на бирже (для системы в целом нет никакого fail-fast). V>·>Если GUI глючит, обычно можно позвонить в саппорт и попросить снять ордера. V>·>В общем какая-то гипотетическая ситуация с гипотетическими проблемами, не хочу фантазировать и спекулировать. V>Ну а я тебе случай из реальной жизни привожу. V>Ты еще попробуй дозвонись, когда на бирже паника.
В таких ситуациях проблемы языка на сотом месте. Начинать надо с качества QA, а не с того, что там какие-то проблемы с типами.
V>>>Убежать за границы сильно сложнее. V>·>Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*. V>На практике отличается сильно. V>- пробежка "ручками" обычно идёт по итераторам; V>- 99% алгоритмов над вектором никакими ручками не делаются, заполнение через всякие input_iterator, обработка через пару итераторов (раньше) или напрямую сейчас (boost::range). V>Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее.
Так на практике элементарные случаи типа "for(Elem elem : elemList)" на раз оптимайзятся RangeCheckElimination.
А в нетривиальных случаях, когда RangeCheckElimination ниасиливает — человеку тоже асилить непросто. Хотя да, ведь зачем напрягать компьютер, девушки С++-сники хорошо справляются.
V>>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end(). V>·>В каких? Кто сравнивает? std::vector — не сравнивает. V>Любой алгоритм сравнивает два итератора.
Ну т.е. явно делает range check (который, кстати, может и остаться в runtime, в отличие от RangeCheckElimination).
V>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы. V>Дык, уровень косвенности на единицу меньше.
Расшифруй.
V>·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы. V>90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды.
Неправда. Скажем, в HFT-системе может быть несколько web-интерфейсов, работа с субд, гейты с разными WebService/Rest. А ещё, скажем, может быть инфраструктура мониторинга, тестирования, деплоймента и т.п. Ты правда считаешь, что native для этого лучше, чем managed??
V>А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но.
Верно. Но обратное-то не верно. Бывают и не сложные системы, которые тоже могут быть требовать.
V>>>Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность. V>·>И даже с этой полусотней работать проще из Java чем из native. V>Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. )) V>Сейчас библиотек под С++ уже просто тонны под все случаи жизни.
Ах, ну да-да, ведь все те джавовские библиотеки — испарились. И с 95-го запретили писать новые злобные С++-ники.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>·>Клиенты — дураки что-ли? Писали бы всё на нейтиве и уделывали бы всех. V>Абсолютное большинство клиентов так и делают, ес-но.
А доказать?
V>>>·>А я не совсем понимаю как же ещё-то можно системные вещи писать? Ну там к железке какой обратиться или файлик записать... но обработка fix-протокола не системная вещь, ни разу. V>>>Системный или не системный — это спекуляции. V>·>Системный — платформозависимый, связанный с железом. Фин-данные тут причём? V>Сейчас никакая ОС не связана с железом, они все построены на HAL.
Ок. Системный — связанный с операционной системой.
V>>>FIX-протокол содержит внутри себя транспортный + сеансовый уровень по OSI, ну типа как SSL, VPN и т.д. V>·>А вот HTTP протокол тебе захочется так же гибридно имплементировать? Он того же уровня, что и FIX. V>Если требуется шустрость, то берут нейтивные HTTP-серваки, ес-но.
Интересно, почему в dotnet http клиент не реализован в нативе? Шустрость не нужна разве? Ведь dotnet уже почти работает быстрее натива...
V>>>·>Не я к личности стал прикапываться. Какая разница когда и какую я искал работу? V>>>Разница есть когда тебя малость заносит: V>·>Ок, заносит. Но это был ответ на хамство и пустых обвинениях во лжи. V>За хамство ты счел моё несогласие с тем, что Джава рулит. V>Ты эта, мух от котлет отделяй, плиз.
Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора, ты ошибся с пониманием приведённого тобой документа о "closely matches" (близкие результаты), но не захотел признать свои ошибки, просто обвинив во лжи. "сам себя уже уговариваешь" никакого отношения к "Джава рулит" не имеет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, ·, Вы писали:
V>>>·>А что будет если в С++/c#-реализации вдруг окажется, что неправильно подобран размер пула аллокаторов или что-то подобное? Он магически сам пофиксится? V>>>Тогда как джаве — крупные объекты НЕ выделяются из хипа GC, они выделяются "честным образом", вот так и в самописном аллокаторе С++ объекты такого размера можно сопровождать на какой-нить fall-back сценарий. V>·>Ну т.е. сабж, переизобретём gc ручками. V>Ну т.е. твой вопрос был неглубокий, прямо скажем.
Ну собственно намёк был в том, что твоя гениальная оптимизация пулами аллокаторов уже есть в gc. Чем оправдываешь переизобретение велосипеда?
V>Сведения о том, как GC выделяет память под большие объекты относится к базовым по той же Джаве.
Прошу прощения, что я не знаю базовые понятия Джава... но можно расшифровать что такое "хип GC"? И что такое "честный образ"?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну собственно намёк был в том, что твоя гениальная оптимизация пулами аллокаторов уже есть в gc.
Намек был на твоё полное невладение предметом, вообще-то.
Сорри, намек ты не понял, поэтому пришлось написать явно.
Ну конечно, в GC такой оптимизации нет, т.к. процесс освобождения памяти крайне дорогой.
·>Чем оправдываешь переизобретение велосипеда?
Технологии современного велосипеда меняются приблизительно каждые 5 лет.
Оправдывают переизобретения тем, что иначе до сих пор на великах были бы деревянные колёса, примерно как в давным давно протухшей Джаве.
Здравствуйте, ·, Вы писали:
V>>·>Клиенты — дураки что-ли? Писали бы всё на нейтиве и уделывали бы всех. V>>Абсолютное большинство клиентов так и делают, ес-но. ·>А доказать?
Да какие проблемы? Как станете топовой конторой, так тоже будете претендовать на роль первоисточника.
Или это была просьба слить тебе базу данных клиентов?
V>>·>Системный — платформозависимый, связанный с железом. Фин-данные тут причём? V>>Сейчас никакая ОС не связана с железом, они все построены на HAL. ·>Ок. Системный — связанный с операционной системой.
Как запись в сокет? Создание потока?
Я не могу уловить, где именно ты проводишь границу. Похоже, прямо по Джаве, ы-ы-ы. ))
V>>Если требуется шустрость, то берут нейтивные HTTP-серваки, ес-но. ·>Интересно, почему в dotnet http клиент не реализован в нативе?
Потому асинхронные сокеты на IOCP реализованы в нейтиве.
·>Шустрость не нужна разве? Ведь dotnet уже почти работает быстрее натива...
Шустрость джаве нужна, конечно. Но, боюсь у меня для тебя плохие новости. В этом плане в Джаве не ожидается НИЧЕГО в ближайшие лет 10 уж точно.
V>>·>Ок, заносит. Но это был ответ на хамство и пустых обвинениях во лжи. V>>За хамство ты счел моё несогласие с тем, что Джава рулит. V>>Ты эта, мух от котлет отделяй, плиз. ·>Ты ошибся с тестом BlockingQueue, назвав его тестом дизраптора
Это ты ошибся с дисраптором, не поняв принцип его работы.
А теперь хамишь, вместо того, чтобы попросить объяснить, что там, собственно, происходит.
Тебе следовало бы читать код до просветления, как грится...
А не как тогда, когда ты дал ссылку на new Thread()
·>ты ошибся с пониманием приведённого тобой документа о "closely matches" (близкие результаты), но не захотел признать свои ошибки, просто обвинив во лжи.
Ну ты слишком много лжешь в каждом посте, чтобы я разбирался с очередным твоим набросом.
Передергиваешь, ты пытаешься как шуллер тасовать факты, задаешь вопросы исключительно в форме утверждений, как последний тролль какой-то.
Если то была цитата из ЧУЖОГО документа (не по ONIXS), то это твой косяк, ес-но, бо ты сказал, что из МОЕГО.
Т.е. тебе стоило извиниться и за свой косяк и за последующее хамство и за невнимательность, бо я до этого дал цифры порядка 6 мкс по нашему продукту. Получается, что ты нагло игноришь данные тебе цифры, а потом на голубом глазу утверждаешь, что некие протухшие 50 мкс близки к моим цифрам. Да еще требуешь извинений непонятно за что. Хорошо себя чувствуешь, эй?
Кароч, в своем рвении обелить Джаву ты многократно перегнул палку, не останавливаешься ни перед каким мухлежом, да еще пытаешься разговаривать с коллегами с высока. Поржал. ))
На неоднократные намеки-просьбы отойти от опасной границы прямого троллинга ты реагируешь слишком вяло — тебя хватает буквально на пару постов, потом ты опять тупо накидываешь невообразимой какой-то херни и передергиваний.
Ну и еще мне сложновато вести беседу с людьмы, которые, так скажем, показывают медленную реакцию. Если человеку надо объяснять более одного раза, то это уже пытка какая-то, а не обсуждение. Нуегона.
Объемы данных растут быстрее, чем улучшаются алгоритмы и соответсвенно качество работы GC.
