Кэш процессора на что влияет. Небольшое сравнение L3 кэша в играх и приложениях

Насколько важен кэш L3 для процессоров AMD?

Действительно, имеет смысл оснащать многоядерные процессоры выделенной памятью, которая будет использоваться совместно всеми доступными ядрами. В данной роли быстрый кэш третьего уровня (L3) может существенно ускорить доступ к данным, которые запрашиваются чаще всего. Тогда ядрам, если существует такая возможность, не придётся обращаться к медленной основной памяти (ОЗУ, RAM).

По крайней мере, в теории. Недавно AMD анонсировала процессор Athlon II X4, представляющий собой модель Phenom II X4 без кэша L3, намекая на то, что он не такой и необходимый. Мы решили напрямую сравнить два процессора (с кэшем L3 и без), чтобы проверить, как кэш влияет на производительность.

Как работает кэш?

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

Попадания и промахи

Эффективность архитектуры кэшей измеряется процентом попаданий. Запросы данных, которые могут быть удовлетворены кэшем, считаются попаданиями. Если данный кэш не содержит нужные данные, то запрос передаётся дальше по конвейеру памяти, и засчитывается промах. Конечно, промахи приводят к большему времени, которое требуется для получения информации. В результате в вычислительном конвейере появляются "пузырьки" (простои) и задержки. Попадания, напротив, позволяют поддержать максимальную производительность.

Запись в кэш, эксклюзивность, когерентность

Политики замещения диктуют, как в кэше освобождается место под новые записи. Поскольку данные, записываемые в кэш, рано или поздно должны появиться в основной памяти, системы могут делать это одновременно с записью в кэш (write-through) или могут маркировать данные области как "грязные" (write-back), а выполнять запись в память тогда, когда она будет вытесняться из кэша.

Данные в нескольких уровнях кэша могут храниться эксклюзивно, то есть без избыточности. Тогда вы не найдёте одинаковых строчек данных в двух разных иерархиях кэша. Либо кэши могут работать инклюзивно, то есть нижние уровни кэша гарантированно содержат данные, присутствующие в верхних уровнях кэша (ближе к процессорному ядру). У AMD Phenom используются эксклюзивный кэш L3, а Intel следует стратегии инклюзивного кэша. Протоколы когерентности следят за целостностью и актуальностью данных между разными ядрами, уровнями кэшей и даже процессорами.

Объём кэша

Больший по объёму кэш может содержать больше данных, но при этом наблюдается тенденция увеличения задержек. Кроме того, большой по объёму кэш потребляет немалое количество транзисторов процессора, поэтому важно находить баланс между "бюджетом" транзисторов, размером кристалла, энергопотреблением и производительностью/задержками.

Ассоциативность

Записи в оперативной памяти могут привязываться к кэшу напрямую (direct-mapped), то есть для копии данных из оперативной памяти существует только одна позиция в кэше, либо они могут быть ассоциативны в n-степени (n-way associative), то есть существует n возможных расположений в кэше, где могут храниться эти данные. Более высокая степень ассоциативности (вплоть до полностью ассоциативных кэшей) обеспечивает наилучшую гибкость кэширования, поскольку существующие данные в кэше не нужно переписывать. Другими словами, высокая n-степень ассоциативности гарантирует более высокий процент попаданий, но при этом увеличивается задержка, поскольку требуется больше времени на проверку всех этих ассоциаций для попадания. Как правило, наибольшая степень ассоциации разумна для последнего уровня кэширования, поскольку там доступна максимальная ёмкость, а поиск данных за пределами этого кэша приведёт к обращению процессора к медленной оперативной памяти.

Приведём несколько примеров: у Core i5 и i7 используется 32 кбайт кэша L1 с 8-way ассоциативностью для данных и 32 кбайт кэша L1 с 4-way для инструкций. Понятно желание Intel, чтобы инструкции были доступны быстрее, а у кэша L1 для данных был максимальный процент попаданий. Кэш L2 у процессоров Intel обладает 8-way ассоциативностью, а кэш L3 у Intel ещё "умнее", поскольку в нём реализована 16-way ассоциативность для максимизации попаданий.

