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

·>Собственно в точности похоже на вручную организованный young gc space. Только вместо того, чтобы компьютер сам искал объекты

Что не бесплатно.

·>что является "контекстом запроса" приходится организовывать архитектуру приложения соответственным образом и внимательно следить, чтобы ничего из этого контекста не утекло куда не надо.

Чтобы не утекло, используется специфическая типизация. Например, ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса.


V>>Никаких тебе shared/unique и прочих _ptr, тупо голые указатели и ссылки. ))
V>>Как тебе такой алгоритм уборки "мусора"?
·>Закат солнца вручную.

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


V>>По последней операции тоже любопытное замечание: ввиду того, что в плюсах почти всё инлайно, то даже этот несчастный аргумент для приращения указателя "виден" оптимизатору. Источником этого аргумента обычно выступает явная (аналог malloc) или неявная (аналог new) операция sizeof, а эта операция возвращает константу времени компиляции. Т.е., даже эта несчастная операция увеличения курсора внутри страницы максимально эффективна из всех возможных вариантов — к указателю прибавляется константа. ))
·>Собственно прибавление указателя это и есть способ аллокации в java.

Ну да, всего-то ~200 машинных инструкций на каждую аллокацию вместо 3-4-х. В зависимости от вида применённого GC, джаве порой сначала надо достать текущий аллокатор из TLS, что порой еще дороже выходит.


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

Еще раз. Медленно. Доставать по всей иерархии аллокатор из TLS очень дорого (всё относительно, может для реальности Джавы и не дорого, фиг его знает ).

Но в нейтиве дешевле протянуть контекст явно, потому что порядок цифр другой и TLS начинает влиять. Но в некоем месте "разрыва" своего кода вполне можно выкрутиться, восстановив контекст.

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

V>>·>Понятно. Я и имею в виду, что код на java может давать те же показатели, что и нейтив решение.
V>>Тебя и поправили — если нейтивный код такой заведомо плохой. Иначе не может.
·>Теоретически некий код на java и с++ может выдавать идентичный машкод. Никто не запрещает.

Система типов запрещает.


·>А фактически ты же сам привёл документ, в котором сказано, что C++ и Java близки. Там был плохой C++?

Я уже тебя поправлял — близки по логике реализации, а не по быстродействию.

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

·>Тему о быстродействии я не поднимал и спорить не хочу, ибо это бессмысленный холивар. Я возразил о HFT, для которого критичным является low latency. И в этой области факты показывают, что Java преуспевает гораздо лучше c#.

Ты не привёл таких никаких фактов от слова совсем.
Данные по быстродействию где?


·>Если ты не понимаешь разницу между быстродействием и LL перечитай топик внимательно. Я несколько раз это объяснял.

Я согласен на голый latency, жду цифры.


·>Гибридные C++/Java решения тоже есть. Но они тоже не интересны, ибо Java является просто ничего не делающей обёрткой. А "гибридные нейтивно-дотнетные решения" появились чисто из чувства прекрасного? Или таки из-за того что чистое решение тупо не работает?

Ты решил дожать оппонентов, что ле?
Еще раз. Гибридные появились из-за того, что уделывают расово-чистые.
Никаких других причин тут нет, ес-но.

Почему в Джаве мало гибридных решений — тоже уже указал тебе, потому что JNI — это издевательство над психикой. За ту же трудоёмкость выгодней уже чисто-нейтивные решения лабать. И напротив, в дотнете сложные гибридные решения — это не хитровымученные (и при этом тупые обертки, на пример JNI), это почти всегда вполне полезный код, просто писанный на C++/CLR. Прямо в исходнике идёт оперирование в родной статической типизации, в отличие от JNI, где мы общаемся с нейтивным АПИ динамической типизации джава-машинки. Разница тут в и эффективности и в контроле компилятором над происходящем просто колоссальная.

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


V>>* Этому некто сначала весьма вежливо говорят: "гхм, извините, но гибридность была выбрана исключительно по тем соображениям, что такое решение получается в три раза шустрее расово-чистого варианта, а в HFT кроме шустрости никого не интересует никакая романтика расовой чистоты". В ответ на сей вполне осмысленный аргумент этот некто решил стать в позу: "вывсёвсеврети! просто вы ниасилили HFT на расово-чистом дотнете!".
·>Т.е. ты хочешь меня убедить, что гибридное Java/C++ решение невозможно или что?

Я хочу сказать, что оно по трудоёмкости часто переплюнет чистый С++, т.е. смысла брать Джаву уже не будет. Неужели ты до сих пор не понял те причины, по которым современная реальность IT устроена так, а не иначе? ))


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

Зачем? Если ты действительно не понял этот абзац — ОК, я просто приму сие к сведению и не буду более аргументировать в эту сторону.


V>>Как ты думаешь, когда я своим детям хрен его знает сколько лет назад памперсы менял, мне их тоже благодарить надо было?
·>Что ты вокруг, да около? Не держи в себе, говори уж, сколько сантиметров?

Так а чего я-то? Не я эту херню начал.

Раз в пять лет обязательно кто-нить сподобиться с одним и тем же — на колу мочало, начинай сначала.

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

V>·>Ну начнём, с того что в джаве нет UB.
V>На большинство UB ругается компилятор в С++.
Ох вечный холивар. Я пас. Давай обсуждать сабж.

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

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

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

V>>>·>Пропажа одного ордера — можно попрощаться с бизнесом.
V>>>Бывает намного хуже — невозможно снять ордер с торгов, а сильно надо. А джавовская прога заглючила.
V>·>И тут приходит С++ и всех спасает. Угу-угу.
V>Статическая типизация, действительно, много где спасает.
А иногда не спасает.
managed код тоже много где спасает.

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

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

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

V>>>·>А бывают и не сложнее.
V>>>Достаточно того, что бывают сложнее.
V>·>Недостаточно.
V>Ну вот ты и проиграл спор.
V>Путать необходимое с достаточным — это сильно. ))
Достаточно для чего? Чтобы JNI не использовать? Нет, не достаточно. Где какая необходимость?

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

V>>>По современным меркам типичная с полным комплексом фишек, с клирингом, со встроенными стратегиями и т.д. и т.п. HFT-система не дотягивает по информационной сложности даже до рабочего места индивидуального предпринимателя с личной бухгалтерией и складом на 1С.
V>·>И что? Странное у тебя возражение. Я говорю, что java хорошо подходит для hft-системы, а ты мне возражаешь, что бухгралтерия. Спасибо, понятно, а в киеве дядька.
V>Сосредоточься:
V>

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

