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

·>Здравствуйте, 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 мб и по идее сборка мусора должна происходить раз в несколько секунд, а не минут.