Однако AMD следует другой стратегии с процессорами Phenom II X4, где используется кэш L1 с 2-way ассоциативностью для снижения задержек. Чтобы компенсировать возможные промахи ёмкость кэша была увеличена в два раза: 64 кбайт для данных и 64 кбайт для инструкций. Кэш L2 имеет 8-way ассоциативность, как и у дизайна Intel, но кэш L3 у AMD работает с 48-way ассоциативностью. Но решение выбора той или иной архитектуры кэша нельзя оценивать без рассмотрения всей архитектуры CPU. Вполне естественно, что практическое значение имеют результаты тестов, и нашей целью как раз была практическая проверка всей этой сложной многоуровневой структуры кэширования.

Кэш — память (кеш , cash , буфер — eng.) — применяется в цифровых устройствах, как высокоскоростной буфер обмена. Кэш память можно встретить на таких устройствах компьютера как , процессоры, сетевые карты, приводы компакт дисков и многих других.

Принцип работы и архитектура кэша могут сильно отличаться.

К примеру, кэш может служить как обычный буфер обмена . Устройство обрабатывает данные и передаёт их в высокоскоростной буфер, где контроллёр передаёт данные на интерфейс. Предназначен такой кэш для предотвращения ошибок, аппаратной проверки данных на целостность, либо для кодировки сигнала от устройства в понятный сигнал для интерфейса, без задержек. Такая система применяется например в CD/DVD приводах компакт дисков.

В другом случае, кэш может служить для хранения часто используемого кода и тем самым ускорения обработки данных. То есть, устройству не нужно снова вычислять или искать данные, что заняло бы гораздо больше времени, чем чтение их из кэш-а. В данном случае очень большую роль играет размер и скорость кэш-а.

Такая архитектура чаще всего встречается на жёстких дисках, и центральных процессорах (CPU ).

При работе устройств, в кэш могут загружаться специальные прошивки или программы диспетчеры, которые работали бы медленней с ПЗУ (постоянное запоминающее устройство).

Большинство современных устройство, используют смешанный тип кэша , который может служить как буфером обмена, как и для хранения часто используемого кода.

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

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

Общий кэш , также позволяет ядрам работать с ним напрямую, минуя медленную .

Кэш для инструкций. Существует либо общий очень быстрый кэш первого уровня для инструкций и других операций, либо специально выделенный под них. Чем больше в процессоре заложенных инструкций, тем больший кэш для инструкций ему требуется. Это уменьшает задержки памяти и позволяет блоку инструкций функционировать практически независимо.При его заполнении, блок инструкций начинает периодически простаивать, что замедляет скорость вычисления.

Другие функции и особенности .

Примечательно, что в CPU (центральных процессорах), применяется аппаратная коррекция ошибок (ECC ), потому как небольшая ошибочка в кэше, может привести к одной сплошной ошибке при дальнейшей обработке этих данных.

В CPU и GPU существует иерархия кэш памяти , которая позволяет разделять данные для отдельных ядер и общие. Хотя почти все данные из кэша второго уровня, всё равно копируются в третий, общий уровень, но не всегда. Первый уровень кеша — самый быстрый, а каждый последующий всё медленней, но больше по размеру.

Для процессоров, нормальным считается три и менее уровней кэша. Это позволяет добиться сбалансированности между скоростью, размером кэша и тепловыделением. В видеопроцессорах сложно встретить более двух уровней кэша.

Размер кэша, влияние на производительность и другие характеристики .

Естественно, чем больше кэш , тем больше данных он может хранить и обрабатывать, но тут есть серьёзная проблема.

Большой кеш — это большой бюджет . В серверных процессорах (CPU ), кэш может использовать до 80% транзисторного бюджета. Во первых, это сказывается на конечной стоимости, а во вторых увеличивается энергопотребление и тепловыделение, которое не сопоставимо с увеличенной на несколько процентов производительностью.

Приветствуем вас на сайте GECID.com! Хорошо известно, что тактовая частота и количество ядер процессора напрямую влияют на уровень производительности, особенно в оптимизированных под многопоточность проектах. Мы же решили проверить, какую роль в этом играет кэш-память уровня L3?

Для исследования этого вопроса нам был любезно предоставлен интернет-магазином pcshop.ua 2-ядерный процессор с номинальной рабочей частотой 3,7 ГГц и 3 МБ кэш-памяти L3 с 12-ю каналами ассоциативности. В роли оппонента выступил 4-ядерный , у которого были отключены два ядра и снижена тактовая частота до 3,7 ГГц. Объем же кэша L3 у него составляет 8 МБ, и он имеет 16 каналов ассоциативности. То есть ключевая разница между ними заключается именно в кэш-памяти последнего уровня: у Core i7 ее на 5 МБ больше.