Я понял что ты говоришь, но ты, похоже, не понял моё возражение. Первое твоё предложение верно, второе — нет. HFT-система — большое число простых задач + небольшое число сложных. HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач.
Или ты хочешь сказать, что если в некой системе информационная сложность меньше бухгалтерии, то ява для такой системы будет работать как-то плохо?

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

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

V>·>Может и "как правило", но не обязательно (собственно как и в C++). Просто не делай так если важно LL.
V>А как делать?
V>В публичном интерфейсе все-равно джавовские строки будут торчать, иначе как клиентское приложение будет работать?
Зачем в LL фин-данных строки? Клиенсктое приложение обычно не только на другом хосте работает, но и в другой сети и прямого доступа к LL-ядру не имеет. А что там клиентское приложение при получении сетевого пакета соорудит себе строчку — пофиг, клиентское приложение по определению не HFT, человек тупо физически не может заметить задержки меньше 100мс.

V>>>Плюсы — это мультипарадигменный язык, позволяющий играть дизайном как душе будет угодно. Виртуальные ф-ии нужны исключительно для абстрактных типов, ну или заменой им можно считать лямбды и прочие std::function.
V>>>Вот у тебя некий пост-процессор данных может быть таким абстрактным функциональным типом, но через это пост-процессор прогоняются вполне себе "плоские" данные. Стоимость вызова std::function примерно равна стоимости одного виртуального вызова, т.е. порядка 2-3ns в цикле для современной техники.
V>·>Ок. А можно ближе к сабжу?
V>Ближе некуда — используй наиболее подходящую парадигму под каждый сценарий или их сочетания.
Где в C# std::function? Мы вроде dotnet обсуждаем. К чему все эти пассажы про Плюсы?

V>>>Да не работает оно. Индексы разметки все-равно в виде ref-типов хранятся.
V>·>Ну например индекс разметки [FIX tag]->[позиция в буфере сообщения] может храниться как "new int[65536]" (tag id в fix == 2 байта) и этот самый массив в единственном экземпляре может жить в gen2 и в кеше вечно.
V>Это на каждый экземпляр сообщения по такому индексу создавать?
Зачем тебе хранить все FIX сообщения в памяти? Храни текущее, обновляй индексы, выполняй бизнес-логику, буферы реюзай под следующее.

V>Дисраптор — это межпоточные lock-free контейнеры для бедных, там в публичном интерфейсе этих контейнеров ничего сложного и не должно быть.
V>Ты же говорил, что в С++ код будет страшный в случае "низкоуровневых оптимизаций".
Это не контейнеры, а буфер для передачи данных между потоками. Тот самый твой (context) в каком-то смысле.

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

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

S>>·>А зачем ты в этом обсуждении вообще COM упомянул?
S>> Ты сказал, что .Net Core еще не в релизе. Я показал тебе статьи, где использую .Net Core. Причем уже 1.0.1
S>>Где подправили ошибки.
·>Ок. И причём тут COM?
В линуксе нет СОМ, в отличие от виндовс. Но можно использоваь .Net классы.
S>>>>Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
S>>·>Ну как и в java, уже несколько лет как: http://normanmaurer.me/blog/2014/01/07/JNI-Performance-Welcome-to-the-dark-side/ чем хвастаться-то?
S>> Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
·>Что из натива? JNI — Java Native Interface. Ты хоть по ссылке-то перешел прежде чем вопросы задавать?
Увидел. Но у меня проще используются в параметрах объекты, вывод типов в дженерик методах, использование методов расширений, калбеки итд.

S>>Смысл в том, что я через CoreClr я могу дергать статические методы, и я могу сделать обертку, что бы загружать нужные сборки, создавать объекты и дергать методы.
S>> В большом .Net можно использовать либо IReflect Использование сборок .NET в 1С 7.x b 8.x. Создание внешних КомпонентИспользование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
S>>или CLR Hosting API При этом все так или иначе через COM
S>> Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.
·>Статические наверное потому, что у них возникли проблемы интеграции с gc. В общем я не понимаю к чему ты это всё рассказываешь. JNI позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
·>А ещё для изврлюбителей иметь дело с COM, есть J-Interop, JACOB, jacoZoom.
Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
А что касается только статических методов, то они еще не сделали анлга CLR Hosting API. Я сделал. При этом сделал автоматический вывод типов для дженерик методов, вызов методов расширения, использование dynamicobject, подключение к событиям итд.
Вызов из 1С максимально приближен к синтаксису C#.


S>> Понимаешь, все это хорошо, пока есть время. Если очередь не справляется, то начинаются задержки. Да их можно размазать.
·>Запуск gc раз в минуту — значит справляется. Когда не справляется — gc пашет постоянно или приложение падает с OOME.

S>>Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
S>>То есть скорость на выделение памяти это будет считаться задержкой?
·>Нет, не будет. Как минимум выделение памяти не блокирует все треды (если конечно gc кучу не заблокировал из-за нехватки памяти).
Блокировать она может и не блокирует только может выполняться дольше 4 мс.

S>>>> Ты утверждаеешь, что zing с этим справляется лучше. Голословно.
S>>·>Если ты не веришь утверждениям на их сайте, можешь скачать их триал и попробовть самому: http://info.azul.com/Zing-Trial.html (сэкономишь $2500 на споре со мной).
S>> Ты утверждаешь ты и доказывай.
·>Не понял. Доказательство тут: https://www.azul.com/products/zing/zing-performance/ Чем тебя не устраивает "Delivers max latencies under 10 msec out of the box, without tuning"? Там же ещё есть и ссылки на всякие графики и бенчмарки. Ты считаешь это враньё и я эту страничку сфабриковал? Какое именно ты доказательство от меня требуешь?
Вот когда ты этот пример покажешь тогда поверю.
S>>·>В каком ещё конце кучи?
S>> По алгоритму в кэше буду добавлены последние выделенные данные
·>Я не понимаю о чём ты и какое это отношение имеет к сабжу.
Это имеет смысл к алгоритмам сбора мусора при таких вырожденных случаях.
S>>>>·>Я видел, что справлялась. У на одном из наших сервисов очистка примерно 1гб мусора происходила примерно раз в час, притом потоки не останавливались на время большее 1мс. Да, кстати, 1мс — это точность измерений, сколько точно микросекунд были задержки — не знаю, всё что меньше 1мс просто не регистрировалось. Если я правильно помню (могу и соврать), по gc-логам время было в среднем в районе 50мкс.
S>> В этом тесте сборка будет не раз в час, а раз в несколько секунд.
·>Судя по графикам сборка была раз в минуту. Если ты считаешь, что чувак в той статье налажал и сделал всё неправильно — проведи свои тесты, .net у тебя есть, наверняка.

Еще раз

processingThreads[i] = new Thread(() =>
{
var threadCounter = 0;
while (true)
{
var text = new string((char)random.Next(start, end + 1), 1000);
stringCache.Set(text.GetHashCode(), text);

// Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
var bytes = new byte[80 * 1024];
random.NextBytes(bytes);
bytesCache.Set(bytes.GetHashCode(), bytes);

threadCounter++;
Thread.Sleep(1); // So we don't thrash the CPU!!!!
}
});

За 1 цикл выделяется 200 кб. Сколько занимает цикл?
S>>>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
S>>·>Какая разница какой алгоритм?
S>> Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.
·>Ты же сам нашел статью о TTSP. Вот почитай её и пойми о чём речь, потом, если останутся какие-то возражения, приходи, продолжим разговор.

S>> И сравнить этот же алгоритм на C++. Который порвет всех.
·>Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
·>Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.

Но я могу использовать в .Net классы C++

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

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

_>>>P.S. А ещё обеим обсуждаемым управляемым платформам явно наступает на пятки JS. Потому что он позволяет писать ещё более ммм непрофессиональный код и при этом уже вполне себе подбирается по быстродействию к Java/C#. Как раз благодаря продвинутости его ВМ (тот самый движок V8).
S>> JS может вытестнить https://ru.wikipedia.org/wiki/WebAssembly

_>Это касается только JS в браузере. А скажем на сервере у JS нет никаких врождённых преимуществ, но тем не менее node.js цветёт и пахнет.
Цветет, но по мне так ему до Asp.Net далеко. Он отбирает нишу у PHP.

S>> А TypeScript сам по себе лучше JS. И его кстати многие выбирают.

_>TypeScript — это не отдельный язык, а надстройка над JS. Т.е. это часть его мира, как раз усиливающая его. Собственно появление TS должно вызывать ещё большие опасения у любителей Java/C#, т.к. приводит в лагерь JS ещё и фанатов статической типизации.
Да нет. Я его использую. И он мне больше нравится чем JS. А главное intellisense ускоряющий как написание так и отладку.
Кроме того он может прекрасно компилироваться и в wasm
S>> У .net есть .Net Native и .Net Core которые очень активно развиваются

_>При появление в 2001-ом году это вполне могло сработать. Но не сейчас. )
Ну почему же. Сейчас переходят на Asp.Net Core, мобильные приложения на Xamarin. Скоро выйдет NetStandart 2
Вот скорее всего он будет отбирать нишу у допотопной Java для Андроид и Objective-C

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

V>·>Собственно в точности похоже на вручную организованный young gc space. Только вместо того, чтобы компьютер сам искал объекты
V>Что не бесплатно.
А сиплюсплюсники работают бесплатно? Намёк: в наше время компьютерное время дешевле человеческого.

V>·>что является "контекстом запроса" приходится организовывать архитектуру приложения соответственным образом и внимательно следить, чтобы ничего из этого контекста не утекло куда не надо.
V>Чтобы не утекло, используется специфическая типизация. Например, ты тут приводил как аргумент std::vector<>, посмотри на все типы-параметры этого шаблонного класса.
Причём тут типизация? Ты тут присал "пришел запрос, ты берешь такой аллокатор из пула аллокаторов...". Вот это определяет твою архитектуру — в каком месте именно считается, что "запрос пришел", в каком именно месте можно вернуть в пул (а если мы внезапно что-то решили обработать асинхронно?), определить характеристики этого пула и т.д. и т.п.
Так вот эти все процессы и делаются gc автоматически. Да, не всегда идеально, но обычно достаточно хорошо, ценой небольшого оверхеда, но с бенефитом уменьшения усилий программиста.

V>>>Никаких тебе shared/unique и прочих _ptr, тупо голые указатели и ссылки. ))
V>>>Как тебе такой алгоритм уборки "мусора"?
V>·>Закат солнца вручную.
V>Разработка операционок, баз данных, физических движков и т.д. — такой же точно "закат", и?
V>Да, чем больше подумаешь головой, тем меньше компьютеру за тобой прибирать. В системных вещах это пользуется популярностью.
Согласен, но это надо далеко не всегда. В подавляющем числе приложений компьютер прибирает достаточно хорошо, чтобы стоило заморачивать себе этим голову.

V>>>По последней операции тоже любопытное замечание: ввиду того, что в плюсах почти всё инлайно, то даже этот несчастный аргумент для приращения указателя "виден" оптимизатору. Источником этого аргумента обычно выступает явная (аналог malloc) или неявная (аналог new) операция sizeof, а эта операция возвращает константу времени компиляции. Т.е., даже эта несчастная операция увеличения курсора внутри страницы максимально эффективна из всех возможных вариантов — к указателю прибавляется константа. ))
V>·>Собственно прибавление указателя это и есть способ аллокации в java.

V>Ну да, всего-то ~200 машинных инструкций на каждую аллокацию вместо 3-4-х. В зависимости от вида применённого GC, джаве порой сначала надо достать текущий аллокатор из TLS, что порой еще дороже выходит.
А доказать?
The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call
Заметь что это Java 1.4, на дворе сейчас java8, может даже ещё что-то улучшили...

V>>>Ну и еще плюшки такого сценария — контекст можно протягивать, а можно и нет, ведь он локальный для потока. Это помогает в ситуации, когда надо подцепиться через колбэк-вызов от третьесторонней либы, через которую нельзя протянуть свой контекст.
V>·>А это вы изобрели TLAB.
V>Еще раз. Медленно. Доставать по всей иерархии аллокатор из TLS очень дорого (всё относительно, может для реальности Джавы и не дорого, фиг его знает ).
V>Но в нейтиве дешевле протянуть контекст явно, потому что порядок цифр другой и TLS начинает влиять. Но в некоем месте "разрыва" своего кода вполне можно выкрутиться, восстановив контекст.
TLAB != TLS.

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

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

S>>>> Хотя лично считаю, что для этого лучше всего подойдет C++ с хорошим менеджером памяти.
S>>·>Т.е. .net не подходит. Что и требовалось доказать. Считаю вопрос закрытым.
S>> Мне интересно не .Net, а как с этим справляется твоя хваленая Java
·>Хорошо справляется с помощью zing. Azul обещает задержки <10ms. Ты считаешь, что они лгут?
Я хочу увидеть этот тест на zing.
S>> особенно в сравнении с кодом на C++
·>Тебе интересно, ты и сравнивай. Создавай новый топик, ищи оппонетнов и там рассуждай. Тут мы обсуждаем "dotnet vs java".

