�ݺ�ߣ

Исследование работы Кэш-памяти
центрального процессора
Чёрная команда
Санкт-Петербургский политехнический университет Петра Великого
Антон Абрамов <abramov91@mail.ru>
Владислав Бусаров <happyfanik@yandex.ru>
Сергей Дедков <dsv.mail@yandex.ru>
Семён Мартынов <semen.martynov@gmail.com>
Николай Патраков <noon.vlg@gmail.com>
23 ноября 2015 г.
Чёрная команда (СПбПУ) Кэш-память 23 ноября 2015 г. 1 / 32

Содержание
1 Назначение кэш памяти
2 Принцип работы кэша процессора
3 Организация кэша
4 Понятие ассоциативности кэша
5 Эксперимент
6 Заключение
7 Источники
8 Вопросы

Понятие кэш-памяти
Кэш (от фр. cacher – "прятать")
промежуточный буфер с быстрым доступом, содержащий информацию,
которая может быть запрошена с наибольшей вероятностью. Доступ к
данным в кэше осуществляется быстрее, чем выборка исходных данных
из более медленной памяти или удаленного источника, однако её объём
существенно ограничен по сравнению с хранилищем исходных данных.
Понятие предложено в 1967 году Лайлом Джонсоном (редактором
журнала "IBM Systems Journal") как замена термину "высокоскоростной
буфер"при описании памяти в разрабатываемой модели 85 из серии
IBM System/360.

Нужна ли кэш-память в современных системах?
Оперативная память представляет собой динамическую память с
произвольным доступом (Dynamic Random Access Memory, DRAM), а
кэш процессора выполняется на базе статической оперативной памяти
(Static Random Access Memory, SRAM).
Рассмотрим память DDR3-1600 9-9-9-27 (tCL-tRCD-tRP-tRAS):
эффективная частота составляет 1600 МГц, это скорость с которой
данные поступают на внешнюю шину в пакетном режиме доступа, а
реальная частота ядра памяти составляет всего 200 МГц.
С момента активации нужной строки памяти и до появления данных на
шине пройдет промежуток времени, равный tCL+tRCD, то есть 18
тактов. С учетом того что частота работы ядра памяти DDR3-1600
составляет 200 МГц, это время равно 90 нс. Если частота работы
процессора составляет 3 ГГц, то это означает, что процессор должен
будет дожидаться нужных данных (простаивать) минимум 270 тактов!

Почему DRAM-память не заменить SRAM-памятью?
Каждая ячейка DRAM-памяти состоит из одного полевого транзистора
и одного конденсатора, ячейка SRAM-памяти – как минимум из шести
полевых транзисторов (есть варианты с числом транзисторов 8 и 12).
Об этом рассказывал проф. Мелехин.
В результате:
Модули SRAM-памяти были бы меньшего объема в сравнении с
модулями DRAM-памяти
Их цена (даже при равном объёме) была бы выше
Существенно возросла бы проблема кэширования периферийных
устройств
Пришлось бы перерабатывать систему кэширования, которая на
данный момент работает достаточно хорошо =)

Принцип работы кэша процессора
Рис. 1: Структура кэш-памяти процессора
Кэш-контроллер перехватывает запросы к оперативной памяти и
определяет, имеется ли копия затребованных данных в кэше. Если есть
(cache hit), то данные извлекаются из кэша, если нет (cache miss) –
тогда запрос переадресуется к оперативной памяти.

Стратегии кэширования
Кэш-контроллер должен уметь предсказывать какие данные
потребуются процессору в будущем и загружать их в кэш
(упреждающая загрузка данных)
On demand – обращение к оперативной памяти происходит только в
случае кэш-промаха
Look Ahead – алгоритмы упреждающей спекулятивной загрузки
данных в кэш основанные на предположении, что данные из
оперативной памяти обрабатываются последовательно, в порядке
возрастания адресов
Look Through – загрузка данных из памяти может либо начинаться
после фиксации кэш-промаха
Look Aside – загрузка осуществляться параллельно с проверкой
наличия соответствующей копии данных и до кэш-попадания (очень
эффективна, но увеличивается энергопотребление процессора)

