Комментарии 13
У интеловских камушков есть соответствующие счётчики производительности, которые можно получить, там можно всё что угодно посмотреть - от промахов по кэшу любого уровня до промахов предсказателя переходов и даже отдельную инфу о количестве инструкций, что летят через порты можно вытащить, надо только уметь пользоваться. Иногда в "мистических случаях" помогает и экономит время, иначе приходится лишь гадать по изменению поведения на те или иные изменения кода.
Хороший пример того, как проблема годами живёт, пока нагрузка не вырастет и не вскроет всё сразу. А какие метрики вы бы советовали смотреть в первую очередь, чтобы такие вещи ловить раньше?
Вот если бы еще в заголовках авторы указывали предмет статьи, то другие бы люди не тратили зря своё время на подобные опусы
Уже переводили же: https://habr.com/ru/companies/mvideo/articles/649009/
Всё ещё веселее, если вспомнить что сейчас пошли процессоры, в которых раздельный кеш L3 для групп ядер. Соответственно, если на них запустить по потоку на ядро с общим атомарным значением, то каждый поток каждый раз будет читать его из оперативки.
Группы таких процессоров, к слову, даже представляются раздельными NUMA-доменами в ACPI.
В принципе даже раздельность L1 и L2 кэшей уже влияет. Вот тут в комментарии спин ожидание в двух конкурентных очередях мы как раз обсуждали ускорение спинлока на гипертредированных ядрах за счёт того, что у них кэш общий на пару. У меня нет процессора с раздельным L3, но есть гибридный i7-13850, и там этот эффект точно также наблюдается. Ну то есть если спин лок на двух раздельных E ядрах запускать, то разница более чем шестикратная (там, конечно, ещё сильно влияет низкая производительность Е ядер, но тем не менее):

Код там выше в комменте был.
Именно. При разделенном L3 это уже не просто контеншен, а постоянные промахи кэша и походы в память из-за когерентности. Особенно если значение часто инкрементится
Здесь прям классика про ложную уверенность в атомиках. На одном сокете оно еще терпимо, а на двух сокетах кэш-линия со счетчиком начинает мигрировать и превращается в точку сериализации. Особенно когда клонирование Arc происходит на каждом вызове
Почитал, спасибки интересно. Только не очень понял как ноутбучный проц с 4 ядрами, при общем кеше тоже L3 вытащила 8Моп/с? Общий кэш, как понимаю, того же третьего уровня. Что дало бы тестирование исправленного кода на ноутбуке тогда?
21 век на дворе, а у людей дальше счётчика ссылок мысль не работает. Я критику счётчика ссылок как метода управления памятью читал, помнится, ещё в книге Пратта 1970-х годов. Но программирование же наука не дворянская, и так сойдёт.

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