Ну дык ты же говоришь, что Java лучше всех. А хочется сравнить.
S>>На этом самом алгоритме. При этом я могу сделать класс на C++
·>И накой когда сдался .net? Шоб було?

Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
S>> и из .Net дергать его методы.
·>Круто, конечно. И что конкретно ты будешь измерять? Цель тех тестов — измерить характеристики GC, его применимость для LL-систем.
·>Методы явы тоже можно из С++ дёргать. И что?

Задача сделать приложение с минимальными задержками, при этом потратить минимум усилий и денег.

S>>При этом у меня будут потери только на копировании, но в задержек не будет. Так, что .Net подходит.
·>Ровно до того момента как сработает GC.
А там собирать то нечего. Проблема то в генерации огромного количества объектов и обновлении кэша размером 200 кб.
На обычных задачах GC справляется.
S>>https://msdn.microsoft.com/en-us/library/ms235281.aspx
S>>А считать то голословно ты можешь, что угодно.
·>Голословен пока только ты. И всё от сабжа постоянно уходишь в сторону нейтива.
Я ухожу в сторону оптимального использования натива в манагед и наоборот.
А вот так и не привел пример на Java. Всем интересно посмотреть. Не только мне.
А я могу написать код с копированием.
Это по сути аналог использования классов на C++.

 var Кэш=new byte[2000][];

 while (true)
  {
    var text = new string((char)random.Next(start, end + 1), 1000);
    stringCache.Set(text.GetHashCode(), text);

    // Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
    var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    var i=bytes.GetHashCode() % размерКэша;

    var массив=Кэш[i];
      if (массив==null)
         Кэш[i]=массив;
      else
      bytes.CopyTo(массив,0);

     threadCounter++;
    Thread.Sleep(1); // So we don't thrash the CPU!!!!
  }
});

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

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

V>·>А фактически ты же сам привёл документ, в котором сказано, что C++ и Java близки. Там был плохой C++?
V>Я уже тебя поправлял — близки по логике реализации, а не по быстродействию.
Ты точно английский читаешь нормально? Там про детали реализации вообще не слова. Там сравнение коммерческих vs opensource. Два коммерческих (pure java cheetah и c++ b2bits) показывают идентичные результаты по производительности:
"A preliminary design test was conducted and results indicated that the use of kernel bypass (Solarflare‟s Open Onload product) had an impact on the commercial FIX engines from B2BITS and Rapid Addition across all tests"
"The commercial FIX engines completed the messaging tasks between 30 and 50 microseconds"
"The commercial FIX engines showed a much tighter distribution range of 4 microseconds"
"The commercial FIX engines were consistent and deterministic throughout the tests"
"The standard deviation from the mean for a commercial engine was only 1 microsecond."
Посмотри картинки — синие линии на них это cheetah и b2bits — они примерно одинаково расположены.

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

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

V>·>Тему о быстродействии я не поднимал и спорить не хочу, ибо это бессмысленный холивар. Я возразил о HFT, для которого критичным является low latency. И в этой области факты показывают, что Java преуспевает гораздо лучше c#.
V>Ты не привёл таких никаких фактов от слова совсем.
V>Данные по быстродействию где?
Я привёл данные о latency gc.

V>·>Если ты не понимаешь разницу между быстродействием и LL перечитай топик внимательно. Я несколько раз это объяснял.
V>Я согласен на голый latency, жду цифры.
https://www.azul.com/products/zing/zing-performance/

V>·>Гибридные C++/Java решения тоже есть. Но они тоже не интересны, ибо Java является просто ничего не делающей обёрткой. А "гибридные нейтивно-дотнетные решения" появились чисто из чувства прекрасного? Или таки из-за того что чистое решение тупо не работает?
V>Ты решил дожать оппонентов, что ле?
V>Еще раз. Гибридные появились из-за того, что уделывают расово-чистые.
V>Никаких других причин тут нет, ес-но.
Плохая отмаза. Расово-чистое C++ решение уделает любое гибридное.

V>Почему в Джаве мало гибридных решений — тоже уже указал тебе, потому что JNI — это издевательство над психикой. За ту же трудоёмкость выгодней уже чисто-нейтивные решения лабать. И напротив, в дотнете сложные гибридные решения — это не хитровымученные (и при этом тупые обертки, на пример JNI), это почти всегда вполне полезный код, просто писанный на C++/CLR. Прямо в исходнике идёт оперирование в родной статической типизации, в отличие от JNI, где мы общаемся с нейтивным АПИ динамической типизации джава-машинки. Разница тут в и эффективности и в контроле компилятором над происходящем просто колоссальная.
Правильно, на java проще писать сразу, чем прикручивать JNI. Язык C++ достаточно развит, чтобы к нему приделать удобную в использовании обёртку над голым JNI, но это не востребованно, т.к. массово на JNI писать не имеет смысла — нечего тупо писать. Максимум тонкая обёртка над специфичным системным вызовом.

Вон, скажем, GCJ был, довольно удобно было смешивать Плюсы и Яву — но нафиг никому не сдался, забросили.

V>Все описанное — это важная причина, почему в дотнете можно задешево задействовать еще один язык для разработки. Ведь эта получается та самая мечта инженера — когда каждый инструмент юзается по своему назначению.
В дот-нет MS вложился в натив по необходимости — чтобы можно было вменяемо использовать все свои нативные legacy api.

V>·>Т.е. ты хочешь меня убедить, что гибридное Java/C++ решение невозможно или что?
V>Я хочу сказать, что оно по трудоёмкости часто переплюнет чистый С++, т.е. смысла брать Джаву уже не будет. Неужели ты до сих пор не понял те причины, по которым современная реальность IT устроена так, а не иначе? ))
Ладно, тут каждый останется при своём мнении. Фактически доказать что-то сложно. Предлагаю закруглиться.

V>>>И это мы еще не касались тех вещей, что в том же дотнете сами системные либы, идущие изкаробки, зачастую выполнены в точности как наши, т.е. являются гибридными и какой-нить reflector однозначно сие показывает. И твоя твоя расово-чистая джава тоже внутри по многим системным либам сплошь нейтивная.
V>·>Можно расшифровать?
V>Зачем? Если ты действительно не понял этот абзац — ОК, я просто приму сие к сведению и не буду более аргументировать в эту сторону.
А. Перечитал, с третьего раза понял. Так бы и написал, что "c# и java написаны на C++". Зачем такие выкрутасы вворачивать?
А я не совсем понимаю как же ещё-то можно системные вещи писать? Ну там к железке какой обратиться или файлик записать... но обработка fix-протокола не системная вещь, ни разу. Какого чёрта для чисто прикладной задачи приходится использовать системные штучки, почему стандартного fw не хватает?

