Здравствуйте, vdimas, Вы писали:

V>>>Чтобы не утекло, используется специфическая типизация. Например, ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса.
V>·>Причём тут типизация?
V>Чтобы не утекло.
Блин, я, видимо, неоднозначно выразился. Под утечкой я не утечку памяти имел в виду, а логическую утечку данных или ссылок на них из контекста. Вначале данные использовались только в рамках контекста, а теперь вдруг они нам понадобились вне контекста — и вроде бы небольшое изменение ВНЕЗАПНО становится ломающим, сложным, требующим пересмотреть архитектуру.

V>·>Ты тут присал "пришел запрос, ты берешь такой аллокатор из пула аллокаторов...". Вот это определяет твою архитектуру — в каком месте именно считается, что "запрос пришел"
V>Вопрос без исходников конкретного приложения лишен смысла.
Согласен. Но я, надеюсь, что ты не будешь спорить с тем, что управление памятью значительно влияет на структуру приложения? Даже в Яве управление любыми ресурсами (всякими там соединениями, открытыми файлами, транзакциями, етс) вечная беда, которую нужно аккуратно разруливать, а в С++ таким ресурсом является и память каждого объекта.

V>·>в каком именно месте можно вернуть в пул (а если мы внезапно что-то решили обработать асинхронно?)
V>Асинхронно означает "долгий процесс". В долгих процессах другие алгоритмы работы с памятью (пулы объектов, например).
Вот... А java — пофиг, пиши как пишется и не надо заботиться об этих алгоритмах, ибо он один единственный — gc.

V>·>Согласен, но это надо далеко не всегда. В подавляющем числе приложений компьютер прибирает достаточно хорошо, чтобы стоило заморачивать себе этим голову.
V>Я тебе больше скажу. Даже в нейтиве описанную технику применяют ОЧЕНЬ редко.
А в яве — никогда

V>·>А доказать?
V>·>The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions
V>А теперь посмотри на кол-во инструкций для выделения new int[16].
Ну могу поколдовать на досуге для получения ассемблерного листинга... А собственно почему ты ожидаешь, что будет что-то принципиально иное? Там даже зануление выделенной области происходит, афаик, не в момент alloc, а до этого,
Но, насколько я слышал, аллокация памяти в Java операция быстрее, чем в С++ (по крайней мере в универсальном аллокаторе, а не в заточенном под конкретный юзкейс).

V>·>TLAB != TLS.
V>На сегодня существует лишь одна технология доступа к личным данным потока в отсутствии явных зависимостей — это Thread Local Storage. А указатель на TLAB — это лишь одно из значений (одна из переменных) локальных для потока.
Ага-ага, конечно, как минимум WebService с smtp-транспортом поверх RFC 1149, не иначе.
TLS это публичное API для хранилища юзерских данных, целый контейнер. А TLAB-указатель это просто поле во внутренней структуре контекста thread, невероятно удивлюсь, если использование этого указателя занимает более пары машинных инструкций.

Здравствуйте, Ikemefula, Вы писали:

I>>>·>Круто, чё, молодцы. Осталось показать это в деле. Жду новый успешно выстреливший стартап на .net core, который заборет все эти тормозные явы. У вас ведь даже фора есть, ведь все ява-разработчики давно уморены долгим нарезанием памяти, .net — вперёд!
I>>>Фора есть у джавы — дотнет тупил 10 лет. Так что будет очень плавный выход.
I>·>Плохая отмаза. У нейтива фора была лет 30 в своё время, если не больше, но это не помешало Яве выстрелить.
I>Не было никакой форы, кучу софта было просто не выгодно писать, об указатели постоянно спотыкались.
Вот именно! java предложила киллер-фичу — managed, решила проблему сломанных указателей и некоторые другие, поэтому даже 30+ лет фора не послужила помехой.
А вот dotnet-у придётся тяжело, ибо он не предлагает ничего принципиально нового, никаких серьёзных проблем не решает, и это 10-летнее отставание может стать фатальным.

Здравствуйте, ·, Вы писали:

V>>·>Теоретически некий код на java и с++ может выдавать идентичный машкод. Никто не запрещает.
V>>Система типов запрещает.
·>Каким образом? Думаешь a+b не будет выражено в виде обычного add-машкода?

Вт эта последовательность:

buf.setFloat(c) = buf.getFloat(a) + buf.getFloat(b);

?
Уверен, там будет чуть больше, чем аналогичное с=a+b в нейтиве.


·>Что собственно не удивительно, т.к. эти цифры находятся в микросекундном диапазоне (IO скорее всего), а время процессинга где-то в области наносекунд, т.к. даже отличие в машкодах вряд ли сыграет заметную роль.

IO — это порядка 2 мкс в среднем на одну операцию, их две в полном цикле, а ты процитировал "30-50 мкс". Не сходится.

Здравствуйте, Ikemefula, Вы писали:

I>>>Может, если узкое место это, скажем, сетевая карта. А если узкое место это процессор, то джаве до нейтива как до луны раком.
I>·>Допустим. А если вспомнишь сабж? Чем dotnet в этом смысле лучше?
I>У дотнета с локальностью данных гораздо лучше, запросто так: value type, generics, fixed и stackalloc. Может еще чтото появилось, не в курсе, 4 года как ушел.
А есть какие-то бенчмарки, сравнения, что это действительно работает лучше чем java JIT?

I>·>Нет. Мы сравниваем c# и java. Java-only приложений полно. А вот c#-only без помощи той же java всё как-то печальнее. Почему тот же самый elasticsearch написан именно на Яве? Ведь c# во всём лучше!?. Начат проект elasticsearch в 2010, в это время c# уже цвёл и пах во всю.
I>elastic search, внимание, основан на lucene, который внимание, появился ажно в 99м году и был открыт сразу же.
Ну вообще-то естьбыл порт Lucene.Net, появился ажно в марте 2000-го, но, похоже, совсем издох в 2012 в стадии RC.

I>Соответственно, причины
I>1 в закрытости винды и в том, что дотнет был прибит к ней гвоздями
Так это не закон природы, а идиотское решение MS. Максимум можно сказать, что дотнету просто не позезло с родителем. Sun вон не стал жмотиться и усаживать всех на свой SunOS.

История не терпит сослагательного наклонения, но мне кажется, если бы MS изначально пилили первоклассные дев-тулы под Винду (Студия в то время была лучшей IDE), но позволяли запускать программы везде — java такой конкуренции могла бы и не выдержать, а они очухались только сейчас со своими .net core, mssql for linux, WSL, etc, более чем удвоили фору, упустили все полимеры.

I>2 фора в более чем 10 лет
Это уже обсудили.

Здравствуйте, ·, Вы писали:

·>Сборка мусора она разная бывает. Тут уже упоминали поколения. Сборка молодого поколения практически бесплатна.

Она то бесплатна, только гц тебе не скажет, остается ли он в рамках нулевого поколения или нет.

Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально

Здравствуйте, ·, Вы писали:

V>>>>Опять загоняешь, кароч.
V>>·>JPG-иконки и HFT? Хм... Я промолчу.
V>>В клиентской проге? Именно так.
·>В какой клиентской проге? HFT для роботов, а не для человеков.

Роботов надо удобно программировать в GUI и отслеживать текущую картинку.
Ну и "большая красная кнопка Stop" — как же без неё? Вот тебе и графический декодер большой красной иконки. ))

Ну и клиентское биржевое приложение не сильно в плане многопоточности отличается от серверного — у нас есть клиенты, которые создают многие десятки (до двух-трех сотен) подключений одновременно.


·>А любые клиентские проги в HFT не важнее как Оутлука.

Важность для каждого отдельного клиента просто катастрофическая.


·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера.

Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются. В третьих, ЛЮБЫЕ "алгофичи" торговых роботов задаются как композиция базовых стратегий/операций/условий, т.е. фактически декларативно из небольшого набора простых отлаженных кирпичиков.