Политики замещения данных в кэш-памяти
Кэш всегда полон; новые данные можно занести только путем
замещения каких-либо старых.
Rnd (Random) замещаемые данные выбираются случайным образом
LFU (Least Frequently Used) – в первую очередь замещаются данные, у
которых самая низкая частота обращений (требует наличия
счетчика удачных запросов в каждой строке кэша)
LRU (Least Recently Used) – замещаются те данные, к которым дольше
всего не обращались
LRR (Least Recently Replaced) – замещаются те данные, которые были
загружены раньше всех

Организация кэша
Из чего формируется кэш-строка (cache-line):
Счетчик возраста строк, для реализации политики замещения на
основе алгоритма LRU
32-разрядный (четырехбайтный) адрес памяти, используемый
контроллером для проверки промахов/попаданий. Адрес
сохраняемого слова принято называть тегом (tag)
Блок данных фиксированного размера (степени двойки – 2, 4, 8, 16
и т.д.), идущих подряд в оперативной памяти. Он называется
размером кэш строки.

Рис. 2: Пример кэш-строки размером 16 байт
Размер кэш строки всегда равен степени двойки, а данные не
пересекаются. Тогда размер тега (в битах) равен 32 − log2S, где S –
размер кэш строки в байтах.
Если размер кэш строки равен 16 байт – то размер тега адреса 28 бита.
Для строки из 32 байт – 27 бит адреса, 64 бай адресуются 26 битами.

Объём кэша можно рассматривать как полный, и как полезный.
Пусть имеется кэш размером 32 Кбайт и длина строки составляет 128
байт. Такой кэш будет содержать 256 строк (32 Кбайт/128 байт).
Каждая строка имеет тег размером 25 бит (32 – log2 128). Кроме того,
добавим счетчик старения, содержащий 8 бит (log2 256). То есть к
каждой строке добавляется еще 33 служебных бита. А всего таких
служебных бит будет 8’448 или 1’056 байт. Соответственно полный
объем кэша составит чуть более 33 Кбайт.
В рассмотренном нами кэше мы не учитывали так называемые биты
модификации, которые также добавляются в каждой строке кэша и
необходимы для поддержания когерентности.

Полностью ассоциативная кэш-память (Fully associative)
Рис. 3: Структура полностью ассоциативной кэш-памяти
Чтобы определить, имеются ли запрошенные процессором данные в
кэш-памяти, нужно перебрать все кэш строки.

Кэш-память с прямым отображением (Direct mapping)
Рис. 4: Структура кэш-памяти с прямым отображением
Каждой строке кэш-памяти соответствует несколько (строго
определенных) строк оперативной памяти.

Соотношение между номерами строк оперативной памяти и номерами
кэш-строк:
Ncache = (Nmemory )mod(Nmax_cache)
Где:
Ncache номер кэш строки
Nmemory номер строки оперативной памяти
Nmax_cache количество строк кэш-памяти
mod функция получения остатка от деления

Перейдём от строк оперативной памяти к адресному пространству.
Nmemory = (ADDR)div(CACHE_LINE_SIZE)
Где:
ADDR адрес элемента в оперативной памяти
CACHE_LINE_SIZE размер кэш-строки
div функция целочисленного деления
Количество строк кэш-памяти можно выразить следующим образом:
Nmax_cache = (CACHE_SIZE)div(CACHE_LINE_SIZE)

Тогда выражение, определяющее номер строки кэш-памяти, в которую
попадет элемент оперативной памяти с адресом ADDR, запишется в
виде:
Ncache =[(ADDR)div(CACHE_LINE_SIZE)]
mod[(CACHE_SIZE)div(CACHE_LINE_SIZE)]

Наборно-ассоциативный кэш (N-way cache)
Рис. 5: Структура наборно-ассоциативного кэша
Кэш состоит из нескольких независимых банков (сегментов), каждый из
которых представляет собой кэш с прямым отображением, а сами банки
полностью ассоциативны по отношению к оперативной памяти.

