Кеши L1 обычно имеют раздельную конструкцию, но кеши L2, L3 имеют единую конструкцию, почему?

Я читал плюсы и минусы раздельного дизайна и унифицированного дизайна кешей в Этот поток.

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

Я, однако, не смог найти интуитивно понятного ответа на вопрос, почему (по крайней мере, в большинстве современных процессоров) кэши L1 следуют раздельному дизайну, а кэши L2 / L3 следуют единому дизайну.)


person Rajesh    schedule 03.10.2020    source источник


Ответы (1)


Основная причина разделения L1 состоит в том, чтобы распределить необходимые порты чтения / записи (и, следовательно, полосу пропускания) между двумя кешами и разместить их физически близко к частям конвейера загрузки / хранения данных, а не к частям выборки инструкций.

Также для L1d для обработки байтовой загрузки / сохранения (и на некоторых ISA, невыровненных более широких загрузок / хранилищ). На процессорах x86, которые хотят обрабатывать это с максимальной эффективность (не RMW содержащего слова (слов)), Intel L1d может использовать только четность, но не ECC. L1i должен обрабатывать только выборки фиксированной ширины, часто что-то простое, например выровненный 16-байтовый фрагмент, и он всегда чистый, потому что он доступен только для чтения, поэтому ему нужно только обнаруживать ошибки (не правильно), и просто повторите загрузку. Таким образом, у него может быть меньше накладных расходов для каждой строки данных, например, только пара битов четности на 8 или 16 байтов.

См. Почему размер кэша L1 меньше, чем размер кеша L2 в большинстве процессоров? re: невозможно создать один большой унифицированный кеш L1 с удвоенной пропускной способностью, той же задержкой и суммой пропускной способности, как у разделенного L1i / d. (По крайней мере, чрезмерно дороже для питания из-за размера и количества портов чтения / записи, но потенциально фактически невозможно из-за задержки из-за физического расстояния.)

Ни один из этих факторов не важен для L2 (или вообще не существует в случае невыровненных / байтовых хранилищ). Общая емкость, которую можно использовать для кода или данных, наиболее полезна в этом случае и распределяется на конкурсной основе по запросу.

Очень редко для любой рабочей нагрузки будет много промахов L1i и L1d в одном тактовом цикле, потому что частые промахи кода означают, что внешний интерфейс останавливается, а серверная часть будет работать без нагрузки / хранить инструкции для выполнения. (Частые промахи L1i случаются редко, но частые промахи L1d действительно случаются при некоторых обычных рабочих нагрузках, например, при зацикливании массива, который не помещается в L1d, или большой хеш-таблицы, или другой более разрозненной модели доступа.) В любом случае это означает, что данные могут быть получить большую часть общего бюджета полосы пропускания L2 в нормальных условиях, а унифицированному L2 по-прежнему нужен только 1 порт чтения.

Ответ @Hadi, который вы связали, охватывает большинство из этих причин, но я думаю, не повредит написать упрощенный / сводный ответ.

person Peter Cordes    schedule 03.10.2020
comment
Просто заметил это. Хорошее резюме. Но я пытаюсь обдумать часть о байтовых загрузках / хранилищах. Вы, безусловно, можете создать унифицированный кеш, поддерживающий неограниченную адресацию. Обращение к L1I проще. Например, в процессорах Intel все выборки в байтовый буфер команд выровнены по 16 байтов, поэтому IFU может опускать 4 младших бита физического адреса при поиске структур памяти IFU (L1I, кэш жертвы, ISB). Это приводит к немного меньшей площади и мощности по сравнению с унифицированным дизайном, но я не знаю никого, кто считал бы это значительной экономией. - person Hadi Brais; 20.03.2021
comment
@HadiBrais: Хм, теперь, когда я думаю об этом, если бы у вас был единый кеш с вдвое большим размером и совокупным количеством портов чтения, порт чтения выборки инструкций мог бы быть проще. По крайней мере, для чтения, большая часть работы по обработке невыровненного внутри строки выполняется на оборудовании, которое существует один раз на порт чтения, а не один раз на строку данных. А для написания - IDK, если при адресации есть большая экономия. - person Peter Cordes; 20.03.2021
comment
@HadiBrais: Но суть в ECC стоит: если вы хотите иметь возможность обновлять любую отдельную коллекцию байтов, вам либо нужен word-RMW, когда вы не пишете полную гранулу ECC, либо ваши гранулы ECC должны быть 1 Б (высокие накладные расходы) , или вам нужно использовать только паритет, как, по слухам, Intel делает для L1d. Эта стоимость зависит от размера массива, поэтому, если половина вашего кэша L1 будет I-кешем, эта половина будет использовать более эффективный ECC. Возможно, вы отделяли это от другого механизма байтовой / невыровненной загрузки / хранения. - person Peter Cordes; 20.03.2021
comment
Да, это действительно так (и я не упомянул об этом в своем ответе). Количество доступов к данным обычно намного больше, чем количество обращений к L1I, поэтому L1D может потребовать защиты на уровне ECC, но для L1I может быть достаточно контроля четности. При унифицированном дизайне каждая запись потребует ECC, что значительно увеличивает накладные расходы на площадь и мощность (и, возможно, снижает производительность) по сравнению с разделением. Вы знаете какой-либо реальный процессор, который использует ECC для L1I? Кажется, я ничего не могу вспомнить. - person Hadi Brais; 20.03.2021
comment
@HadiBrais: Ах да, я забыл, что L1i особенный, потому что он никогда не бывает грязным: он может просто перечитать, если обнаружит ошибку. Так что да, обычно просто паритет звучит правильно. - person Peter Cordes; 20.03.2021
comment
Вполне вероятно, что L1D использует ECC, а не паритет в большинстве процессоров (не только от Intel). Я помню, как обсуждал с вами инструмент в Linux, который показывает, какой метод обнаружения ошибок используется на каждом уровне кэша (но мы не были уверены, откуда инструмент получает данные). Я не смог найти обсуждение (я думаю, что это в разделе комментариев некоторых связанных вопросов и ответов). В любом случае, я помню инструмент, сообщающий о ECC для L1D, что, скорее всего, правильно. - person Hadi Brais; 20.03.2021