Если это ощутимо повлияет на производительность, тогда можно будет провести еще один тест с представителем серии Core i5, у которых на борту 6 МБ кэша L3.

Но пока вернемся к текущему тесту. Помогать участникам будет видеокарта и 16 ГБ оперативной памяти DDR4-2400 МГц. Сравнивать эти системы будем в разрешении Full HD.

Для начала начнем с рассинхронизированных живых геймплев, в которых невозможно однозначно определить победителя. В Dying Light на максимальных настройках качества обе системы показывают комфортный уровень FPS, хотя загрузка процессора и видеокарты в среднем была выше именно в случае Intel Core i7.

Arma 3 имеет хорошо выраженную процессорозависимость, а значит больший объем кэш-памяти должен сыграть свою позитивную роль даже при ультравысоких настройках графики. Тем более что нагрузка на видеокарту в обоих случаях достигала максимум 60%.

Игра DOOM на ультравысоких настройках графики позволила синхронизировать лишь первые несколько кадров, где перевес Core i7 составляет около 10 FPS. Рассинхронизация дельнейшего геймплея не позволяет определить степень влияния кэша на скорость видеоряда. В любом случае частота держалась выше 120 кадров/с, поэтому особого влияния даже 10 FPS на комфортность прохождения не оказывают.

Завершает мини-серию живых геймплеев Evolve Stage 2 . Здесь мы наверняка увидели бы разницу между системами, поскольку в обоих случаях видеокарта загружена ориентировочно на половину. Поэтому субъективно кажется, что уровень FPS в случае Core i7 выше, но однозначно сказать нельзя, поскольку сцены не идентичные.

Более информативную картину дают бенчмарки. Например, в GTA V можно увидеть, что за городом преимущество 8 МБ кэша достигает 5-6 кадров/с, а в городе - до 10 FPS благодаря более высокой загрузке видеокарты. При этом сам видеоускоритель в обоих случаях загружен далеко не на максимум, и все зависит именно от CPU.

Третий ведьмак мы запустили с запредельными настройками графики и высоким профилем постобработки. В одной из заскриптованных сцен преимущество Core i7 местами достигает 6-8 FPS при резкой смене ракурса и необходимости подгрузки новых данных. Когда же нагрузка на процессор и видеокарту опять достигают 100%, то разница уменьшается до 2-3 кадров.

Максимальный пресет графических настроек в XCOM 2 не стал серьезным испытанием для обеих систем, и частота кадров находилась в районе 100 FPS. Но и здесь больший объем кэш-памяти трансформировался в прибавку к скорости от 2 до 12 кадров/с. И хотя обоим процессорам не удалось по максимум загрузить видеокарту, вариант на 8 МБ и в этом вопросе местами преуспевал лучше.

Больше всего удивила игра Dirt Rally , которую мы запустили с пресетом очень высоко. В определенные моменты разница доходила до 25 кадров/с исключительно из-за большего объема кэш-памяти L3. Это позволяло на 10-15% лучше загружать видеокарту. Однако средние показатели бенчмарка показали более скромную победу Core i7 - всего 11 FPS.

Интересная ситуация получилась и с Rainbow Six Siege : на улице, в первых кадрах бенчмарка, преимущество Core i7 составляло 10-15 FPS. Внутри помещения загрузка процессоров и видеокарты в обоих случаях достигла 100%, поэтому разница уменьшилась до 3-6 FPS. Но в конце, когда камера вышла за пределы дома, отставание Core i3 опять местами превышало 10 кадров/с. Средний же показатель оказался на уровне 7 FPS в пользу 8 МБ кэша.

The Division при максимальном качестве графики также хорошо реагирует на увеличение объема кэш памяти. Уже первые кадры бенчмарка по полной загрузили все потоки Core i3, а вот общая нагрузка на Core i7 составляла 70-80%. Однако разница в скорости в эти моменты составляла всего 2-3 FPS. Чуть позже нагрузка на оба процессора достигла 100%, а разница в определенные моменты уже была за Core i3, но лишь на 1-2 кадра/с. В среднем же она составила около 1 FPS в пользу Core i7.

В свою очередь бенчмарк Rise of Tomb Rider при высоких настройках графики во всех трех тестовых сценах наглядно показал преимущество процессора с значительно большим объемом кэш памяти. Средние показатели у него на 5-6 FPS лучше, но если внимательно посмотреть каждую сцену, то местами отставание Core i3 превышает 10 кадров/с.

