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

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

S>>·>В LL не надо дефрагментировать 200мб за 4мс.
S>>>>·>А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
S>>Я ничего не доказываю. Там вообще все на рефлексии.
·>А зачем ты в этом обсуждении вообще COM упомянул?
Ты сказал, что .Net Core еще не в релизе. Я показал тебе статьи, где использую .Net Core. Причем уже 1.0.1
Где подправили ошибки.
S>>Но скорость вызова .Net метода из натива через рефлексию порядка 500 000 вызовов в секунду.
·>Ну как и в java, уже несколько лет как: http://normanmaurer.me/blog/2014/01/07/JNI-Performance-Welcome-to-the-dark-side/ чем хвастаться-то?
Из натива? Смысл в том, что мне нужно дергать из натива (1С через ВК на C++) любой метод из сборки .Net.
Смысл в том, что я через CoreClr я могу дергать статические методы, и я могу сделать обертку, что бы загружать нужные сборки, создавать объекты и дергать методы.
В большом .Net можно использовать либо IReflect Использование сборок .NET в 1С 7.x b 8.x. Создание внешних КомпонентИспользование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент
или CLR Hosting API При этом все так или иначе через COM
Для .Net Core пока только через статические методы. Поэтому и сделала аналог COM на .Net Core.



S>>>>·>Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
S>> Что ты мне доказал? Что нетовский GC плохо работает с постоянно обновляемыми данными в кэше размером за 100 мегабайт?
·>Ты внимательно читаешь что я пишу? Я доказал себе, тебе доказывать я не хочу, по крайней мере бесплатно. Это займёт моё время, потребует доступ к серверному железу (хотя бы 16-ядерный проц и 32гб памяти, лучше больше), у меня такого в прямой досягаемости нет. Притом для сравнения я предпочитаю linux, что не особо прокатит с c#. Или ты согласишься на тесты с mono (с win будет стоить дороже)? Ты готов оплатить моё время? Или хотя бы поспорить? Я даже тебе фору дам. Скажем, я ставлю свои $5000 против твоих $2500, на то, что zing даст лучший latency time во время сборки мусора, чем c#. И как, по рукам?
Понимаешь, все это хорошо, пока есть время. Если очередь не справляется, то начинаются задержки. Да их можно размазать.
Но постановка в очередь может стать дольше твоих 4 мс. Вот интересно посмотреть не только на задержки GC, но и на скорость выделения памяти итд.
То есть скорость на выделение памяти это будет считаться задержкой?

S>> Ты утверждаеешь, что zing с этим справляется лучше. Голословно.
·>Если ты не веришь утверждениям на их сайте, можешь скачать их триал и попробовть самому: http://info.azul.com/Zing-Trial.html (сэкономишь $2500 на споре со мной).

Ты утверждаешь ты и доказывай.
S>>>>·>Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.
S>> Где статья, что Java быстрее .Net. Ты привел только код на .Net.
·>Где статья, что .net быстрее Java. Ты вообще ничего не привёл.

S>>>> Я ничего доказывать не должен. Ты утверждаешь что приведенный пример будет работать без задержек на Java/
S>>·>Уверен. Если не сработает — зарепорчу баг в azul.
S>> Вот и сделай и посмотрим. В том числе посмотрим на общую скорость.
S>> Я уже писал можно сделать смесь GC и менеджера памяти.
·>Что за смесь? И чем эта смесь поможет? Почему эту же смесь нельзя сделать на java?

S>> Там не раз в минуту память должна забиваться. Правда по алгоритму, выжившие данные должны быть в конце кучи.
S>>Но опять же поколения, которые постоянно обновляются. Нетипичная задача для ГС.
·>В каком ещё конце кучи?

По алгоритму в кэше буду добавлены последние выделенные данные
S>>·>Там "не быстро", а в течение примерно минуты. Ну чтоб пятнадцатиминутный тест показывал хоть что-то полезное.
S>> Ну посмотри на код. Там за цикл выделяется 200 килобайт. Из некольких потоков. Ты хоть этот тес крутил?
·>Нет, у меня нет винды дома, а на работе не до этого.

S>>>> Но зачем тогда C++? Или Java уже и натив обгоняет.
S>>>> Мне просто интересно справится Java как ты утверждаешь или нет.
S>>·>Я видел, что справлялась. У на одном из наших сервисов очистка примерно 1гб мусора происходила примерно раз в час, притом потоки не останавливались на время большее 1мс. Да, кстати, 1мс — это точность измерений, сколько точно микросекунд были задержки — не знаю, всё что меньше 1мс просто не регистрировалось. Если я правильно помню (могу и соврать), по gc-логам время было в среднем в районе 50мкс.
В этом тесте сборка будет не раз в час, а раз в несколько секунд.

S>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
·>Какая разница какой алгоритм?

Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.

И сравнить этот же алгоритм на C++. Который порвет всех.