V>>>Как ты думаешь, когда я своим детям хрен его знает сколько лет назад памперсы менял, мне их тоже благодарить надо было?
V>·>Что ты вокруг, да около? Не держи в себе, говори уж, сколько сантиметров?
V>Так а чего я-то? Не я эту херню начал.
V>Раз в пять лет обязательно кто-нить сподобиться с одним и тем же — на колу мочало, начинай сначала.
Не я к личности стал прикапываться. Какая разница когда и какую я искал работу? И памперсы твои никого не интересуют. Это каким-то образом повлияет на GC latency?

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

S>>>Где подправили ошибки.
S>·>Ок. И причём тут COM?
S> В линуксе нет СОМ, в отличие от виндовс. Но можно использоваь .Net классы.
Cool story, bro, но я не понимаю зачем ты мне это всё рассказывешь. Кстати java-классы тоже можно в лиуксе использовать.

S>>> Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
S>·>Что из натива? JNI — Java Native Interface. Ты хоть по ссылке-то перешел прежде чем вопросы задавать?
S> Увидел. Но у меня проще используются в параметрах объекты, вывод типов в дженерик методах, использование методов расширений, калбеки итд.
Это как? В C++ вывод типов дженерик? Расширения? А чем калбеки отличаются от вызовов методов?

S>>> Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.
S>·>Статические наверное потому, что у них возникли проблемы интеграции с gc. В общем я не понимаю к чему ты это всё рассказываешь. JNI позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
S>·>А ещё для изврлюбителей иметь дело с COM, есть J-Interop, JACOB, jacoZoom.
S> Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
В смысле .net core позволяет сделать COM в линухе? Я похоже вообще перестал понимать о чём ты говоришь и что именно ты хочешь доказать. Просто делишься новостями что-ли?

S>>>Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
S>>>То есть скорость на выделение памяти это будет считаться задержкой?
S>·>Нет, не будет. Как минимум выделение памяти не блокирует все треды (если конечно gc кучу не заблокировал из-за нехватки памяти).
S> Блокировать она может и не блокирует только может выполняться дольше 4 мс.
10 машинных инструкций столько выполнятся не могут. Ты вроде тут у нас спец по доказательствам. Давай доказывай, что может.

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

S>·>Не понял. Доказательство тут: https://www.azul.com/products/zing/zing-performance/ Чем тебя не устраивает "Delivers max latencies under 10 msec out of the box, without tuning"? Там же ещё есть и ссылки на всякие графики и бенчмарки. Ты считаешь это враньё и я эту страничку сфабриковал? Какое именно ты доказательство от меня требуешь?
S> Вот когда ты этот пример покажешь тогда поверю.
$2500 на бочку + точный исходник на C# (а то обвинишь ещё потом, что не тот пример примерил) — займусь.

S>·>Я не понимаю о чём ты и какое это отношение имеет к сабжу.
S> Это имеет смысл к алгоритмам сбора мусора при таких вырожденных случаях.
Это не вырожденный случай. Это простейший случай. В реальности размер кучи десятки гигабайт хрен знает чего.

S>·>Судя по графикам сборка была раз в минуту. Если ты считаешь, что чувак в той статье налажал и сделал всё неправильно — проведи свои тесты, .net у тебя есть, наверняка.
S> За 1 цикл выделяется 200 кб. Сколько занимает цикл?
Ок. Ты считаешь, что тест корявый. Найди другой или напиши свой. Я не автор этих тестов, у меня и c# нет, т.к. линух дома.

S>·>Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
S>·>Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.
S> Но я могу использовать в .Net классы C++
Они не помогут тебе бороться с задержками, вызываемыми GC. Ты, конечно, можешь из С++ ещё управлять и выделением/удалением памяти, и правильным размещением структур в памяти, и синхронизацией, и потоками, и прочим, выключить gc, но смысл от c# тогда какой, как от топора в каше?

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

S>·>Хорошо справляется с помощью zing. Azul обещает задержки <10ms. Ты считаешь, что они лгут?
S>Я хочу увидеть этот тест на zing.
Возьми, да запусти, делов-то.

S>>> особенно в сравнении с кодом на C++
S>·>Тебе интересно, ты и сравнивай. Создавай новый топик, ищи оппонетнов и там рассуждай. Тут мы обсуждаем "dotnet vs java".
S> Ну дык ты же говоришь, что Java лучше всех. А хочется сравнить.
Я так не говорю. Я говорю, что Java лучше чем dotnet в LL-задачах.

S>>>На этом самом алгоритме. При этом я могу сделать класс на C++
S>·>И накой когда сдался .net? Шоб було?
S> Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
Можешь ровно до того момента как ты не столкнёшься в LL-задачей.

S>>> и из .Net дергать его методы.
S>·>Круто, конечно. И что конкретно ты будешь измерять? Цель тех тестов — измерить характеристики GC, его применимость для LL-систем.
S>·>Методы явы тоже можно из С++ дёргать. И что?
S> Задача сделать приложение с минимальными задержками, при этом потратить минимум усилий и денег.
С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC.

S>>>При этом у меня будут потери только на копировании, но в задержек не будет. Так, что .Net подходит.
S>·>Ровно до того момента как сработает GC.
S> А там собирать то нечего. Проблема то в генерации огромного количества объектов и обновлении кэша размером 200 кб.
S>На обычных задачах GC справляется.
В реальном приложении всегда есть что собирать. Он справляется, но он не гарантирует задержек меньше 10мс. Azul — гарантирует.

S>·>Голословен пока только ты. И всё от сабжа постоянно уходишь в сторону нейтива.
S> Я ухожу в сторону оптимального использования натива в манагед и наоборот.
S>А вот так и не привел пример на Java. Всем интересно посмотреть. Не только мне.
S> А я могу написать код с копированием.
S> Это по сути аналог использования классов на C++.
На джаве тоже можешь написать код с копированием. Но суть теста в том, что он создаёт мусор, который нужно собирать. И во время сборки stop-the-world не должен тормозить работающие треды на время большее 10мс.

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

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

S>>>>Где подправили ошибки.
S>>·>Ок. И причём тут COM?
S>> В линуксе нет СОМ, в отличие от виндовс. Но можно использоваь .Net классы.
·>Cool story, bro, но я не понимаю зачем ты мне это всё рассказывешь. Кстати java-классы тоже можно в лиуксе использовать.
Ты спросил, я ответил.

S>>>> Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
S>>·>Что из натива? JNI — Java Native Interface. Ты хоть по ссылке-то перешел прежде чем вопросы задавать?
S>> Увидел. Но у меня проще используются в параметрах объекты, вывод типов в дженерик методах, использование методов расширений, калбеки итд.
·>Это как? В C++ вывод типов дженерик? Расширения? А чем калбеки отличаются от вызовов методов?
Из 1С. Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II