А вот при выборе пресета с очень высокими настройками возрастает нагрузка на видеокарту и процессоры, поэтому в большинстве своем разница между системами уменьшается до нескольких кадров. И лишь кратковременно Core i7 может показывать более значимые результаты. Средние показатели его преимущества по итогам бенчмарка снизились до 3-4 FPS.

Hitman также меньше подвержен влиянию кэш-памяти L3. Хотя и здесь при ультравысоком профиле детализации дополнительные 5 МБ обеспечили лучшую загрузку видеокарты, превратив это в дополнительные 3-4 кадра/с. Особо критичного влияния на производительность они не оказывают, но из чисто спортивного интереса приятно, что есть победитель.

Высокие настройки графики Deus ex: Mankind divided сразу же потребовали максимальной вычислительной мощности от обеих систем, поэтому разница в лучшем случае составляла 1-2 кадра в пользу Core i7, на что указывает и средний показатель.

Повторный запуск при ультравысоком пресете еще сильнее загрузил видеокарту, поэтому влияние процессора на общую скорость стало еще меньшим. Соответственно, разница в кэш-памяти L3 практически не влияла на ситуацию и средний FPS отличался менее чем на полкадра.

По итогам тестирования можно отметить, что влияние кэш-памяти L3 на производительность в играх действительно имеет место, но оно проявляется лишь тогда, когда видеокарта не загружена на полную мощность. В таких случаях можно было бы получить прирост в 5-10 FPS, если бы кэш увеличился в 2,5 раза. То есть ориентировочно получается, что при прочих равных каждый дополнительный МБ кэш-памяти L3 добавляет только 1-2 FPS к скорости отображения видеоряда.

Так что, если сравнивать соседние линейки, например, Celeron и Pentium, или модели с разным объем кэш-памяти L3 внутри серии Core i3, то основной прирост производительности достигается благодаря более высоким частотам, а потом и наличию дополнительных процессорных потоков и ядер. Поэтому, выбирая процессор, в первую очередь, все же, нужно ориентироваться на основные характеристики, а только потом обращать внимание на объем кэш-памяти.

На этом все. Спасибо за внимание. Надеемся, этот материал был полезным и интересным.

Статья прочитана 27046 раз(а)

Подписаться на наши каналы

Почти все разработчики знают, что кэш процессора - это такая маленькая, но быстрая память, в которой хранятся данные из недавно посещённых областей памяти - определение краткое и довольно точное. Тем не менее, знание «скучных» подробностей относительно механизмов работы кэша необходимо для понимания факторов влияющих на производительность кода.

В этой статье мы рассмотрим ряд примеров иллюстрирующих различные особенности работы кэшей и их влияние на производительность. Примеры будут на C#, выбор языка и платформы не так сильно влияет на оценку производительности и конечные выводы. Естественно, в разумных пределах, если вы выберите язык, в котором чтение значения из массива равносильно обращению к хеш-таблице, никаких результатов пригодных к интерпретации вы не получите. Курсивом идут примечания переводчика.

Habracut - - -

Пример 1: доступ к памяти и производительность

Как вы думаете, насколько второй цикл быстрее первого?

int arr = new int ;

// первый
for (int i = 0; i < arr.Length; i++) arr[i] *= 3;

// второй
for (int i = 0; i < arr.Length; i += 16) arr[i] *= 3;

Первый цикл умножает все значения массива на 3, второй цикл только каждое шестнадцатое значение. Второй цикл совершает только 6% работы первого цикла, но на современных машинах оба цикла выполняются примерно за равное время: 80 мс и 78 мс соответственно (на моей машине).

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

Пример 2: влияние строк кэша

Копнём глубже - попробуем другие значения шага, не только 1 и 16:

for (int i = 0; i < arr.Length; i += K /* шаг */ ) arr[i] *= 3;

Вот время работы этого цикла для различных значений шага K:

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

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

Из-за того, что 16 значений типа int занимают 64 байта, циклы с шагами от 1 до 16 обращаются к одинаковому количеству строк кэша, точнее говоря, ко всем строкам кэша массива. При шаге 32, обращение происходит к каждой второй строке, при шаге 64, к каждой четвёртой.

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

Пример 3: размеры кэшей первого и второго уровня (L1 и L2)

Современные процессоры, как правило, имеют два или три уровня кэшей, обычно их называют L1, L2 и L3. Для того, чтобы узнать размеры кэшей различных уровней, можно воспользоваться утилитой CoreInfo или функцией Windows API GetLogicalProcessorInfo . Оба способа так же предоставляют информацию о размере строки кэша для каждого уровня.

