Сообщение Re[51]: dotnet vs java 2016-2020 от 15.10.2016 15:47
Изменено 15.10.2016 17:26 Serginio1
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 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 в релизе.
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 у тебя есть, наверняка.
Еще раз
За 1 цикл выделяется 200 кб. Сколько занимает цикл?
S>>>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
S>>·>Какая разница какой алгоритм?
S>> Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.
·>Ты же сам нашел статью о TTSP. Вот почитай её и пойми о чём речь, потом, если останутся какие-то возражения, приходи, продолжим разговор.
S>> И сравнить этот же алгоритм на C++. Который порвет всех.
·>Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
·>Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.
Но я могу использовать в .Net классы C++
·>Здравствуйте, 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 позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
·>А ещё для
Еще раз я тебе ответил про использование .Net Core, и то что он месяца 3 в релизе.
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++
Re[51]: dotnet vs java 2016-2020
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 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 у тебя есть, наверняка.
Еще раз
За 1 цикл выделяется 200 кб. Сколько занимает цикл?
S>>>> Ты видел именно на этом алгоритме? А 50 мс близко к дефрагментации 200 мб
S>>·>Какая разница какой алгоритм?
S>> Большая. Все это хорошо пока времени хватает. Еще раз нужно считать не только задержки на GC но и на выделение памяти.
·>Ты же сам нашел статью о TTSP. Вот почитай её и пойми о чём речь, потом, если останутся какие-то возражения, приходи, продолжим разговор.
S>> И сравнить этот же алгоритм на C++. Который порвет всех.
·>Сравнивай если хочешь, но это оффтопик. Мы обсуждаем сабж.
·>Но заметь, цель теста измерить перформанс GC, как он влияет на исполнение приложения. А не "порвать всех". Тонкий намёк: в C++ нет GC.
Но я могу использовать в .Net классы C++
·>Здравствуйте, 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 позволяет дёргать любые методы, загружать классы, создавать инстансы, кидать|ловить исключения и т.п.
·>А ещё для
Еще раз я тебе ответил про использование .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++