С того времени добавил поддержку методов с параметрами по умолчанию, вызов методов расширений, вывод типов для дженерик методов, поддержка объектов реализующих IDynamicMetaObjectProvider (ExpandoObject,DynamicObject), добавление синонимов к членам типа и асинхронное программирование на 1С!

S>>>> Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.
S>>·>Статические наверное потому, что у них возникли проблемы интеграции с gc. В общем я не понимаю к чему ты это всё рассказываешь. JNI позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
S>>·>А ещё для изврлюбителей иметь дело с COM, есть J-Interop, JACOB, jacoZoom.
S>> Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
·>В смысле .net core позволяет сделать COM в линухе? Я похоже вообще перестал понимать о чём ты говоришь и что именно ты хочешь доказать. Просто делишься новостями что-ли?

Моя обертка позволяет использовать .Net классы в 1С, на подобие COM классов.

S>>>>Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
S>>>>То есть скорость на выделение памяти это будет считаться задержкой?
S>>·>Нет, не будет. Как минимум выделение памяти не блокирует все треды (если конечно gc кучу не заблокировал из-за нехватки памяти).
S>> Блокировать она может и не блокирует только может выполняться дольше 4 мс.
·>10 машинных инструкций столько выполнятся не могут. Ты вроде тут у нас спец по доказательствам. Давай доказывай, что может.
Еще раз. При большой скорости выделения объектов, и большом количестве выживших объектов, любой GC будет плохо справляться.
Либо будет жутко фрагментированная память, так как полная сборка будет больше 4 мс, при этом выжившие объекты постоянно изменяются.
значит нужен аналог нативного менеджера памяти.


·>Но на минуточку можно допустить, что и вправду может — это не беда. Выделять память можно в одном треде, LL-некритичном, хоть пол часа, и отправлять выделенный объект в LL-критичный тред через atomic переменную. Или даже иметь кеш готовых выделенных объектов. Но это я уже фантазирую в ответ на твои фантазии.
Мне просто интересно посмотреть как справляется с эти явовский GC. Только и всего. И сравнить его с нптивным менеджером памяти.
А для таких задач он как раз прекрасно подходит.

S>>·>Не понял. Доказательство тут: https://www.azul.com/products/zing/zing-performance/ Чем тебя не устраивает "Delivers max latencies under 10 msec out of the box, without tuning"? Там же ещё есть и ссылки на всякие графики и бенчмарки. Ты считаешь это враньё и я эту страничку сфабриковал? Какое именно ты доказательство от меня требуешь?
S>> Вот когда ты этот пример покажешь тогда поверю.
·>$2500 на бочку + точный исходник на C# (а то обвинишь ещё потом, что не тот пример примерил) — займусь.

S>>·>Я не понимаю о чём ты и какое это отношение имеет к сабжу.
S>> Это имеет смысл к алгоритмам сбора мусора при таких вырожденных случаях.
·>Это не вырожденный случай. Это простейший случай. В реальности размер кучи десятки гигабайт хрен знает чего.
Еще раз это вырожденный случай, корневые когда данные постоянно обновляются и при этом занимают большой объем.
Нормальный это когда есть поколения, а выживших объектов достаточно мало.
И эти Десятки гигабай не обновляются постояннон. Они обычно прекрасно живут в старших поколениях. А вот если они посоянно обновляются, то проще использовать нативную БД.

S>>·>Судя по графикам сборка была раз в минуту. Если ты считаешь, что чувак в той статье налажал и сделал всё неправильно — проведи свои тесты, .net у тебя есть, наверняка.
S>> За 1 цикл выделяется 200 кб. Сколько занимает цикл?
·>Ок. Ты считаешь, что тест корявый. Найди другой или напиши свой. Я не автор этих тестов, у меня и c# нет, т.к. линух дома.
Я именно по этому тесту и веду разговор. Он очень тяжелый для ГС.
S>>·>Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
S>>·>Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.
S>> Но я могу использовать в .Net классы C++
·>Они не помогут тебе бороться с задержками, вызываемыми GC. Ты, конечно, можешь из С++ ещё управлять и выделением/удалением памяти, и правильным размещением структур в памяти, и синхронизацией, и потоками, и прочим, выключить gc, но смысл от c# тогда какой, как от топора в каше?
Если выживших объектов немного, то поможет.
На самом деле классы C++ играют роль БД. На C# вся остальная нагрузка.

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

S>> Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
·>Можешь ровно до того момента как ты не столкнёшься в LL-задачей.
Ну вот тебе на это кстати vdimas приводит примеры.
S>>>> и из .Net дергать его методы.
S>>·>Круто, конечно. И что конкретно ты будешь измерять? Цель тех тестов — измерить характеристики GC, его применимость для LL-систем.
S>>·>Методы явы тоже можно из С++ дёргать. И что?
S>> Задача сделать приложение с минимальными задержками, при этом потратить минимум усилий и денег.
·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC.
Можно. И кстати та же самая статья говорит, что можно.

S>>>>При этом у меня будут потери только на копировании, но в задержек не будет. Так, что .Net подходит.
S>>·>Ровно до того момента как сработает GC.
S>> А там собирать то нечего. Проблема то в генерации огромного количества объектов и обновлении кэша размером 200 кб.
S>>На обычных задачах GC справляется.
·>В реальном приложении всегда есть что собирать. Он справляется, но он не гарантирует задержек меньше 10мс. Azul — гарантирует.
Ну вот статья то как раз говорит, что может на нормальных данных.

S>>·>Голословен пока только ты. И всё от сабжа постоянно уходишь в сторону нейтива.
S>> Я ухожу в сторону оптимального использования натива в манагед и наоборот.
S>>А вот так и не привел пример на Java. Всем интересно посмотреть. Не только мне.
S>> А я могу написать код с копированием.
S>> Это по сути аналог использования классов на C++.
·>На джаве тоже можешь написать код с копированием. Но суть теста в том, что он создаёт мусор, который нужно собирать. И во время сборки stop-the-world не должен тормозить работающие треды на время большее 10мс.
А вот в примере данные данные не будут менять ссылок. И по сути вся сборка мусора сводится к переносу начала кучи. Ничего дефрагментировать не надо.

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

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

S>>> В линуксе нет СОМ, в отличие от виндовс. Но можно использоваь .Net классы.
S>·>Cool story, bro, но я не понимаю зачем ты мне это всё рассказывешь. Кстати java-классы тоже можно в лиуксе использовать.
S> Ты спросил, я ответил.
мы вроде рассуждаем о LL, а ты рассказываешь о COM. Зачем?