На моей машине CoreInfo сообщает о кэшах данных L1 объёмом по 32 Кбайт, кэшах инструкций L1 объёмом по 32 Кбайт и кэшах данных L2 объёмом по 4 Мбайт. Каждое ядро имеет свои персональные кэши L1, кэши L2 общие для каждой пары ядер:

Logical Processor to Cache Map: *--- Data Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 *--- Instruction Cache 0, Level 1, 32 KB, Assoc 8, LineSize 64 -*-- Data Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 -*-- Instruction Cache 1, Level 1, 32 KB, Assoc 8, LineSize 64 **-- Unified Cache 0, Level 2, 4 MB, Assoc 16, LineSize 64 --*- Data Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 --*- Instruction Cache 2, Level 1, 32 KB, Assoc 8, LineSize 64 ---* Data Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 ---* Instruction Cache 3, Level 1, 32 KB, Assoc 8, LineSize 64 --** Unified Cache 1, Level 2, 4 MB, Assoc 16, LineSize 64
Проверим эту информацию экспериментально. Для этого, пройдёмся по нашему массиву инкрементируя каждое 16-ое значение - простой способ изменить данные в каждой строке кэша. При достижении конца, возвращаемся к началу. Проверим различные размеры массива, мы должны увидеть падение производительности когда массив перестаёт помещаться в кэши разных уровней.

Код такой:

int steps = 64 * 1024 * 1024; // количество итераций
int lengthMod = arr.Length - 1; // размер массива -- степень двойки

for (int i = 0; i < steps; i++)
{
// x & lengthMod = x % arr.Length, ибо степени двойки
arr[(i * 16) & lengthMod]++;
}

Результаты тестов:

На моей машине заметны падения производительности после 32 Кбайт и 4 Мбайт - это и есть размеры кэшей L1 и L2.

Пример 4: параллелизм инструкций

Теперь давайте взглянем на кое-что другое. По вашему мнению, какой из этих двух циклов выполнится быстрее?

int steps = 256 * 1024 * 1024;
int a = new int ;

// первый
for (int i = 0; i < steps; i++) { a++; a++; }

// второй
for (int i = 0; i < steps; i++) { a++; a++; }

Оказывается, второй цикл выполняется почти в два раза быстрее, по крайней мере, на всех протестированных мной машинах. Почему? Потому, что команды внутри циклов имеют разные зависимости по данным. Команды первого имеют следующую цепочку зависимостей:

Во втором цикле зависимости такие:

Функциональные части современных процессоров способны выполнять определённое число некоторых операций одновременно, как правило, не очень большое число. Например, возможен параллельный доступ к данным из кэша L1 по двум адресам, так же возможно одновременное выполнение двух простых арифметических команд. В первом цикле процессор не может задействовать эти возможности, но может во втором.

Пример 5: ассоциативность кэша

Один из ключевых вопросов, на который необходимо дать ответ при проектировании кэша - могут ли данные из определённой области памяти храниться в любых ячейках кэша или только в некоторых из них. Три возможных решения:

1. Кэш прямого отображения , данные каждой строки кэша в оперативной памяти хранятся только в одной заранее определённой ячейке кэша. Простейший способ вычисления отображения: индекс_строки_в_памяти % количество_ячеек_кэша. Две строки, отображённые на одну и ту же ячейку, не могут находится в кэше одновременно.
2. N-входовый частично-ассоциативный кэш , каждая строка может храниться в N различных ячейках кэша. Например, в 16-входовом кэше строка может храниться в одной из 16-ти ячеек составляющих группу. Обычно, строки с равными младшими битами индексов разделяют одну группу.
3. Полностью ассоциативный кэш , любая строка может быть сохранена в любую ячейку кэша. Решение эквивалентно хеш-таблице по своему поведению.

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

К примеру, на моей машине кэш L2 размером в 4 Мбайт является 16-входовым частично-ассоциативным кэшем. Вся оперативная память разделена на множества строк по младшим битам их индексов, строки из каждого множества соревнуются за одну группу из 16 ячеек кэша L2.

Так как кэш L2 имеет 65 536 ячеек (4 * 2 20 / 64) и каждая группа состоит из 16 ячеек, всего мы имеем 4 096 групп. Таким образом, младшие 12 битов индекса строки определяют к какой группе относится эта строка (2 12 = 4 096). В результате, строки с адресами кратными 262 144 (4 096 * 64) разделяют одну и ту же группу из 16-ти ячеек и соревнуются за место в ней.

