Повышение производительности с использованием uop-кэша на Sandy Bridge+

И всё это сделать глядя на C'шный код? ;)

Изначально не было кода на C и я просто хотел разобраться как ведет себя µop cache в различных ситауциях. Например, известный CPU Erratum описывает неожидаемое поведение кэша при наличии jcc в конце 32-байтного региона. Мне хотелось понять, есть ли что-то похожее на моем железе и, собирая метрики для различных случаев, я случайно наткнулся на проседание в retirement bandwidth при 7-ми микрооперациях. Далее, разобравшись почему так происходит, мне стало интересно будет ли это заментым ограничителем по производительности для, скажем, L1d-bound кода. Я рассмотрел пример, который содержит 7 микроопераций в цикле и померил его. Посколько метрика resource_stall.any была на 4 порядка меньше uops_retired.total_cycles стало ясно, что пропускной способности L1D хватало, чтобы не давать переполниться ROB, MOB(SB+LB) и RS. На графиках видно, что при цикле из 12-микроопераций проседания retirement bandwidth не наблюдается (6 + 6 за 2 такта, при пиковой Renamer bandwidth 4 + 4 за 2 такта), поэтому для устранения этой неэффективности достаточно раскрутить цикл один раз, так что он будет содержать 12 микроопераций.

А вот практический пример не особо понятен.

Для оценки раскидывания микроопераций по линиям можно использовать тот же подход, что и в случае с nop-ами. В данном случае добавляеются операции чтения и записи. Документация Intel описывает, что запись состоит из 2-х микроопераций (Store Address, Store Data), однако к данной инструкции применяется Micro Fusion — т.е. в µop cache они будут храниться как одна микрооперация, а при попадании в RS эта микрооперация будет зашедулена на 2 соответствующих порта. (Т.е. Micro Fusion — это когда одна микрооперация шедулиться несколько раз). Также к cmp-jne применяется Macro Fusion, т.е. две инструкции схлопываются в одну микрооперацию и шедулятся один раз. Таким образом, учитывая micro/macro fusion получаем 7 микроопераций в цикле