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

I>"Количество повторно неиспользуемого кода" это что за термин ?

Это речь о раздельных кешах для данных и для инструкций.

I>>>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.

V>>Я не зря тебе дал вполне жОсткую (С) временную сетку. Тебе уже не надо гадать и нащупывать нужные области. Предлагаю проводить тест тогда, когда вообще "ничего такого" с машиной не происходит. То бишь, когда она ничем больше не занята. Результаты тебя всё-равно удивят.

I>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.

Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.



I>>>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.

V>>GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.

I>Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.

Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.


I>Это не требует разнообразия типов, хватит и просто большого количества объектов.

Гы, и обратное тоже верно. Молодца, хорошо споришь.


I>>>2 количество узлов в дереве

V>>Поправлю, кол-во постоянно обновляемых объектов.
I>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep

В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД.


V>>Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.
I>Принципиально, ибо стек сканируется в лоб, в случае рекурсивных алгоритмов в стеке нужно сканировать _мегабайты_.

Я бы уволил такого программиста... Пользоваться инструментом надо уметь.
Не напомнишь выделяемую потоку глубину стека по-умолчанию?


V>>При нашем малом кол-ве объектов, да еще устойчиво живущих во 2-м поколении + крайне редком выделении памяти, считай, что фрагментации нет совсем.
I>Это не важно, чего у вас есть а чего нет, важно что степень фрагментации слишком сильно влияет на скорость GC. Как аргумент — вы от пулами именно с фрагментацией и боретесь.

Мы вообще с издержками боремся, а эти издержки очень многофакторны. Да, пул объектов позволяет эффетивно использовать хотя бы кеш второго уровня в процессоре. Тем более, что правильный пул объектов обязательно работает по схеме LIFO, в отличие от стратегии выделения памяти в GC.