V>>Летающая корова не противоречит законам физики, если из скрипта ей задали параметры как у воздушного шарика. ))
·>Всяко бывает. В старых играх без скриптов глитчей не было? Что ты хочешь доказать-то? Игроделы — идиоты, должны выкинуть скрипты и писать на Плюсах?

По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде.


V>>Да нормальный аргумент. Если имеем исключение при выходе за диапазон, то это не значит, что прога стала работать лучше. Всё-равно нужную операцию совершить не удастся.
·>fail-fast — важный критерий оценки качества.

Та блин, я тебе как раз привел именно такой пример — необходимо снять ордера с торгов, а операция совершается с ошибкой.
Я ж не думал, что мне надо всё пояснять до самого конца, а именно — если ты вышел из клиентского приложения (джавовское fail-fast), это НЕ значит, что твои ордера перестали торговаться на бирже (для системы в целом нет никакого fail-fast).


V>>·>Это лучше, если операцию совершить невозможно, да ещё и с громким бабахом, чем если бы совершилась втихую какая-то другая операция.
V>>Однако, в С++ принято бегать итераторами по коллекциями.
·>И что? Какая разница?

Убежать за границы сильно сложнее.


V>>>>И это я еще не даже не начинал спрашивать, где ты видел в плюсах выходы за границы. Не в С, а именно в С++. Мне было бы ОЧЕНЬ любопытно взглянуть на пойманную такую хрень в реальном коде, это была бы сенсация.
V>>·>Разве оператор std::vector[] проверяет границы в проде? Или вы боитесь делать релизные сборки?
V>>А разве кто-то использует индекс в векторе вместо итератора?
·>Ты хочешь меня обмануть, надеясь, что я Плюсы не знаю? Итераторы за границы могут выходить на ура

Так и ты в свой байт-буфер может мимо написать, в отсутствии статической типизации.
Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().


V>>·>Какие советы?
V>>Про ценность JNI. Выглядит так, что ты еще не сильно любопытствовал устройство многих джавовских системных библиотек, которые поверх JNI писаны. Вот как полюбопытствуешь, так приходи.
·>Да, это полный кашмар! Но это ещё не всё, я тебе открою страшную тайну: java на Плюсах написана.

Сам движок? Ну так это совсем другое дело. Например, Java-машинка знает многие базовые джавовские типы "в лицо" (string, array и т.д.) и обращается с ними вполне типизированно, т.е. безопасно и эффективно — через типизированное отражение их разметки в памяти на соответствующие нейтивные структуры. Это на психику не давит, в отличие от нейтивного АПИ динамической типизации Джава-машинки. Вот как раз писать и читать из ByteBuffer, эмулируя "плоские структуры", — примерно того же уровня задачка. Т.е. всё держится на честном слове, а не на контроле компилятора.


·>Я понял что ты говоришь, но ты, похоже, не понял моё возражение. Первое твоё предложение верно, второе — нет. HFT-система — большое число простых задач + небольшое число сложных.

Да не понял ты меня. Я говорил, что твоя оценка насчет "большое число" — неверная. Число задач в HFT относительно небольшое. Относительно тех же программ для складов/бухгалтерий. Просто довелось несколько лет работать в области автоматизации предприятий и я хорошо знаю, о чем говорю. Например, в типичной снапшотовой БД огромнейшей популярной биржи будет примерно 3-4 десятка таблиц всего, в то время как в самой несчастной бухгалтерии+складе — примерно 3-4 сотни. А если система учета не несчастная, а вполне себе на уровне, то и до тысячи таблиц и выше аж бегом.


·>HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач.

Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность.


·>Или ты хочешь сказать, что если в некой системе информационная сложность меньше бухгалтерии, то ява для такой системы будет работать как-то плохо?

Я говорю о том, где именно рулят управляемые среды.


V>>·>Ты так говоришь, как будто это что-то плохое.
V>>Если конечная система состоит из туевой хучи некритичных простейших модулей, то это даже хорошо.
·>А когда над критичной системой могут работать не только семи-пядевые гении, а обычные смертные, т.к. она состоит из простейших модулей — это огромный плюс.