Чтобы эффекты ассоциативности проявили себя, нам необходимо постоянно обращаться к большому количеству строк из одной группы, например, используя следующий код:

public static long UpdateEveryKthByte(byte arr, int K)
{
const int rep = 1024 * 1024; // количество итераций

Stopwatch sw = Stopwatch.StartNew();

int p = 0;
for (int i = 0; i < rep; i++)
{
arr[p]++;

P += K; if (p >= arr.Length) p = 0;
}

Sw.Stop();
return sw.ElapsedMilliseconds;
}

Метод инкрементирует каждый K-ый элемент массива. По достижении конца, начинаем заново. После довольно большого количества итераций (2 20), останавливаемся. Я сделал прогоны для различных размеров массива и значений шага K. Результаты (синий - большое время работы, белый - маленькое):

Синим областям соответствуют те случаи, когда при постоянном изменении данных кэш не в состоянии вместить все требуемые данные одновременно . Яркий синий цвет говорит о времени работы порядка 80 мс, почти белый - 10 мс.

Разберёмся с синими областями:

1. Почему появляются вертикальные линии? Вертикальные линии соответствуют значениям шага при которых осуществляется доступ к слишком большому числу строк (больше 16-ти) из одной группы. Для таких значений, 16-входовый кэш моей машины не может вместить все необходимые данные.

   Некоторые из плохих значений шага - степени двойки: 256 и 512. Для примера рассмотрим шаг 512 и массив в 8 Мбайт. При этом шаге, в массиве имеются 32 участка (8 * 2 20 / 262 144), которые ведут борьбу друг с другом за ячейки в 512-ти группах кэша (262 144 / 512). Участка 32, а ячеек в кэше под каждую группу только 16, поэтому места на всех не хватает.

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

2. Почему вертикальные линии обрываются на границе в 4 Мбайт? При размере массива в 4 Мбайт или меньше, 16-входовый кэш ведёт себя так же как и полностью ассоциативный, то есть может вместить все данные массива без конфликтов. Имеется не более 16-ти областей ведущих борьбу за одну группу кэша (262 144 * 16 = 4 * 2 20 = 4 Мбайт).
3. Почему слева вверху находится большой синий треугольник? Потому, что при маленьком шаге и большом массиве кэш не в состоянии уместить все необходимые данные. Степень ассоциативности кэша играет тут второстепенную роль, ограничение связано с размером кэша L2.

   Например, при размере массива в 16 Мбайт и шаге 128, мы обращаемся к каждому 128-му байту, таким образом, модифицируя каждую вторую строку кэша массива. Чтобы сохранить каждую вторую строку в кэше, необходим его объём в 8 Мбайт, но на моей машине есть только 4 Мбайт.

   Даже если бы кэш был полностью ассоциативным, это не позволило бы сохранить в нём 8 Мбайт данных. Заметьте, что в уже рассмотренном примере с шагом 512 и размером массива 8 Мбайт, нам необходим только 1 Мбайт кэша, чтобы сохранить все нужные данные, но это невозможно сделать из-за недостаточной ассоциативности кэша.

4. Почему левая сторона треугольника постепенно набирает свою интенсивность? Максимум интенсивности приходится на значение шага в 64 байта, что равно размеру строки кэша. Как мы увидели в первом и во втором примере, последовательный доступ к одной и той же строке практически ничего не стоит. Скажем, при шаге в 16 байт, мы имеем четыре обращения к памяти по цене одного.

   Так как количество итераций равно в нашем тесте при любом значении шага, то более дешёвый шаг в результате даёт меньшее время работы.

Обнаруженные эффекты сохраняются и при больших значениях параметров:

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

Пример 6: ложное разделение кэша

На многоядерных машинах можно столкнуться с другой проблемой - согласование кэшей. Ядра процессора имеют частично или полностью раздельные кэши. На моей машине кэши L1 раздельны (как и обычно), так же имеются два кэша L2, общие для каждой пары ядер. Детали могут различаться, но в целом современные многоядерные процессоры имеют многоуровневые иерархические кэши. Причём самые быстрые, но и самые маленькие кэши, принадлежат индивидуальным ядрам.