S> Из 1С. [url=https://habrahabr.ru/post/307188/]Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
Интересно. А зачем это? Почему бы не писать всё на одном из языков?

S>>> Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
S>·>В смысле .net core позволяет сделать COM в линухе? Я похоже вообще перестал понимать о чём ты говоришь и что именно ты хочешь доказать. Просто делишься новостями что-ли?
S> Моя обертка позволяет использовать .Net классы в 1С, на подобие COM классов.
Ок. Что ты хочешь доказать? К чему всё это? Я тебя вообще про 1С не спрашивал.

S>·>10 машинных инструкций столько выполнятся не могут. Ты вроде тут у нас спец по доказательствам. Давай доказывай, что может.
S> Еще раз. При большой скорости выделения объектов, и большом количестве выживших объектов, любой GC будет плохо справляться.
Ладно, напиши другой тест, какой считаешь нужным, запусти и измерь latency тредов (как статье с jhiccup). Это займёт тебе пол часа, и винда+c# у тебя есть наверняка.
Цель теста — вызывать периодические сборки мусора, скажем, каждые 10 минут, и чтобы собирался 1гб памяти, из 16гб кучи.

S>Либо будет жутко фрагментированная память, так как полная сборка будет больше 4 мс, при этом выжившие объекты постоянно изменяются.
gc (по крайней мере в java) умеет дефрагментировать память.

S> значит нужен аналог нативного менеджера памяти.
Проблема фрагментации с нативным менеджером ещё хуже, т.к. в нативные объекты не умеют перемещаться (либо реализовывать перемещение придётся самому).

S>·>Но на минуточку можно допустить, что и вправду может — это не беда. Выделять память можно в одном треде, LL-некритичном, хоть пол часа, и отправлять выделенный объект в LL-критичный тред через atomic переменную. Или даже иметь кеш готовых выделенных объектов. Но это я уже фантазирую в ответ на твои фантазии.
S> Мне просто интересно посмотреть как справляется с эти явовский GC. Только и всего. И сравнить его с нптивным менеджером памяти.
S>А для таких задач он как раз прекрасно подходит.
Каких таких? Нет никаких задач. Задача есть — измерить паузы, возникающие при срабатывании gc. Как ты это сделаешь с нативным менеджером памяти?

S>·>Это не вырожденный случай. Это простейший случай. В реальности размер кучи десятки гигабайт хрен знает чего.
S> Еще раз это вырожденный случай, корневые когда данные постоянно обновляются и при этом занимают большой объем.
S> Нормальный это когда есть поколения, а выживших объектов достаточно мало.
S> И эти Десятки гигабай не обновляются постояннон. Они обычно прекрасно живут в старших поколениях. А вот если они посоянно обновляются, то проще использовать нативную БД.
Ок. Пусть живут где тебе угодно. Старшее поколение когда-нибудь собирается? Ну хоть раз в день? Если да — какие это вызывает задержки?

S>>> За 1 цикл выделяется 200 кб. Сколько занимает цикл?
S>·>Ок. Ты считаешь, что тест корявый. Найди другой или напиши свой. Я не автор этих тестов, у меня и c# нет, т.к. линух дома.
S> Я именно по этому тесту и веду разговор. Он очень тяжелый для ГС.
В этом его и суть. Можешь его облегчить, но тогда прогоны будут не 5 минут, а 5 часов. Но ты можешь объяснить за счёт чего улучшится latency?

S>·>Они не помогут тебе бороться с задержками, вызываемыми GC. Ты, конечно, можешь из С++ ещё управлять и выделением/удалением памяти, и правильным размещением структур в памяти, и синхронизацией, и потоками, и прочим, выключить gc, но смысл от c# тогда какой, как от топора в каше?
S> Если выживших объектов немного, то поможет.
Малая сборка (YG) вроде не вызывает stop-the-world. Это будет бессмысленный тест.

S> На самом деле классы C++ играют роль БД. На C# вся остальная нагрузка.
Ну вот как vdimas рассказывал, так им и пришлось сделать — синхронизация, управление памятью и потоки — нативные.

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

S>>> Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
S>·>Можешь ровно до того момента как ты не столкнёшься в LL-задачей.
S> Ну вот тебе на это кстати vdimas приводит примеры.
Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.

S>·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC.
S> Можно. И кстати та же самая статья говорит, что можно.
Цитату плз.

S>>>На обычных задачах GC справляется.
S>·>В реальном приложении всегда есть что собирать. Он справляется, но он не гарантирует задержек меньше 10мс. Azul — гарантирует.
S> Ну вот статья то как раз говорит, что может на нормальных данных.
Цитату плз.

S>·>На джаве тоже можешь написать код с копированием. Но суть теста в том, что он создаёт мусор, который нужно собирать. И во время сборки stop-the-world не должен тормозить работающие треды на время большее 10мс.
S> А вот в примере данные данные не будут менять ссылок. И по сути вся сборка мусора сводится к переносу начала кучи. Ничего дефрагментировать не надо.
Ты хочешь сказать, что можно взять любой код и легко переписать его таким образом, что дефрагметация не будет происходить?
Ещё раз — тест призван выяснить — что происходит, когда таки gc должен собрать мусор и дефрагментировать.

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

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

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

S>>>> В линуксе нет СОМ, в отличие от виндовс. Но можно использоваь .Net классы.
S>>·>Cool story, bro, но я не понимаю зачем ты мне это всё рассказывешь. Кстати java-классы тоже можно в лиуксе использовать.
S>> Ты спросил, я ответил.

S> Есть кроссплатформенный .Net Core и .Net Native
Они разве уже "есть"? Пока вроде просто публичные preview билды. Когда зарелизить обещают?

·>мы вроде рассуждаем о LL, а ты рассказываешь о COM. Зачем?
Еще раз напомню, я ответил на твой вопрос про релиз .Net Core. Я привел тебе примеры использования уже релиза.
S>> Из 1С. [url=https://habrahabr.ru/post/307188/]Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
·>Интересно. А зачем это? Почему бы не писать всё на одном из языков?
1С это очень удобный конструктор и язык для работы с Базами данных. А во внутренний язык очень ограничен. Но с помощью .Net его можно расширить. Только никому это не нужно.
S>>>> Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
S>>·>В смысле .net core позволяет сделать COM в линухе? Я похоже вообще перестал понимать о чём ты говоришь и что именно ты хочешь доказать. Просто делишься новостями что-ли?
S>> Моя обертка позволяет использовать .Net классы в 1С, на подобие COM классов.
·>Ок. Что ты хочешь доказать? К чему всё это? Я тебя вообще про 1С не спрашивал.
Еще раз. Я дал пример использования релизного .Net Core.


S>> Я именно по этому тесту и веду разговор. Он очень тяжелый для ГС.
·>В этом его и суть. Можешь его облегчить, но тогда прогоны будут не 5 минут, а 5 часов. Но ты можешь объяснить за счёт чего улучшится latency?
За счет, того что не нужно дефрагментировать большое количество памяти за счет нативного менеджера памяти.

S>>·>Они не помогут тебе бороться с задержками, вызываемыми GC. Ты, конечно, можешь из С++ ещё управлять и выделением/удалением памяти, и правильным размещением структур в памяти, и синхронизацией, и потоками, и прочим, выключить gc, но смысл от c# тогда какой, как от топора в каше?
S>> Если выживших объектов немного, то поможет.
·>Малая сборка (YG) вроде не вызывает stop-the-world. Это будет бессмысленный тест.
Вот именно.
S>> На самом деле классы C++ играют роль БД. На C# вся остальная нагрузка.
·>Ну вот как vdimas рассказывал, так им и пришлось сделать — синхронизация, управление памятью и потоки — нативные.
Ну при этом они используют и манагед код. Просто для многих специфических задач смешанный код подходит лучше всего.

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

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

S>>>> Я могу использовать манакед GC и нативный менеджер памяти. Это расширяет возможности.
S>>·>Можешь ровно до того момента как ты не столкнёшься в LL-задачей.
S>> Ну вот тебе на это кстати vdimas приводит примеры.
·>Он какие-то странные примеры приводит. В одном примере так вообще производительность pure-java оказалась близкой к C++.

S>>·>С текущей реализацией GC ты не можешь решить эту задачу с использованием dotnet managed GC.
S>> Можно. И кстати та же самая статья говорит, что можно.
·>Цитату плз.
То, что при такой нагрузке задержки начинаются только на 10 минуте.
S>>>>На обычных задачах GC справляется.
S>>·>В реальном приложении всегда есть что собирать. Он справляется, но он не гарантирует задержек меньше 10мс. Azul — гарантирует.
S>> Ну вот статья то как раз говорит, что может на нормальных данных.
·>Цитату плз.
То, что при такой нагрузке задержки начинаются только на 10 минуте.

S>>·>На джаве тоже можешь написать код с копированием. Но суть теста в том, что он создаёт мусор, который нужно собирать. И во время сборки stop-the-world не должен тормозить работающие треды на время большее 10мс.
S>> А вот в примере данные данные не будут менять ссылок. И по сути вся сборка мусора сводится к переносу начала кучи. Ничего дефрагментировать не надо.
·>Ты хочешь сказать, что можно взять любой код и легко переписать его таким образом, что дефрагметация не будет происходить?
·>Ещё раз — тест призван выяснить — что происходит, когда таки gc должен собрать мусор и дефрагментировать.
Он будет справляться. Еще раз при такой нагрузке задержки начинаются только на 10 минуте.
На обычных данных он может и справиться. Надо спрашивать у Vdimas. Я просто обратил внимание на тест где генерится огромный объем данных при этом кэш составляет порядка 200 мб и по идее сборка мусора должна происходить раз в несколько секунд, а не минут.

Здравствуйте, Serginio1, Вы писали:
S>·>мы вроде рассуждаем о LL, а ты рассказываешь о COM. Зачем?
S> Еще раз напомню, я ответил на твой вопрос про релиз .Net Core. Я привел тебе примеры использования уже релиза.
То что зарелизили — хорошо, через два-три года может станет юзабельным. Но меня больше интересует не факт того, что он хоть как-то работает, а даёт ли он показатели, важные для нашего обсуждения.

S>>> Из 1С. [url=https://habrahabr.ru/post/307188/]Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
S>·>Интересно. А зачем это? Почему бы не писать всё на одном из языков?
S> 1С это очень удобный конструктор и язык для работы с Базами данных. А во внутренний язык очень ограничен. Но с помощью .Net его можно расширить. Только никому это не нужно.
Тут как я понимаю вопрос — а зачем этот язык расширять? Он нужен только для чего-то простого, что-то заскриптовать. А если какой-то сложный код, который плохо ложится на сложную задачу, то эту задачу лучше целиком реализовать на каком-то другом языке и интегрировать с 1C каким-то более обычным способом, через WebService, REST или подобное.
Но мы опять отбиваемся от темы...

S>>> Я именно по этому тесту и веду разговор. Он очень тяжелый для ГС.
S>·>В этом его и суть. Можешь его облегчить, но тогда прогоны будут не 5 минут, а 5 часов. Но ты можешь объяснить за счёт чего улучшится latency?
S> За счет, того что не нужно дефрагментировать большое количество памяти за счет нативного менеджера памяти.
Как нативный менеджер памяти делает дефрагметацию? Или эта проблема не появляется в нативном менеджере памяти?

S>>> Если выживших объектов немного, то поможет.
S>·>Малая сборка (YG) вроде не вызывает stop-the-world. Это будет бессмысленный тест.
S> Вот именно.
А зачем нужен бессмысленный тест?

S>>> На самом деле классы C++ играют роль БД. На C# вся остальная нагрузка.
S>·>Ну вот как vdimas рассказывал, так им и пришлось сделать — синхронизация, управление памятью и потоки — нативные.
S> Ну при этом они используют и манагед код. Просто для многих специфических задач смешанный код подходит лучше всего.
Ок, подытожу.
Суть проблемы в том, что смешанный код тут — необходимость. Т.к. решение только на одном из языков — C# или C++ плохо либо в одном (показатели производительности), либо в другом (сложности native-мира).
Решение на чистой Java — возможно, и даёт достаточный компромисс производительности и предоставляет прелести managed. Решение получается лучше в сопровождении, т.к. используется один ЯП (точнее платформа) для всего — это упрощает многие этапы ЖЦ проекта.
Тебя не убеждают реальные проекты. Я не видел c# ни в одной LL системе, видел только GUI, при этом backend либо C++, либо Java — в этом убедиться сам, изучив рынок труда для программистов HFT, если ты видел — покажи хоть один пример. Ещё иногда c# используют брокеры, но это по сути тоже клиентский код и совсем не HFT, требования значительно ниже, т.к. коннектятся-то они к биржам написанным на C++ и Java. Хедж-фанды, инвест-банки, етс — всё то же.
Тебя не убеждают приведённые данные о производительности gc. Тебя не убеждает даже простой факт отсутствия pauseless gc для .net в принципе.
В качестве доказательства твоей тз от тебя я видел только рассуждения о том, что тесты плохие и в Линуксе COM с 1С.
В общем, мне надоело, я пас. Оставайся при своём мнении.