Ну вот поэтому в каждой сложной системе есть как минимум два уровня — "ядерный" и "прикладной".

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, ·, Вы писали:

V>>>·>Теоретически некий код на java и с++ может выдавать идентичный машкод. Никто не запрещает.
V>>>Система типов запрещает.
V>·>Каким образом? Думаешь a+b не будет выражено в виде обычного add-машкода?
V>Вт эта последовательность:
V>

V>buf.setFloat(c) = buf.getFloat(a) + buf.getFloat(b);
V>

V>?
V>Уверен, там будет чуть больше, чем аналогичное с=a+b в нейтиве.
А я не уверен, там полно intrinsic (у azul кстати свои таблицы интринзиков, но я исходники его не видел) и хороший оптимизатор, надо обязательно смотреть сгенерённый машкод, не знаю как ты, я плоховато умею в уме код компилировать и JIT-ить. И не забывай, что buf это прочитанный или отправляемый в сеть пакет, а значит как в java, так и в С++ будут конвертации блока байт в машинное представление float, если endianness или alignment не совпадает.

V>·>Что собственно не удивительно, т.к. эти цифры находятся в микросекундном диапазоне (IO скорее всего), а время процессинга где-то в области наносекунд, т.к. даже отличие в машкодах вряд ли сыграет заметную роль.
V>IO — это порядка 2 мкс в среднем на одну операцию,
Правильно, целых 2 микросекунды! А порядок даже лишних индирекций, промахов по L1/L2-кешам и сотен "лишних" маш-инструкций будет в районе сотни наносекунд максимум.

V> их две в полном цикле, а ты процитировал "30-50 мкс". Не сходится.
Ну это я уже так глубоко не лез, 30-50 мкс выдавал и С++-ый код. Хочешь — разбирайся почему С++ таак тормозил. Суть в том, что время то же, что и в java-реализации.

Здравствуйте, Ikemefula, Вы писали:

I>·>Сборка мусора она разная бывает. Тут уже упоминали поколения. Сборка молодого поколения практически бесплатна.
I>Она то бесплатна, только гц тебе не скажет, остается ли он в рамках нулевого поколения или нет.
Скажет посредством gc-логов.

I>Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально
off-heap решения для огромных куч, для старого поколения, а не для молодого. Кстати, с развитием GC необходимость off-heap решений падает.

Здравствуйте, ·, Вы писали:

I>>>>Фора есть у джавы — дотнет тупил 10 лет. Так что будет очень плавный выход.
I>>·>Плохая отмаза. У нейтива фора была лет 30 в своё время, если не больше, но это не помешало Яве выстрелить.
I>>Не было никакой форы, кучу софта было просто не выгодно писать, об указатели постоянно спотыкались.
·>Вот именно! java предложила киллер-фичу — managed, решила проблему сломанных указателей и некоторые другие, поэтому даже 30+ лет фора не послужила помехой.

Алё — не было никакой форы. Ибо переход native-managed. Новая экономическая ниша и конкуренты у джавы отсутствовали !

·>А вот dotnet-у придётся тяжело, ибо он не предлагает ничего принципиально нового, никаких серьёзных проблем не решает, и это 10-летнее отставание может стать фатальным.

А здесь — есть. managed-managed. На самом деле это не так страшно, как кажется. Дотнет практически всегда в качестве догоняющего. Более того, IIS из нуля откусил долю рынка аккурат за счет дотнета.

Здравствуйте, ·, Вы писали:

I>>Она то бесплатна, только гц тебе не скажет, остается ли он в рамках нулевого поколения или нет.
·>Скажет посредством gc-логов.

Ну увидел ты логи. Чем это поможет текущему инстанцу сервера ? Твои действия ?
Представляю

   if(logs.gc.oldGeneration.size() > limit) { 
       forceFutureUseYounGeneration(Since.Now()) 
       moveOldToYoung(Options.ZeroTimePenalty()) 
       startWorkingFaster(Times(10))
   }