Когда одно из ядер модифицирует значение в своём кэше, другие ядра больше не могут использовать старое значение. Значение в кэшах других ядер должно быть обновлено. Более того, должна быть обновлена полностью вся строка кэша , так как кэши оперируют данными на уровне строк.

Продемонстрируем эту проблему на следующем коде:

private static int s_counter = new int ;

private void UpdateCounter(int position)
{
for (int j = 0; j < 100000000; j++)
{
s_counter = s_counter + 3;
}
}

Если на своей четырёхядерной машине я вызову этот метод с параметрами 0, 1, 2, 3 одновременно из четырёх потоков, то время работы составит 4.3 секунды . Но если я вызову метод с параметрами 16, 32, 48, 64, то время работы составит только 0.28 секунды .

Почему? В первом случае, все четыре значения, обрабатываемые потоками в каждый момент времени, с большой вероятностью попадают в одну строку кэша. Каждый раз когда одно ядро увеличивает очередное значение, оно помечает ячейки кэша, содержащие это значение в других ядрах, как невалидные. После этой операции, все остальные ядра должны будут закэшировать строку заново. Это делает механизм кэширования неработоспособным, убивая производительность.

Пример 7: сложность железа

Даже теперь, когда принципы работы кэшей для вас не секрет, железо по-прежнему будет преподносить вам сюрпризы. Процессоры отличаются друг от друга методами оптимизации, эвристиками и прочими тонкостями реализации.

Кэш L1 некоторых процессоров может осуществлять параллельный доступ к двум ячейкам, если они относятся к разным группам, но если они относятся к одной, только последовательно. Насколько мне известно, некоторые даже могут осуществлять параллельный доступ к разным четвертинкам одной ячейки.

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

Вот другой пример странных причуд железа:

private static int A, B, C, D, E, F, G;

private static void Weirdness()
{
for (int i = 0; i < 200000000; i++)
{
<какой-то код>
}
}

Если вместо <какой-то код> подставить три разных варианта, можно получить следующие результаты:

Инкрементирование полей A, B, C, D занимает больше времени, чем инкрементирование полей A, C, E, G. Что ещё страннее, инкрементирование полей A и C занимает больше времени, чем полей A, C и E, G. Не знаю точно каковы причины этого, но возможно они связаны с банками памяти (да-да, с обычными трёхлитровыми сберегательными банками памяти, а не то, что вы подумали ). Имеющих соображения на этот счёт, прошу высказываться в комментариях.

У меня на машине вышеописанного не наблюдается, тем не менее, иногда бывают аномально плохие результаты - скорее всего, планировщик задач вносит свои «коррективы».

Из этого примера можно вынести следующий урок: очень сложно полностью предсказать поведение железа. Да, можно предсказать многое, но необходимо постоянно подтверждать свои предсказания с помощью измерений и тестирования.

Заключение

Надеюсь, что всё рассмотренное помогло вам понять устройство кэшей процессоров. Теперь вы можете использовать полученные знания на практике для оптимизации своего кода.

Речь идет не о наличности, а о кэш -памяти процессоров и не только. Из объема кэш -памяти торгаши сделали очередной коммерческий фетиш, в особенности с кэшем центральных процессоров и жестких дисков (у видеокарт он тоже есть – но до него пока не добрались). Итак, есть процессор ХХХ с кэшем L2 объемом 1Мб, и точно такой же процессор XYZ с кэшем объемом 2Мб. Угадайте какой лучше? Аа – вот не надо так сразу!