Количество банков кэша называется его степенью ассоциативности или
канальностью (way). То есть может быть 2-канальный (2-way),
4-канальный (4-way), 8-канальный (8-way) и т.д.
Поскольку каждый банк кэш-памяти является сегментом памяти с
прямым отображением, в нем действует то же правило, что и для
кэш-памяти с прямым отображением, то есть:
Nbank_cache = (Nmemory )mod(Nmax_bank_cache)
Где:
Nbank_cache номер кэш строки в банке памяти
Nmax_bank_cache количество строк кэш-памяти в банке
Nmemory номер строки оперативной памяти

Количество строк кэш-памяти в банке определяется соотношением:
Nmax_bank_cache =
Nmax_cache
N
Где:
Nmax_cache количество строк в кэш-памяти
N степень ассоциативности (количество банков или каналов).

Постановка задачи
Исследовать характеристики обращение к памяти для программ из
бенчмарка Ливерморские циклы, ядра 1-9.
Используя результаты исследования, определить оптимальную для этой
вычислительной нагрузки конфигурацию кэш-памяти общим объемом
0,5 Мбайт;
Параметры:
m – число строк
n – число слов в строке
k – коэффициент ассоциативности

Ливерморские циклы
"Ливерморские циклы"появился в середине 60-х годов и состоит из
фрагментов программ, имеющих реальное хождение в Ливерморской
Национальной лаборатории им. Лоуренса в США.
Считается, что Ливерморские циклы – это типичный набор программ
для решения численных задач. В этих фрагментах используются
различные вычислительные алгоритмы: сеточные, последовательные,
волновые, что существенно с точки зрения соответствия
вычислительных и аппаратных структур.

Ливерморские циклы
1 Hydro fragment
2 ICCG excerpt (Incomplete Cholesky Conjugate Gradient)
3 Inner product
4 Banded linear equations
5 Tri-diagonal elimination, below diagonal
6 General linear recurrence equations
7 Equation of state fragment
8 ADI integration
9 Integrate predictors
Исходный код:
https://github.com/SemenMartynov/SPbPU_ComputingSystems/
blob/master/lab2/livermorec/livermorec.c

Порядок решения
Для решения задачи было принято решение использовать средство
динамического анализа Intel Pin:
1 На 32-битной системе мы запустили pintool (для оптимизированной
и не оптимизированной версии Ливерморских циклов),
генерирующий журнал обращений к памяти
2 На С++ реализовали модель работы кэш-памяти 32-битного
процессора. Использовалась стратегии кэширования On demand, и
алгоритм LRU для замещения (перед этим мы использовали LFU,
но он обнаружил свои очевидные недостатки).
3 По итогам моделирования получили таблицу с количеством кэш
промахов и попаданий при различных коэффициентах
ассоциативности, количестве и длине кэш строк.

Сборка с использованием gcc 4.6.3.
Компиляция с максимальной оптимизацией
$ gcc livermorec.c -o livermorec-mxopt -O3
$ /opt/pin/pin -t /opt/pin/source/tools/SimpleExamples/obj-ia32/pinatrace.so -- ./livermorec-mxopt
$ mv pinatrace.out livermorec-mxopt.out
Реальное время работы программы с оснасткой 0m13.114s
Компиляция без оптимизации
$ gcc livermorec.c -o livermorec-noopt -O0
$ /opt/pin/pin -t /opt/pin/source/tools/SimpleExamples/obj-ia32/pinatrace.so -- ./livermorec-noopt
$ mv pinatrace.out livermorec-no/opt.out
Реальное время работы программы с оснасткой 0m13.442s
результаты компиляции (журналы отличаются)
$ du -hsBk livermorec*
20K livermorec.c
8K livermorec-mxopt
1756K livermorec-mxopt.out
12K livermorec-noopt
1764K livermorec-noopt.out