I>>Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально
·>off-heap решения для огромных куч, для старого поколения, а не для молодого. Кстати, с развитием GC необходимость off-heap решений падает.

Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении.
Как только ты перебрал определенный лимит, часть объектов уходит в старое поколение и ты на это никак повлиять не можешь

То есть, off-heap нужен для того, что бы исключить gc по максимуму

Здравствуйте, vdimas, Вы писали:

V>·>В какой клиентской проге? HFT для роботов, а не для человеков.
V>Роботов надо удобно программировать в GUI и отслеживать текущую картинку.
V>Ну и "большая красная кнопка Stop" — как же без неё? Вот тебе и графический декодер большой красной иконки. ))
С иконкой вряд ли сможет случиться беда, незамеченная на этапе разработки, ибо это константная картинка. Вот какие-то генерируемые по текущим данным графики, да...

V>Ну и клиентское биржевое приложение не сильно в плане многопоточности отличается от серверного — у нас есть клиенты, которые создают многие десятки (до двух-трех сотен) подключений одновременно.
Да, но микросекундные задержки рояли не играют, всё что меньше 1 секунды — никто не заметит. Да и подключения, как правило, куда угодно по миру, вплоть до пингов в сотни миллисекунд.

V>·>А любые клиентские проги в HFT не важнее как Оутлука.
V>Важность для каждого отдельного клиента просто катастрофическая.
Как и Оутлука или какого-нибудь news-фида.

V>·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера.
V>Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются.
Когда последний раз менялся стандарт JPEG? И сколько раз за свою жизнь?

V>В третьих, ЛЮБЫЕ "алгофичи" торговых роботов задаются как композиция базовых стратегий/операций/условий, т.е. фактически декларативно из небольшого набора простых отлаженных кирпичиков.
Сам ведь знаешь, что сложность композиции компонент не означает простое сложение их сложности.

V>>>Летающая корова не противоречит законам физики, если из скрипта ей задали параметры как у воздушного шарика. ))
V>·>Всяко бывает. В старых играх без скриптов глитчей не было? Что ты хочешь доказать-то? Игроделы — идиоты, должны выкинуть скрипты и писать на Плюсах?
V>По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде.
Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры.

V>>>Да нормальный аргумент. Если имеем исключение при выходе за диапазон, то это не значит, что прога стала работать лучше. Всё-равно нужную операцию совершить не удастся.
V>·>fail-fast — важный критерий оценки качества.
V>Та блин, я тебе как раз привел именно такой пример — необходимо снять ордера с торгов, а операция совершается с ошибкой.
А я имею в виду, что гораздо хуже, когда операция завершается "успешно", но делает хрен знает что, из-за того, что итератор куда-то не туда убежал. И обнаруживается это сильно потом.

V>Я ж не думал, что мне надо всё пояснять до самого конца, а именно — если ты вышел из клиентского приложения (джавовское fail-fast), это НЕ значит, что твои ордера перестали торговаться на бирже (для системы в целом нет никакого fail-fast).
Если GUI глючит, обычно можно позвонить в саппорт и попросить снять ордера.
В общем какая-то гипотетическая ситуация с гипотетическими проблемами, не хочу фантазировать и спекулировать.

V>>>Однако, в С++ принято бегать итераторами по коллекциями.
V>·>И что? Какая разница?
V>Убежать за границы сильно сложнее.
Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*. Можно, конечно at() использовать, но редко наблюдал на практике...

V>>>>>И это я еще не даже не начинал спрашивать, где ты видел в плюсах выходы за границы. Не в С, а именно в С++. Мне было бы ОЧЕНЬ любопытно взглянуть на пойманную такую хрень в реальном коде, это была бы сенсация.
V>>>·>Разве оператор std::vector[] проверяет границы в проде? Или вы боитесь делать релизные сборки?
V>>>А разве кто-то использует индекс в векторе вместо итератора?
V>·>Ты хочешь меня обмануть, надеясь, что я Плюсы не знаю? Итераторы за границы могут выходить на ура
V>Так и ты в свой байт-буфер может мимо написать, в отсутствии статической типизации.
V>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().
В каких? Кто сравнивает? std::vector — не сравнивает.

