Информация об изменениях

Сообщение Re[47]: dotnet vs java 2016-2020 от 14.10.2016 18:12

Изменено 14.10.2016 18:51 Serginio1

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

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


S>>>> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.

S>>·>Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
S>>·>Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.
S>>Вот под это прекрасно подходят нативные менеджеры памяти.
·>Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.
Вопрос пока открыт пока не покажешь этот же самый код на Java.
S>>Да там может быть жуткая фрагментация.
·>Угу... Или не будет, если переизобретёшь явовский gc.
Я то не буду. Но как MS могут добавить еще один GC для таких вырожденных случаев.
S>>Но можно сделать компромиссный GC с менеджером памяти.
·>Или не париться и взять java.
Я не пишу на Java. Ты так и не показал этот же тест на Java.
Только свои предположения. Возьми и напиши. Делов то. А я может и перейду на Java.
Здравствуйте, ·, Вы писали:

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


S>>>> Так приведи пример дефрагментации 200мб за 4 мс. Я жду от тебя подтвердения твоих слов.

S>>·>Ты всё ещё не понимаешь суть LL. Пусть хоть 4 дня дефрагментирует. Главное — без единовременных задердек всех тредов приложения на время большее сотен микросекунд.
S>>·>Т.е. LL GC должен работать по-другому, не так как бы ты ожидал от "быстрого и эффективного" GC. Он должен не пытаться сделать всё сразу при первом шансе пока все ждут, а размазать это на много небольших кусочков, чтобы исключить единовременные задержки. Т.е. улучшение latency обычно происходит за счёт ухудшения throughput.
S>>Вот под это прекрасно подходят нативные менеджеры памяти.
·>Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.
Вопрос пока открыт пока не покажешь этот же самый код на Java.
S>>Да там может быть жуткая фрагментация.
·>Угу... Или не будет, если переизобретёшь явовский gc.
Я то не буду. Но как MS могут добавить еще один GC для таких вырожденных случаев.
S>>Но можно сделать компромиссный GC с менеджером памяти.
·>Или не париться и взять java.
Я не пишу на Java. Ты так и не показал этот же тест на Java.
Только свои предположения. Возьми и напиши. Делов то. А я может и перейду на Java.
Заодно и .Net Core протестируем.