Особенности модели кэша
При разработке модели кэша мы заложили следующие особенности:
1 Проверка на размер. Общий объём кэша вычисляется в
зависимости от переданных параметров и составляет 512 Кбайт (в
действительности ± 16 Кбайт)
2 Если запрошенный из памяти кусок данных требует обращения к
нескольким кэш-строкам, то кэш-попадание засчитывается только
в случае если все куски были кэшированы и обращение к памяти
не потребовалось
3 Модель ориентирована на вычисление промахов и попаданий, а не
на эффективное хранение адресов (тегов). Очевидно, что после
определения строки поиск нужного банка производится перебором,
за линейную сложность.

Результаты эмуляции
Далее будут приведены результаты эмуляции для оптимизированной и
не оптимизированной версии программы, с кэшем в 512 (± 16) Кбайт.
В таблице используются следующие обозначения:
C.Lines – количество кэш-линий
Words – количество 32-битных слов в каждой линии
Assoc. – коэффициент ассоциативности
Total size – общий объём кэша
Miss ctr – количество кэш-попаданий
Hit ctr – количество кэш-промахов
Rate – коэффициент кэш-попаданий
LongHit – максимальное количество кэш-попаданий подряд

Результаты эмуляции
Результат для оптимизированной версии
/=====================================================================================
| C.Lines | Words | Assoc. | Total size || Miss ctr | Hit ctr | Rate || LongHit |
|---------|---------|---------|------------||----------|----------|--------||---------|
| 14564 | 8 | 2 | 512 KB || 1568 | 44490 | 96.6% || 2670 |
| 14564 | 8 | 4 | 512 KB || 1569 | 44489 | 96.6% || 2670 |
| 26052 | 4 | 4 | 512 KB || 2643 | 43415 | 94.3% || 2454 |
| 42800 | 2 | 8 | 512 KB || 4403 | 41655 | 90.4% || 2439 |
| 62600 | 1 | 8 | 512 KB || 7795 | 38263 | 83.1% || 2406 |
| 42800 | 2 | 16 | 512 KB || 4414 | 41644 | 90.4% || 2439 |
=====================================================================================/
Результат для не оптимизированной версии
/=====================================================================================
|---------|---------|---------|------------||----------|----------|--------||---------|
| 14564 | 8 | 2 | 512 KB || 1573 | 44677 | 96.6% || 2670 |
| 14564 | 8 | 4 | 512 KB || 1573 | 44677 | 96.6% || 2670 |
| 26052 | 4 | 4 | 512 KB || 2649 | 43601 | 94.3% || 2454 |
| 42800 | 2 | 8 | 512 KB || 4419 | 41831 | 90.4% || 2439 |
| 62600 | 1 | 8 | 512 KB || 7802 | 38448 | 83.1% || 2406 |
| 42800 | 2 | 16 | 512 KB || 4422 | 41828 | 90.4% || 2439 |
=====================================================================================/
Время работы на Intel Core2 Quad CPU Q8300 @ 2.50GHz – 33m23.979s

Результаты эмуляции на маленьком кэше
Результат для оптимизированной версии
/=====================================================================================
|---------|---------|---------|------------||----------|----------|--------||---------|
| 256 | 64 | 16 | 64.9 KB || 443 | 45615 | 99.0% || 3572 |
| 128 | 64 | 8 | 32.5 KB || 505 | 45553 | 98.9% || 3572 |
| 128 | 64 | 16 | 32.5 KB || 510 | 45548 | 98.9% || 3572 |
| 64 | 64 | 8 | 16.2 KB || 675 | 45383 | 98.5% || 3572 |
| 64 | 64 | 4 | 16.2 KB || 696 | 45362 | 98.5% || 3572 |
| 64 | 64 | 16 | 16.2 KB || 704 | 45354 | 98.5% || 3572 |
=====================================================================================/
Результат для не оптимизированной версии
/=====================================================================================
|---------|---------|---------|------------||----------|----------|--------||---------|
| 256 | 64 | 16 | 64.9 KB || 430 | 45820 | 99.1% || 3572 |
| 128 | 64 | 8 | 32.5 KB || 502 | 45748 | 98.9% || 3572 |
| 128 | 64 | 16 | 32.5 KB || 512 | 45738 | 98.9% || 3572 |
| 64 | 64 | 8 | 16.2 KB || 680 | 45570 | 98.5% || 3572 |
| 64 | 64 | 16 | 16.2 KB || 695 | 45555 | 98.5% || 3572 |
| 256 | 32 | 16 | 32.9 KB || 716 | 45534 | 98.5% || 3572 |
=====================================================================================/
Результат оказался лучше при меньшем объёме кэша!