V>>>Про ценность JNI. Выглядит так, что ты еще не сильно любопытствовал устройство многих джавовских системных библиотек, которые поверх JNI писаны. Вот как полюбопытствуешь, так приходи.
V>·>Да, это полный кашмар! Но это ещё не всё, я тебе открою страшную тайну: java на Плюсах написана.
V>Сам движок? Ну так это совсем другое дело. Например, Java-машинка знает многие базовые джавовские типы "в лицо" (string, array и т.д.) и обращается с ними вполне типизированно, т.е. безопасно и эффективно — через типизированное отражение их разметки в памяти на соответствующие нейтивные структуры. Это на психику не давит, в отличие от нейтивного АПИ динамической типизации Джава-машинки. Вот как раз писать и читать из ByteBuffer, эмулируя "плоские структуры", — примерно того же уровня задачка. Т.е. всё держится на честном слове, а не на контроле компилятора.
Нет, String это обычный plain-java класс поверх "char[]", ArrayList — тоже, поверх Object[]. Нативные штуки там есть для работы с примитивными типами данных "char[]" (типа System.arraycopy), "Object" и системными штуками типа FileSystem и т.п.
В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

V>·>Я понял что ты говоришь, но ты, похоже, не понял моё возражение. Первое твоё предложение верно, второе — нет. HFT-система — большое число простых задач + небольшое число сложных.
V>Да не понял ты меня. Я говорил, что твоя оценка насчет "большое число" — неверная. Число задач в HFT относительно небольшое. Относительно тех же программ для складов/бухгалтерий. Просто довелось несколько лет работать в области автоматизации предприятий и я хорошо знаю, о чем говорю. Например, в типичной снапшотовой БД огромнейшей популярной биржи будет примерно 3-4 десятка таблиц всего, в то время как в самой несчастной бухгалтерии+складе — примерно 3-4 сотни. А если система учета не несчастная, а вполне себе на уровне, то и до тысячи таблиц и выше аж бегом.
Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.

V>·>HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач.
V>Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность.
И даже с этой полусотней работать проще из Java чем из native.

Здравствуйте, ·, Вы писали:

·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.

С другой стороны, строки получились адски быстрыми и до кучи целая пачка апишных функции работает крайне быстро, фактически, без прослойки в виде интеропа.
В джаве же будет пенальти. Собтсвенно этот пенальти и наблюдаем на виндовозных джава-приложениях

Здравствуйте, Ikemefula, Вы писали:

I>>>Не было никакой форы, кучу софта было просто не выгодно писать, об указатели постоянно спотыкались.
I>·>Вот именно! java предложила киллер-фичу — managed, решила проблему сломанных указателей и некоторые другие, поэтому даже 30+ лет фора не послужила помехой.
I>Алё — не было никакой форы. Ибо переход native-managed. Новая экономическая ниша и конкуренты у джавы отсутствовали !
Само по себе "managed" не является причиной перехода. А именно то, что managed даёт ощутимые game changing преимущества, которые перевешивают недостатки. Ты хочешь сказать, что у c# вообще никаких преимуществ перед java нет, дык об чём речь тогда?

I>·>А вот dotnet-у придётся тяжело, ибо он не предлагает ничего принципиально нового, никаких серьёзных проблем не решает, и это 10-летнее отставание может стать фатальным.
I>А здесь — есть. managed-managed. На самом деле это не так страшно, как кажется. Дотнет практически всегда в качестве догоняющего. Более того, IIS из нуля откусил долю рынка аккурат за счет дотнета.
Так тут меня убеждают, что c# это супер-пупер-мега-экста-максимум, голов эдак на 100 выше Java по всем фронтам. Там и великолепнейший gc есть с гениальным sustained LL mode, и struct types, и Expression Trees, linq, и stackalloc, и с 1C интегрируется, и c++/clr, чуть ли не паузы приходится расставлять, иначе производительнось c# получается выше натива; вообще: "Эй, птичка, летим со мной, там столько вкусного!!!".

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, ·, Вы писали:

