Как работает индексирование кеша данных Lake Lake 48KiB L1?

Question

В ручной оптимизации Intel (редакция от сентября 2019 г.) показан 8-канальный ассоциативный кэш данных L1 48 КиБ для микроархитектуры Ice Lake.

^{1 Задержка / пропускная способность, видимая программным обеспечением, будет варьироваться в зависимости от моделей доступа и других факторов.}

Это сбило меня с толку, потому что:

• Есть 96 комплектов (48 КиБ / 64/8), который не является степенью двойки.
• Биты индексации набора и биты индексации байтового смещения добавляют к более чем 12 битам, что делает cheap-PIPT -as-VIPT-trick недоступно для страниц объемом 4 КБ.

В целом, кажется, что кэш обходится дороже, но задержка увеличилась лишь незначительно (если она вообще была в зависимости от того, что Intel означает именно с этим числом).

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

Чего мне не хватает?

Answer 1

Руководство по оптимизации неверно.

Согласно инструкции CPUID, ассоциативность равна 12 (на Core i5-1035G1). См. Также uops.info / cache. html и en.wikichip.org / wiki / intel / microarchitectures / ice_lake_ (клиент) .

Это означает, что Есть 64 набора, что соответствует предыдущим микроархитектурам.

Answer 2

Как в руководстве по оптимизации, так и в таблице семейства процессоров (раздел 2.4.2) упоминается, что кэш данных L1 является 8-сторонним ассоциативным. Другой источник - InstLatx64, который предоставляет cpuid дампов для многих процессоров, включая процессоры Ice Lake. Возьмите, например, дамп для i7-1065G7

CPUID 00000004: 1C004121-02C0003F-0000003F-00000000 [SL 00]

Информация о кэше может можно найти в cpuid листе 0x4. В Intel SDM Volume 2 обсуждается, как декодировать эти байты. Биты 31 - 22 EBX (второй слева) представляют собой количество способов минус один. Эти биты в двоичном виде являются 1011, что является 11 в десятичном виде. Итак, cpuid говорит, что есть 12 способов. Другая информация, которую мы можем получить здесь, состоит в том, что кэш данных L1 имеет размер 48 КБ, с размером строки 64-байтового кэша и использует простую схему адресации. Таким образом, основываясь на информации cpuid, биты 11-6 адреса представляют индекс набора кэша.

Итак, какой из них правильный? Руководство по оптимизации может быть неправильным (и это будет не в первый раз), но также дамп cpuid может содержать ошибки (и это не будет в первый раз). Ну, оба могут ошибаться, но исторически это гораздо менее вероятно. Другие примеры расхождений между руководством и информацией cpuid обсуждаются здесь , поэтому мы знаем, что ошибки существуют в обоих источниках. Более того, я не знаю ни одного другого источника Intel, в котором упоминается количество путей в L1D. Конечно, источники не от Intel также могут быть ошибочными.

Наличие 8 способов с 96 наборами может привести к необычной конструкции и вряд ли произойдет без простого упоминания одного числа в руководстве по оптимизации ( хотя это не обязательно означает, что кэш должен иметь 12 способов). Это само по себе делает руководство более вероятным, что оно здесь не так.

К счастью, Intel исправляет ошибки реализации в своих процессорах в документах обновления spe c. Мы можем проверить с помощью spe c документ обновления для процессоров Ice Lake, который вы можете найти здесь . Здесь задокументированы две cpuid ошибки:

CPUL TLB Информация неточная

Я уже обсуждал эту проблему в своем ответе на Понимание TLB из CPUID результаты на Intel . Вторая ошибка:

Информация о кеше CPU2 L2 может быть неточной

Это не относится к вашему вопросу.

Тот факт, что в обновленном документе spe c упоминаются некоторые ошибки cpuid, убедительно свидетельствует о том, что информация из cpuid leaf 0x4 была проверена Intel и является точной. Таким образом, руководство по оптимизации (и таблица данных), вероятно, в этом случае неверно.