Здравствуйте, vdimas, Вы писали:
V>>>Мде... И у тебя совсем-совсем никаких вариантов, как на многопроцессорной машине организовать тики с точностью до микросекунд? Ты бы эта... замерил на досуге стоимость QueryPerformanceCounter, что-ле...
I>>Ты бы замерил что ли
V>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns.
Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки
I>>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100) I>>Повторяю — это особенность виндовса.
V>Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...
Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.
V>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести.
В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.
V>>>Ну и для показанного теста вообще дергать GC НЕ надо, это демонстрация не для GC, а для кеша. I>>Интересно, для вычисления зависимости скорости работы GC от количества типов оказывается GC не надо дёргать
V>Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике.
"Дергать GC" это например вызывать new для референстайпов.
Здравствуйте, vdimas, Вы писали:
I>>Если весь эффект это "сумма отдельных слагаемых не равна сумме" то этим свойством обладает любой отрезок кода который затрагивает кеш. Делаешь прогоны через паузу — опаньки, суммарное время прогонов меньше суммарного времени прогонов без пауз. GC здесь ничего не меняет.
V>Паузы не в счет, ес-но.
Я где то написал, что надо сами паузы суммировать или тебе хочется прочесть именно таким образом ?
>И да, в тесте можно выявить зависимость по двум координатам — по паузам и по кол-ву повторно неиспользуемого кода.
"Количество повторно неиспользуемого кода" это что за термин ?
I>>Разнообразие типов может повлиять на перформанс а может и не повлиять, зависит от того, что происходит с кешем.
V>Я не зря тебе дал вполне жОсткую (С) временную сетку. Тебе уже не надо гадать и нащупывать нужные области. Предлагаю проводить тест тогда, когда вообще "ничего такого" с машиной не происходит. То бишь, когда она ничем больше не занята. Результаты тебя всё-равно удивят.
Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.
I>>У меня, например, в памяти находится несколько десятков миллионов объектов при количестве типов минимум несколько тысяч и что характерно, GC отрабатывает примерно за то же время, как и в том случае, если в приложении десятки миллионов объектов и всего десяток типов.
V>GC не пробегает все экземпляры за каждый цикл, а при уборке 0-го поколения кол-во интерпретируемых типов вообще минимально. Да и сами объекты обычно еще в кеше. И да, у нас (в описанном сценарии) ни о каких десятков миллионов речи быть не могло, ес-но. В среднем десятки тясяч объектов составляют пул для медиа для тысячи одновременных подключений и примерно столько же составляют описание самих подключений. Выделения из GC происходят только когда соединения меняют состояния, что происходит невероятно редко в сравнеии с частотой поступления пакетов медиа. По пути медиа в коде не встречается ни одного new. )) В общем, борьба шла за то, чтобы вложить самые тяжелые паузы GC в ~50ms. Больше — нельзя.
Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.
I>>Ты для начала внятно опиши, что же это за эффект такой.
V>Ты уже сам его описал — эффект от выталкивания полезных данных из кеша. Кеш многоуровневый, эффект тоже.
Это не требует разнообразия типов, хватит и просто большого количества объектов.
I>>2 количество узлов в дереве
V>Поправлю, кол-во постоянно обновляемых объектов.
Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep
I>>3 глубина стека
V>Непринципиально. У тебя глубже 2-3-х десятков уровней во вменяемой программе будет мало вызовов. И даже отклонение в 2 раза от этой цифры ничего не изменит.
Принципиально, ибо стек сканируется в лоб, в случае рекурсивных алгоритмов в стеке нужно сканировать _мегабайты_.
I>>4 степень фрагментации
V>При нашем малом кол-ве объектов, да еще устойчиво живущих во 2-м поколении + крайне редком выделении памяти, считай, что фрагментации нет совсем.
Это не важно, чего у вас есть а чего нет, важно что степень фрагментации слишком сильно влияет на скорость GC. Как аргумент — вы от пулами именно с фрагментацией и боретесь.
Здравствуйте, Ikemefula, Вы писали:
I>Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.
Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет.
И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.
Здравствуйте, vdimas, Вы писали:
G>>Тьфу-ты. То есть речь идет просто об общей эффективности работы с большим количеством типов и алгоритмы GC тут не при чем. "Протухание кэша" Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?
V>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.
" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов"
"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @
Здравствуйте, Ikemefula, Вы писали:
V>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ. I>Давай, покажи на примере Enumerable.ElementAt, вперёд.
Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))
Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?
V>>Цифры приведены. Ну и потестировать List<> и IList<> можно самому, не? I>От тебя по прежнему нет кода Тенденция-с.
Дык, мне оно и не надо, я это уже многнократно проходил во всех позах. И вообще, List<> vs IList<> как-нить сам. Это не тот нетривиальный пример, о котором говорили выше.
Здравствуйте, Ikemefula, Вы писали:
V>>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.
I>" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов" I>"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @ I>
И? поясни юмор?
Не пробовал на досуге сравнивать размеры своих объектов vs размеры их метаописания?
Если кол-во метаинформации, необходмой для интерпретирования (во время уборки мусора) достаточно велико, то эффект протухания кеша ты получишь в квадрате, вот и всё, что имелось ввиду. Просто по своей наивности мне всегда кажется, что читатели и так должны знать, о чем речь. Фрум-то не для домохозяек...
Здравствуйте, vdimas, Вы писали:
I>>Я говорю о том, что аргументы у тебя высосаны из пальца, ни пояснить, ни подтвердить кодом у тебя не получается.
V>Время надо. Для адекватного воспроизведения покодогенерить неплохо бы, а то непонятно что смотреть будем...
То есть, коэффициэнт 16 высосан из пальца ? Поздравляю.
V>Попробую этой время найти ближе к выходным. Самому интересно, что покажет мой сегодняшний рабочий комп и новый дотнет. V>И зря ты свой тест не даешь, коль он у тебя уже есть. Несерьезный ты человек.
"Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать.." @ vdimas
Здравствуйте, Ikemefula, Вы писали:
V>>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns. I>Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки
Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.
I>>>Успокойся — 15 секунд задержки было замерено в нативном коде c с помощью трех вызовов апи, два из которых QueryPerformanceCounter а третий Sleep(100) I>>>Повторяю — это особенность виндовса.
V>>Я получаю паузы в 3-5 сек только когда некая железка, обращение с которой идет через DMA, выходит из сна. Например, винт. Конкретно винды тут не при чем, на Линухах можно повторить. Больше нигде я таких пауз не наблюдал...
I>Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.
Боюсь, что это зависит больше от драйвера, а не от операционки.
V>>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести. I>В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.
Ничего от "просто нагрузки" не зависит. Запусти несколько процессов 10 GOTO 10 на многоядерной машинке и убедись. Речь может идти только о реалтаймовых потоках в виндах или случая запрета прерываний на подзадержавшемся DMA. Как раз второй момент по-идее одинаково работает для любых операционок.
V>>Ничего смешного. Ты не можешь достоверно управлять дотнетным асинхронным GC. Поэтому, чтобы воспроизвести сценарий какой-нить сложной проги... это надо брать саму прогу, которую вполне можно тестировать на конкретной технике. I>"Дергать GC" это например вызывать new для референстайпов.
Опять и снова — интересуют всегда затраты на уборку, а не на выделение. Выделение относительно дешевое (не ахти, в сравнении с самописными аллокаторами, но достаточно дешевое для обсуждаемого). А вот уборкой ты управлять особо и не можешь. А интересует таки сугубо ограничение сверху на паузы GC в реальной проге и ничего более.
Здравствуйте, vdimas, Вы писали:
V>>>Дык, наоборот, был использован популярный мем "протухание кэша", чтобы сразу было понятно о чем речь. Я считал, что понятно и так, а стал расписывать подробности лишь когда ты показал, что для тебя это новость.
I>>" Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов" I>>"не миллион, а три рубля, не в казино, а в домино, не выиграл а проиграл" @ I>>
V>И? поясни юмор?
Поясняю — на мой взгляд в твоих слова примерно 90-95% дезы пополам с общими словами( по оценке снизу конечно же).
V>Не пробовал на досуге сравнивать размеры своих объектов vs размеры их метаописания? V>Если кол-во метаинформации, необходимой для интерпретирования (во время уборки мусора) достаточно велико, то эффект протухания кеша ты получишь в квадрате, вот и всё, что имелось ввиду. Просто по своей наивности мне всегда кажется, что читатели и так должны знать, о чем речь. Фрум-то не для домохозяек...
И сколько этого "достаточно велико" ? На боевом приложении, где разных типов не менее 1000 (по оценке снизу) эффект ничем не отличается от чистой синтетики Сколько это "достаточно велико", 10К, 100К, 1ККК ?
Здравствуйте, 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.
Здравствуйте, vdimas, Вы писали:
V>>>Гы-гы, оценка O — это оценка сложности СВЕРХУ. А на реальных задачах обязательно интересует так же оценка СНИЗУ. I>>Давай, покажи на примере Enumerable.ElementAt, вперёд.
V>Что тебе показать-то? Принцип подвижного маляра относительно неподвижного ведра с краской? ))
"прирост до 50 раз " @ vdimas
V>Тебе действительно сложно перебрать элементы абстрактного и конкретного контейнеров?
Успокойся, не волнуйся, твои сценарии самые-самые, и да, это не беда, что только у тебя они используются.
Для моих сценариев IList<> в самый раз, просто потому что List<> это ОЧЕНЬ дорогой контейнер. Настолько дорогой, что использовать его нельзя во многих сценариях.
Здравствуйте, vdimas, Вы писали:
V>>>Давно и не раз на разной технике. От десятков ns до примерно сотни, зависит от чипсета. А если брать инструкцию RDTSC — от долей до единиц ns. I>>Не до сотни ns, а до тысяч милисекунд. Ты снова ошибся на порядки
V>Увы, это ты ошибся. Интересуют собственные затраты на эту операцию, а как их найти с помощью статистики ты должен бы и сам знать, если умудрился самостоятельно закончить ВУЗ.
Нет, просто ты упустил из виду ключевой момент — как делать маленькие задержки и как правильно обрабатывать такие результаты. В виндовс это мягко говоря нетривиальная задача. Например rdtsc который ты указал, тоже имеет нюансы использования. И QueryPerformanceCounter имеет нюансы.
Ты же великий реалтаймщик, распинаешься перед публикой которая непонимает ни капли , по твоим словам, в реалтайме, а сам не можешь рассказать, какие же подводные камни у этого реалтайма.
I>>Конкретно это особенность виндов, потому что например QNX такой вот особенностью не обладает. А лялих имеет ровно такую же проблему, как и винда.
V>Боюсь, что это зависит больше от драйвера, а не от операционки.
Неправильно думаешь. ОСРВ гарантирует с большой точностью время работы системных вызовов. В QNX поток, который выполняет ожидание на момент окончания этого ожидания имеет наивысший приоритет, а в винде этого нет. Ну и инверсию приоритетов не надо забывать и много чего еще, например обработку аппаратных прерываний, здесь тоже есть ключевые различия, например в QNX ни просыпающийся веник, ни говнодрайвер в принципе не способны заморозить систему, а в винде это норма.
Собственно, что это я тебе рассказываю, ты ведь специалист по реалтайму вроде и сам всё знаешь и понимаешь.
V>>>Могу еще предположить, что на машине крутились реалтаймовые потоки, которые не давали работать остальным потокам. Иначе, покажи как воспроизвести. I>>В винде задержка зависит от нагрузки. В ОСРВ задержка _не_ зависит от нагрузки.
V>Ничего от "просто нагрузки" не зависит.
Зависит.
I>>"Дергать GC" это например вызывать new для референстайпов.
V>Опять и снова — интересуют всегда затраты на уборку, а не на выделение.
Да-да. Все правильно. new инициирует уборку. Это что, новость ?
Здравствуйте, vdimas, Вы писали:
I>>"Количество повторно неиспользуемого кода" это что за термин ?
V>Это речь о раздельных кешах для данных и для инструкций.
Это я догадался, хотелось бы точное определение, а не то через 5 сообщений ты снова скажешь, что GC работает быстро если его не трогать.
I>>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.
V>Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.
Подай в суд на вындоус за эти неожиданности
I>>Если ты не понял, то объясняю еще раз — GC работает на боевом приложении с такой же скоростью как и на синтетическом. Разница исключительно в разнообразии типов, в синтетическом его, разнообразия, просто нет. И именно по этой причине я сомневаюсь в твоих словах.
V>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда.
Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?
I>>Это не требует разнообразия типов, хватит и просто большого количества объектов. V>Гы, и обратное тоже верно. Молодца, хорошо споришь.
Моя модель более простая, понимаешь что это значит с т.з. диагностики ?
I>>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep
V>В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД.
Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC
V>Мы вообще с издержками боремся, а эти издержки очень многофакторны.
Буду знать, а то я было решил что ты акк кому то дал.
Здравствуйте, vdimas, Вы писали:
I>>Машина не может спать. Если бы ты про дос говорил,тогда можно было бы понять. Но винда сама использует процессор а следовательно и кеш.
V>Да как-то дохрена она собственного кода пробегает в режиме "ничегонеделания". То бишь быстрое протухание кеша инструкций (см. временную сетку) лично для меня явилось когда-то неожиданностью.
Задачка.
Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд.
Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10.
Никакого дотнета, олдскульный С даже без плюсов.
Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
Здравствуйте, Ikemefula, Вы писали:
I>Задачка.
I>Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд. I>Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10. I>Никакого дотнета, олдскульный С даже без плюсов.
I>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
просто любопытствую:
реально с таким сталкивался?
как заборол(и)?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
I>Есть алгоритм обработки данных, данные — просто гигантский массив в памяти. Алгоритм распараллеливается на раз, т.е. нет никаких зависимостей по данным между потоками и соотсветсвенно нет никакой синхронизации и тд и тд. I>Фокус — алгоритм показывает перформанс 1000 условных единиц. Два, три и более потоков показывают условный перформанс <10. I>Никакого дотнета, олдскульный С даже без плюсов.
Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.
I>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. ))
Ты показал эффект от нелокальности данных для потока, более ничего.
Здравствуйте, vdimas, Вы писали:
I>>Никакого дотнета, олдскульный С даже без плюсов.
V>Настолько клинический эффект бывает только от деления одних и тех же линеек кеша м/у ядрами. Давай исходник, покажу как правильно расставить pad-ы в данных.
Извини, 5 или 6 лет назад не знали, что ты сможешь решить, потому решили сами. И я кстати, не уверен, что там были многоядерные процы.
I>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
V>Пффф.. Описанное тобою не имеет ничего общего с протуханием кеша. То бишь аргумент про детский лепет я тебе, пожалуй, возвращу. )) V>Ты показал эффект от нелокальности данных для потока, более ничего.
Я не знаю какой смысл ты вкладываешь в "протухание кеша"
Здравствуйте, Философ, Вы писали:
I>>Вот это называется "протухание кеша", а то что ты выдал это детский лепет.
Ф>просто любопытствую: Ф>реально с таким сталкивался?
Да.
Ф>как заборол(и)?
Просто по другому озадачили треды, они перестали сбрасывать друг другу линейки кеша.
V>>Если речь о таких паузах GC как у тебя, то ес-но работает НЕ так же. Попробуй получить эти же паузы на своем тесте, где гоняется только 0-е поколение. Не добьешься никогда. I>Расскажи, в каком из примерно десятка тестов, что я сделал за последнюю неделю, гоняется только 0-е поколение ?
Словами ты описал мне именно это. Код всё-равно не показал. И да, не уходи от ответа на вопрос: в синтетических тестах получал ли свои 15 сек паузы на GC?
I>>>Это не требует разнообразия типов, хватит и просто большого количества объектов. V>>Гы, и обратное тоже верно. Молодца, хорошо споришь.
I>Моя модель более простая,
Она более однобока с т.з. происходящего в реальном коде.
Хотя, если речь о твоём клиническом случае в десятки миллионов объектов, то... то какого хрена там делает дотнет, не пояснишь? Он не для этих сценариев.
I>понимаешь что это значит с т.з. диагностики ?
Ес-но понимаю. Это означает нерелевантность любых синтетических результатов по такой модели.
I>>>Нет, именно узлов в дереве, кури вычислительную сложность mark'n'sweep V>>В общем, всё с тобой ясно. При чем тут обновление ссылок в объектах 2-го поколения ты даже не в курсе... ЧТД. I>Вообще то ты говоришь про оптимизацию, которая и нужна как раз из за того, что количетсво узлов слишком сильно влияет на перформанс GC
Нет, речь не о кол-ве узлов, а именно что об простом обновлении ссылочных полей "старых" объектов. Попробуй еще раз.
V>>Мы вообще с издержками боремся, а эти издержки очень многофакторны. I>Буду знать, а то я было решил что ты акк кому то дал.
Да не будешь ты знать... ты пытаешься модель заранее урезать и высмеиваешь любые попытки сделать наоборот.
Только вот зачем было так писать, вроде бы тут не девочки форум читают, зачем так умничать и всем известные вещи называть непонятными словами и выдавать за откровения?