I>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

I>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.

Ну в .Net Core https://github.com/dotnet/coreclr/blob/32f0f9721afb584b4a14d69135bea7ddc129f755/src/mscorlib/src/System/String.cs
Нет привязки к винде.
Но есть метод unsafe internal int ConvertToAnsi(byte *pbNativeBuffer, int cbNativeBuffer, bool fBestFit, bool fThrowOnUnmappableChar)
который использует

 fixed (char* pwzChar = &this.m_firstChar) 
             { 
                 nb = Win32Native.WideCharToMultiByte( 
                     CP_ACP, 
                     flgs, 
                     pwzChar, 
                     this.Length, 
                     pbNativeBuffer, 
                     cbNativeBuffer, 
                     IntPtr.Zero, 
                     (fThrowOnUnmappableChar ? new IntPtr(&DefaultCharUsed) : IntPtr.Zero)); 
             }

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, ·, Вы писали:

I>>>Она то бесплатна, только гц тебе не скажет, остается ли он в рамках нулевого поколения или нет.
I>·>Скажет посредством gc-логов.
I>Ну увидел ты логи. Чем это поможет текущему инстанцу сервера ? Твои действия ?
I>Представляю
I>
Ну почти, если тормоза будут упущены на этапе perf tests, то можно будет прод-сервак перезапустить с другими параметрами gc (изменить размер YG или возраст отправки в OG, например).

I>>>Собтсвенно именно это и есть основание для применения off-heap решений. Гарантии вот этой бесплатности надо обеспечить руками за счет исключения гц вообще, тотально
I>·>off-heap решения для огромных куч, для старого поколения, а не для молодого. Кстати, с развитием GC необходимость off-heap решений падает.

I> Ты в одном сообщении умудряешься сам себе противоречить. Если твоя софтина не вылазит за пределы нулевого поколения, ей off heap не нужен. off heap нужен не для поколений, а для того, что бы gc бегал исключительно по объектам молодого поколения. Для этого надо руками гарантировать небольшое количество выделений в молодом поколении.
I>Как только ты перебрал определенный лимит, часть объектов уходит в старое поколение и ты на это никак повлиять не можешь
Который из gc? minor gc не так страшен.

I>То есть, off-heap нужен для того, что бы исключить gc по максимуму
Нет, он нужен чтобы изменение графа объектов в OG не вызывал известно бесполезные, но болезненные major gc.

Здравствуйте, Ikemefula, Вы писали:

I>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
I>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.
Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Ikemefula, Вы писали:

I>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
I>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.
·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe.
А что плохого? Это же стандартные вылизанные библиотеки. Не надо мучиться компилятору для оптимизации.
Многие в нативе вообще ассемблерные вставки используют.

Здравствуйте, Serginio1, Вы писали:

I>>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
I>>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.
S>·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe.
S> А что плохого? Это же стандартные вылизанные библиотеки. Не надо мучиться компилятору для оптимизации.
Это может говорить о качестве такого компилятора, то что для него это — мучение. Правильно, как там vdimas упомянул? "зачем мучить компьютер компиляцией, когда у нас есть девушки".
Если придётся по какой-то причине понадобится реализовать похожий алгортим самому, в своём коде — компилятор тоже не осилит, и здравствуй unsafe, каша из топора.

S>Многие в нативе вообще ассемблерные вставки используют.
Если вставки для системных вещей — ок, если для прикладных, — не ок.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Serginio1, Вы писали:

I>>>>·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.
I>>>>Да, это одна из проблем. В винде сплошной блудняк со строками и вот такими вот "гвоздями" товарищи и прибили дотнет к винде.
S>>·>Негодная отмаза. Array.cs выглядит ничем не лучше, даже sort ниасилили запилить без unsafe.
S>> А что плохого? Это же стандартные вылизанные библиотеки. Не надо мучиться компилятору для оптимизации.
·>Это может говорить о качестве такого компилятора, то что для него это — мучение. Правильно, как там vdimas упомянул? "зачем мучить компьютер компиляцией, когда у нас есть девушки".
·>Если придётся по какой-то причине понадобится реализовать похожий алгортим самому, в своём коде — компилятор тоже не осилит, и здравствуй unsafe, каша из топора.