Результаты эмуляции утилиты ls
Сгенерируем журнал (на 32-битной системе) и проведём эмуляцию для
утилиты ls – полученный журнал около 12 Мбайт.
Результат для большого кэша
/=====================================================================================
|---------|---------|---------|------------||----------|----------|--------||---------|
| 14564 | 8 | 2 | 512 KB || 4190 | 167372 | 97.6% || 2670 |
| 14564 | 8 | 4 | 512 KB || 4190 | 167372 | 97.6% || 2670 |
| 26052 | 4 | 4 | 512 KB || 7765 | 163797 | 95.5% || 2454 |
| 42800 | 2 | 8 | 512 KB || 14463 | 157099 | 91.6% || 2439 |
| 62600 | 1 | 8 | 512 KB || 23570 | 147992 | 86.3% || 2406 |
| 42800 | 2 | 16 | 512 KB || 14464 | 157098 | 91.6% || 2439 |
=====================================================================================/
Результат для маленького кэша
/=====================================================================================
|---------|---------|---------|------------||----------|----------|--------||---------|
| 256 | 64 | 16 | 64.9 KB || 1199 | 170363 | 99.3% || 5710 |
| 128 | 64 | 8 | 32.5 KB || 1657 | 169905 | 99.0% || 5710 |
| 128 | 64 | 16 | 32.5 KB || 1667 | 169895 | 99.0% || 5710 |
| 256 | 32 | 16 | 32.9 KB || 2092 | 169470 | 98.8% || 3572 |
| 128 | 32 | 16 | 16.5 KB || 2806 | 168756 | 98.4% || 3572 |
| 64 | 64 | 16 | 16.2 KB || 3061 | 168501 | 98.2% || 5710 |
=====================================================================================/

Заключение
В ходе анализа результатов, нами были сделаны следующие выводы:
Объём кэша влияет на эффективность работы (коэффициент
кэш-попаданий) меньше, чем его организация. Оптимальное
значение находится в районе 32 Кбайт.
Наиболее эффективно работает кэш с большим количеством
машинных слов в каждой кэш-линии. В случае с Ливерморскими
циклами это объясняется последовательным доступам к элементам
массива, созданного на стеке. В утилите ls, возможно, дело в
оптимизации компилятора.
Неоптимизированная версия Ливерморских циклов показала очень
хороший результат. Вероятно, это обусловлено достаточно
оптимальным исходным кодом.
Исходные коды, журналы и полные версии таблиц доступны по адресу:
https://github.com/SemenMartynov/SPbPU_ComputingSystems

Источники
Крис Касперский
Техника оптимизации программ. Эффективное использование памяти
БХВ-Петербург - ISBN 5-94157-232-8; 2003 г.
Корныхин Е. В.
Генерация тестовых данных для тестирования механизмов кэширования и
трансляции адресов микропроцессоров
Программирование, 2010,N N 1.-С.40-49
Сергей Пахомов
Что такое кэш процессора, и как он работает
Компьютер Пресс. - 2013. - № 1. - С. 48-54
Ulrich Drepper
Memory part 2: CPU caches
http://lwn.net/Articles/252125/

Вопросы?

�ݺ�ߣ

Исследование работы Кэш-памяти центрального процессора

Recommended

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Исследование работы Кэш-памяти центрального процессора (20)

More from Semen Martynov (9)

Исследование работы Кэш-памяти центрального процессора