Кэш -память – это буфер, куда складывается то, что можно и/или нужно отложить на потом. Процессор выполняет работу и возникают ситуации, когда промежуточные данные нужно где-то сохранить. Ну конечно в кэше! – ведь он на порядки быстрее, чем оперативная память, т.к. он в самом кристалле процессора и обычно работает на той же частоте. А потом, через какое то время, эти данные он выудит обратно и будет снова их обрабатывать. Грубо говоря как сортировщик картошки на конвейере, который каждый раз, когда попадается что-то другое кроме картошки (морковка ) , бросает ее в ящик. А когда тот полон – встает и выносит его в соседнюю комнату. В этот момент конвейер стоит и наблюдается простой. Объем ящика и есть кэш в данной аналогии. И сколько его надо – 1Мб или 12? Понятно, что если его объем мал придется слишком много времени уделят выносу и будет простой, но с какого то объема его дальнейшее увеличение ничего не даст. Ну будет ящик у сортировщика на 1000кг морковки – да у него за всю смену столько ее не будет и от этого он НЕ СТАНЕТ В ДВА РАЗА БЫСТРЕЕ! Есть еще одна тонкость – большой кэш может вызывать увеличение задержек обращения к нему во-первых, а заодно повышается и вероятность возникновения ошибок в нем, например при разгоне – во-вторых. (о том КАК в этом случае определить стабильность/нестабильность процессора и выяснить что ошибка возникает именно в его кэше, протестировать L1 и L2 – можно прочесть тут.) В-третьих – кэш выжирает приличную площадь кристалла и транзисторный бюджет схемы процессора. То же самое касается и кэш памяти жестких дисков. И если архитектура процессора сильная – у него будет востребовано во многих приложениях 1024Кб кэша и более. Если у вас быстрый HDD – 16Мб или даже 32Мб уместны. Но никакие 64Мб кэша не сделают его быстрее, если это обрезок под названием грин версия (Green WD) с частотой оборотов 5900 вместо положеных 7200, пусть даже у последнего будет и 8Мб. Потом процессоры Intel и AMD по-разному используют этот кэш (вообще говоря AMD более эффективно и их процессоры часто комфортно довольствуются меньшими значениями). Вдобавок у Intel кэш общий, а вот у AMD он персональный у каждого ядра. Самый быстрый кэш L1 у процессоров AMD составляет по 64Кб на данные и инструкции, что вдвое больше, чем у Intel. Кэш третьего уровня L3 обычно присутствует у топовых процессоров наподобие AMD Phenom II 1055T X6 Socket AM3 2.8GHz или у конкурента в лице Intel Core i7-980X. Прежде всего большие объемы кэша любят игры. И кэш НЕ любят многие профессиональные приложения (см. Компьютер для рендеринга, видеомонтажа и профприложений). Точнее наиболее требовательные к нему вообще равнодушны. Но чего точно не стоит делать, так это выбирать процессор по объему кэша. Старенький Pentium 4 в последних своих проявлениях имел и по 2Мб кэша при частотах работы далеко за 3ГГц – сравните его производительность с дешевеньким двуядерничком Celeron E1***, работающим на частотах около 2ГГц. Он не оставит от старичка камня на камне. Более актуальный пример – высокочастотный двухъядерник E8600 стоимостью чуть не 200$ (видимо из-за 6Мб кэша) и Athlon II X4-620 2,6ГГц, у которого всего 2Мб. Это не мешает Атлону разделать конкурента под орех.

Как видно на графиках – ни в сложных программах, ни в требовательных к процессору играх никакой кэш не заменит дополнительных ядер. Athlon с 2Мб кэша (красный) легко побеждает Cor2Duo с 6Мб кэша даже при меньшей частота и чуть не вдвое меньшей стоимости. Так же многие забывают, что кэш присутствует в видеокартах, потому что в них, вообще говоря, тоже есть процессоры. Свежий пример видеокарта GTX460, где умудряются не только порезать шину и объем памяти (о чем покупатель догадается) – но и КЭШ шейдеров соответственно с 512Кб до 384Кб (о чем покупатель уже НЕ догадается). А это тоже добавит свой негативный вклад в производительность. Интересно еще будет выяснить зависимость производительности от объема кэша. Исследуем как быстро она растет с увеличением объема кэша на примере одного и того же процессора. Как известно процессоры серии E6*** , E4*** и E2*** отличаются только объемом кэша (по 4, 2 и 1 Мб соответственно). Работая на одинаковой частоте 2400МГц они показывают следующие результаты.

Как видно – результаты не слишком отличаются. Скажу больше – если бы участвовал процессор с объемом 6Мб – результат увеличился бы еще на чуть-чуть, т.к. процессоры достигают насыщения. А вот для моделей с 512Кб падение было бы ощутимым. Другими словами 2Мб даже в играх вполне достаточно. Резюмируя можно сделать такой вывод – кэш это хорошо, когда УЖЕ много всего остального. Наивно и глупо менять скорость оборотов винчестера или количество ядер процессора на объем кэша при равной стоимости, ибо даже самый емкий ящик для сортировки не заменит еще одного сортировщика Но есть и хорошие примеры.. Например Pentium Dual-Core в ранней ревизии по 65-нм процессу имел 1Мб кэша на два ядра (серия E2160 и подобные), а поздняя 45-нм ревизия серии E5200 и дальше имеет уже 2Мб при прочих равных условиях (а главное – ЦЕНЕ). Конечно же стоит выбирать именно последний.