Вот для .Net Native можно писать как угодно. Там скорость компиляции не важна. А вот jit малооптимизирующий компилятор.
S>>Многие в нативе вообще ассемблерные вставки используют.
·>Если вставки для системных вещей — ок, если для прикладных, — не ок.
Так String это чуть ли не основной класс. Его стоит вылизать. То есть на C++ это нормально, а для C# это нонсенс.
Это же касается и Array.
Этих классов совсем немного, но они как раз находятся в пространстве System

Но кстати сейчас идет работа по оптимальной компиляции в IL код
http://rsdn.org/forum/dotnet/6572465.1

Автор: Serginio1
Дата: 05.10.16

То есть вполне возможно появление компилятора, который будет оптимизировать код в MSIL
инлайнить, разворачивать Linq итд

Здравствуйте, Serginio1, Вы писали:

S>>>·>Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти?
S>>> Нативный менеджер не делает дефрагментацию. Вот тебе пример дельфёвого менеджера памяти https://rsdn.org/article/Delphi/memmanager.xml

Автор(ы): Андрей Мистик
Дата: 21.02.2003
В данной статье я постараюсь в общих чертах описать принципы работы менеджера памяти Delphi.
Зачем это нужно? Ведь, казалось бы, работает себе и работает, зачем его трогать? Это нужно по нескольким причинам. Во-первых, никогда не помешает разбор чужого кода, особенно если это грамотный код. Это возможность научиться чему-либо новому, а также получить эстетическое наслаждение. Во-вторых, никогда не лишне поглубже разобраться в чем-то, убедиться в тех вещах, в которых вы ранее не были уверены или же, наоборот, найти слабые места, о которых вы ранее и не подозревали, чтобы в будущем писать более эффективный код.

S>·>Эээ... И что? Я не понимаю тебя. Не делать дефрагметацию — это плохо. Память закончиться внезапно может. Менеджер памяти не делающий дефрагментацию — плохой, негодный менеджер. Приходится под него подстраиваться.
S> Ну так на этом все нативные менеджеры построены. И ведь работают. А для твоего теста они подходят лучше всего. Просто в .Net ты можешь комбинировать.
Ты не понял. То что в нативных менеджерах нет дефрагментации — это недостаток, ибо её реализовать невозможно, т.к. объекты неперемещаемые. В managed же объекты можно перемещать, компактифицируя кучу, делая её более cache friendly и прочее. Если тебе тупо не нужна дефрагметация кучи в gc, ты её можешь тупо отключить одним флажочком.

S>>>·>А зачем нужен бессмысленный тест?
S>>>Это ответ на то как поможет нативный менеджер памяти.
S>·>Он использует локи, критические секции, что практически не допустимо для LL.
S> Можно так же использовать все те же interlockedexchange. Этих менеджеров памяти достаточно много. https://habrahabr.ru/company/billing/blog/238787/
Таким же образом может помочь выбор gc-алгоритма и параметров.

S>>>·>Ок, подытожу.
S>>>·>Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира).
S>>>·>Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
S> Ну это нужно сравнивать в тестах. Что лучше.
Сравнивать в тестах что? Упрощение ЖЦ проекта??

S>>> Ну Vdimas то использует 1 язык. Просто есть манагед классы и унманагед. А вообще мне приходится писать на 3 языках. И ничего.
S>·>Нет, он сказал, что там C# и нативный C++ код. Ну, по крайней мере, я его так понял.
S> Ну можно писать и на нескольких языках если команда большая. Делать смешанные классы на C++, а использовать их на всех других нетовских языках. Сейчас F# продвигается активно.
Можно, но не нужно. К тому же на java никто не запрещает использовать C++ и прочие активно продвигаемые scala/kotlin/ceylon/closure/groovy/etc.