Обновить

Всего одна строка кода, из-за которой 24-ядерный сервер стал работать медленнее ноутбука

Время на прочтение13 мин
Охват и читатели34K
Всего голосов 47: ↑44 и ↓3+55
Комментарии13

Комментарии 13

У интеловских камушков есть соответствующие счётчики производительности, которые можно получить, там можно всё что угодно посмотреть - от промахов по кэшу любого уровня до промахов предсказателя переходов и даже отдельную инфу о количестве инструкций, что летят через порты можно вытащить, надо только уметь пользоваться. Иногда в "мистических случаях" помогает и экономит время, иначе приходится лишь гадать по изменению поведения на те или иные изменения кода.

Хороший пример того, как проблема годами живёт, пока нагрузка не вырастет и не вскроет всё сразу. А какие метрики вы бы советовали смотреть в первую очередь, чтобы такие вещи ловить раньше?

Вот если бы еще в заголовках авторы указывали предмет статьи, то другие бы люди не тратили зря своё время на подобные опусы

Всё ещё веселее, если вспомнить что сейчас пошли процессоры, в которых раздельный кеш L3 для групп ядер. Соответственно, если на них запустить по потоку на ядро с общим атомарным значением, то каждый поток каждый раз будет читать его из оперативки.

Группы таких процессоров, к слову, даже представляются раздельными NUMA-доменами в ACPI.

В принципе даже раздельность L1 и L2 кэшей уже влияет. Вот тут в комментарии спин ожидание в двух конкурентных очередях мы как раз обсуждали ускорение спинлока на гипертредированных ядрах за счёт того, что у них кэш общий на пару. У меня нет процессора с раздельным L3, но есть гибридный i7-13850, и там этот эффект точно также наблюдается. Ну то есть если спин лок на двух раздельных E ядрах запускать, то разница более чем шестикратная (там, конечно, ещё сильно влияет низкая производительность Е ядер, но тем не менее):

Код там выше в комменте был.

Именно. При разделенном L3 это уже не просто контеншен, а постоянные промахи кэша и походы в память из-за когерентности. Особенно если значение часто инкрементится

Здесь прям классика про ложную уверенность в атомиках. На одном сокете оно еще терпимо, а на двух сокетах кэш-линия со счетчиком начинает мигрировать и превращается в точку сериализации. Особенно когда клонирование Arc происходит на каждом вызове

Почитал, спасибки интересно. Только не очень понял как ноутбучный проц с 4 ядрами, при общем кеше тоже L3 вытащила 8Моп/с? Общий кэш, как понимаю, того же третьего уровня. Что дало бы тестирование исправленного кода на ноутбуке тогда?

21 век на дворе, а у людей дальше счётчика ссылок мысль не работает. Я критику счётчика ссылок как метода управления памятью читал, помнится, ещё в книге Пратта 1970-х годов. Но программирование же наука не дворянская, и так сойдёт.

Это тот Пратт, который из алгоритма Кнута-Морриса-Пратта? О какой конкретно книге идёт речь, если не секрет?

Другой Пратт, Терренс. "Языки программирования: разработка и реализация".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации