CC BY
17
УДК 004.051
Е.П. Антышев, Ю.В. Тименков
моделирование распределения вычислительных ресурсов с учетом влияния буферизации кода
Существует класс моделей для описания распределения ресурсов операционной системы на основе представления выполняющейся задачи в терминах «траектории исполнения»: текущему состоянию задачи ставится в соответствие точка в координатах (X, T), где X - стадия исполнения программы, а T - физическое время. Данная модель предложена А.Г. Тормасовым в 2006 г. [5] и расширена в последующих работах по данной тематике [6] и др.
Ключевым входным параметром модели [2] является профиль использования ресурсов: количество необходимых задаче на некотором этапе исполнения ресурсов, таких, как время процессора, сетевого адаптера, жесткого диска и др. Мерой потребности в процессоре здесь может выступать количество тактов на инструкцию (cycles per instruction, CPI).
В работе [2] подразумевалось, что информация об использовании ресурсов выделенным процессом будет верна и для множества одновременных процессов исполнения той же программы. Однако существует множество факторов, когда различие будет существенным. Как правило, эти факторы связаны с переполнением кеша процессора: для единственного выделенного процесса доля промахов при доступе к коду или данным минимальна, при появлении других процессов происходит взаимное вытеснение из кеша процессора, что приводит к увеличению CPI каждой задачи.
Еще одним фактором, ограничивающим использование профиля исполнения для расчета набора задач, является невозможность переноса результата на другую вычислительную машину, процессор которой имеет иное устройство конвейера, приводящее к другому CPI. То есть существует проблема применимости данных моделирования для другой машины, отличной по характеристикам от той, для которой были получены переносы данных моделирования: оборудование отличается по множеству параметров, относящимся к производительности. В частности, машина с другим чипсетом может иметь боль-
шую латентность RAM памяти, что приведет к увеличению времени работы программы при том же количестве выделенного времени процессора. Иными словами, CPI программы зависит сильным образом от оборудования.
Возникает задача использования профиля ресурсов, полученного на одной машине, для моделирования тех же задач на другой машине. Для ее решения необходимо убрать из профиля специфическую для данной машины задержку, связанную с рассматриваемой компонентой процессора (в настоящей работе это front-end).
В данной статье предпринята попытка математически описать влияние характеристик frontend процессора, а также кеша инструкций на CPI программы с целью уточнения модели распределения ресурса процессора, предложенной в [2].
Цель работы. Исследование факторов, определяющих производительность выполнения кода на типичном x86 процессоре, их количественное описание с целью уточнения модели [2]. Из широкого множества таких факторов для исследования выбраны эффекты, относящиеся к производительности front-end и кеша инструкций первого уровня.
Внутренние ресурсы процессора. В статье рассматривается процессор Intel Core как современный суперскалярный вариант имплементации архитектуры 80x86, ввиду его широкого распространения, типичности для серверного и кластерного оборудования.
Практически во всех современных микропроцессорах используется конвейер для одновременной обработки последовательных стадий выполнения потока инструкций. Наличие конвейера позволяет говорить о ресурсах микропроцессора: пропускной способности различных участков конвейера.
В статье выделено три таких ресурса: устройство подкачки и обработки инструкций, или frontend (instruction fetch unit, decoder, BPU), устройство исполнения микроопераций (out-of-order engine, OOO) и устройство завершения инструкций (retirement unit, ROB).
Figure 2-2. Intel Core Microarchitecture Pipeline Functionality
Рис. 1. Схема конвейера Intel Core из [3]
Необходимо отметить в сложной структуре процессора «узкие места»: устройства, производительность которых для некоторого класса программ определяет общую производительность. В качестве широкого и относительно малоизученного такого класса задач мы выбрали large code - small data разновидность задач.
Производительность таких программ при некоторых условиях ограничена front-end микропроцессора: набором устройств обработки инструкций, передающим их в виде потока микроопераций на вход суперскалярного вычислительного утрой-ства (out-of-order execution unit) [7].
Измерение производительности front-end и OOO engine. Современные процессоры обычно имеют большой набор неархитектурных счетчиков производительности, доступных для ядра операционной системы (ring 0). Как правило, удобный интерфейс для их исследования предоставляют профилировщики, созданные производителем микропроцессора. Это, например, vtune от Intel и CodeAnalyst для AMD. В данной статье рассматривается процессор Intel Core 2 Duo и используются соответствующие наименования счетчиков.
Промах кеша инструкций без перехода. Самый непосредственный способ вызвать промах кеша инструкций - организовать цикл, тело которого имеет размер больше размера кеша. Например, в рассматриваемом случае цикл имел вид, представленный в листинге 1.
mov ebx, $exit - <codesize> jmp ebx
$start:
dec eax dec eax dec eax
jl $exit jmp ebx
$exit:
Листинг 1: Цикл с регулируемым размером кода
В конце цикла проверяется значение EAX. Если оно отрицательное, то происходит выход из цикла. То есть количество выполненных инструкций будет равным начальному значению EAX с точностью до размеров тела цикла (на x86 код «dec eax» 1 байт). При значении EAX = 2e9 и размере цикла 100 Кбайт погрешность 0,02 %.
Эксперимент показал, что количество промахов подчиняется очевидной формуле:
L1I MISSES =
(1)
= Pmiss х INST _RETIRED.ANY
Иными словами, количество промаха есть вероятность вытеснения инструкции из кеша L1, умноженная на число инструкций. При механизме вытеснения pseudo-LRU, применяемом в кеше L1I Intel Core [3], каждая сто двадцать восьмая (64 байта - размер линии кеша, еще 64 байта -prefetch stride [3, § 7.7.3.3]) инструкция оказывается вытесненной, если размер кода цикла превышает S(L1) = 32 Кб - размер кеша инструкций L1. То есть в нашем эксперименте Pmiss = 1/128.
Однако возрастание L1I_MISSES не сказывается на производительности: о промахе кеша становится известно на этапе instruction fetch до выполнения инструкции.
Пропускная способность IFU на Intel Core 2 составляет 16 байтов на такт: в нашем случае, когда размер инструкции 1 байт, это дало бы 16 инструкций в такт. Производительность frontend в целом определяется скоростью декодирования коротких инструкций: четыре микрооперации в такт (подробнее см. [3, § 2.2.2.4]). «dec eax» составляет одну микрооперацию (поэтому RS_UOPS_DISPATCHED = INST_RETIRED. ANY), следовательно front-end обрабатывает не более четырех инструкций в такт.
Производительность out-of-order engine составляет одну микрооперацию в такт: последовательность «dec eax» является информационно-зависимой, что не позволяет использовать более одного ALU.
Следовательно, производительность конвейера в целом для нашей программы определяется скоростью выполнения микроопераций в одном ALU и равна одной инструкции в такт (что подтверждается опытом, исходя из счетчика RESOURCE_STALLS.RS_FULL - числа тактов, в которые reservation station не смогла принять новых микроопераций от front-end ввиду их медленного выполнения). Наличие промахов L1, предсказанных на ранней стадии конвейера, на производительность не влияет, что и является основным результатом этого эксперимента:
CLK = CLK0 + (2)
+ K *L1_ MISSES* L1_miss_cost
Здесь выражено ухудшение производительности в зависимости от числа промахов кеша инструкций L1I_MISSES; K - коэффициент «непредсказуемости» перехода (K = 0 в данном случае); L1_miss_cost - стоимость промаха кеша инструкций с попаданием в кеш L2.
Следовательно, промахи кеша инструкций не являются достаточным условием для ухудшения производительности, если о них становится известно на ранних стадиях конвейера, как в рассмотренном случае.
Прямые переходы. Для исследования влияния прямых переходов (direct jumps) на производительность сгенерирована тестовая программа, содержащая большое количество относительных переходов на одинаковый сдвиг. В листинге 2 приведен участок программы:
unitN: dec eax jz $exit
mov ecx, unitN + 64 cmp ecx, ebx jae $start jmp unitN + 64 ALIGN 16 unitN+1:
Листинг 2: Прямые переходы в ограниченном адресном пространстве (от unit0 до ebx, с шагом 64 байта)
Сгенерирован код, состоящий из подобных идентичных блоков. Регистр EAX играет роль счетчика переходов, регистр EBX содержит адрес-ограничитель: если следующий переход произойдет на адреса ниже (больше) ограничителя, произойдет возврат в начало кода (метка $start). Таким образом, каждый переход на длину не менее 64 байтов на вытесненный из кеша адрес, вызывает обращение к кешу L2. В нашем случае каждый следующий переход вызывает промах кеша при размере цикла более 32 Кбайтов.
Исследованы следующие значения сдвига: 4096 байт, 512 байт, 256 байт, 128 байт, 64 байта, 32 байта. На рис. 2 приведены графики зависимостей времени выполнения программы (CLK_CPU_UNHALTED.CORE) от размера кода, в котором локализованы переходы, при одинаковом общем числе выполненных инструкций.
Во всех случаях наблюдается скачок при размере кода в 32 Кбайта: в этой точке происходит резкое ухудшение благодаря тому, что код перестает помещаться в кеш L1. В отличие от эксперимента со случайными переходами, где наблюдается плавное возрастание количества промахов L1 (и задержек front-end) от размера кода, здесь изменение скачкообразное.
Ключ к пониманию этой особенности - ограниченная ассоциативность кеша L1. Напомним, что кеш L1 инструкций на Intel Core имеет восемь направлений по 4 Кбайта, механизм вытеснения (псевдо) LRU. Пусть сдвиг переходов равен 4096 байт. В 8-way кеше существует восемь линий, способных содержать адреса с одинаковым смещением в 4 Кбайта странице. Если общее количество адресов переходов в программе не больше восьми, весь код через несколько промахов оказывается в кеше. Однако если количество пере-
Рис. 2. CLK_CPU_UNHALTED.CORE от размера кода в цикле (прямые переходы)
ходов больше восьми, каждый очередной переход вызывает промах L1, в результате которого сам оказывается в кеше, но следующий переход в свою очередь вызывает промах и т. д. Таким образом, когда размер кода, в котором производятся переходы, превышает 8 * 4096 байт = 32 Кбайта (размер кеша L1), происходит резкое понижение производительности front-end.
Количественно изменение производительности выражается через время задержки на доступ к кешу L2: 23-24 такта задержки на один промах L1. Это значительно больше, чем документированная задержка в 10 тактов на промах L2, которую можно найти в [3]. Предположительно, 24 такта являются суммой 10 тактов задержки на доступ к L2 и 14 тактов на прохождение конвейера [1]:
L1_miss_cost = L2_lat + Pipe_length . (3)
Итак, влияние прямых переходов на общую производительность без учета указанных особенностей пропорционально количеству переходов, вызывающих промах кеша (спекулятивно определяется по пути выполнения из листинга программы) и суммарной латентностью кеша L2 и временем прохождения конвейера, в данном эксперименте равной 24 тактам: CLK = CLK0 + Pmiss * BR _ INST _EXEC *
*(L2_lat + Pipe_ length).
Косвенные переходы. Косвенные переходы представляют особую сложность для устройства BPU ввиду того, что адрес перехода неизвестен до завершения исполнения инструкции перехода. В современных процессорах используются достаточно сложные и недокументированные механизмы предсказания адресов переходов [4].
Некоторые разновидности косвенных переходов могут быть хорошо предсказаны. Адреса возврата ret инструкций практически всегда могут быть получены из стека адресов возврата, который поддерживается в BPU Intel Core 2 [1, § 2.2.2.1].
Тестовая программа, позволяющая узнать задержку на сброс конвейера и обращение к кешу L2, возникшую вследствие неугаданного косвенного перехода, приведена в листинге 3:
mov eax, ecx /*eax = ecx(random seed)*/
xor edx, edx
mov edi, 1664525
mul edi
xor edx, edx
add eax, 1013904223 /* eax <-- next random */ mov ecx, eax /* ecx - store random seed */ div ebx
mov eax, edx /* eax %= ebx(CODESIZE) */ and eax, 0xffffffc0 /* eax = (eax / UNITSIZE)*UNITSIZE */
dec esi /* decrease ops counter */ jz $exit
mov edx, $start /* edx = $start */ add edx, eax /*edx += random offset */ jmp edx /* jump to random unit */ ud2 /* tell processor not to decode fall-through path*/
ALIGN 16 int 3
ALIGN 16
Листинг 3: Переходы на вычисляемый псевдослучайный адрес
Указанный фрагмент кода составляет 64 байта на x86 архитектуре. С помощью препроцессора сгенерирована программа размером 64 Кбайта,
состоящая из подобных повторяющихся фрагментов.
Каждый фрагмент вычисляет псевдослучайный адрес возврата, сохраняя сдвиг генератора в регистре EAX. Использован линейный конгру-ентный метод Xn+1 = (a * Xn + c) mod m с параметрами a = 1664525, c = 1013904223, m = 232 (из Numerical Recipes [8]). Адрес очередного перехода лежит в диапазоне от начала кода $start до EBX - параметр, определяющий границу переходов. В регистре ESI содержится счетчик сделанных переходов, начальное значение 2E09.
При случайной генерации адресов переходов BPU оказывается неспособным их предсказать, что приводит к сильному влиянию локальности кода на производительность: появляются непредсказуемые переходы, сопровождающиеся промахами кеша инструкций. Исходя из случайности переходов, для вероятности промаха очередного перехода можем записать:
Pmiss = MAX(0, (codesize - L1I_size)/
/ codesize).
(5)
Форму ла (1) теперь ширена подстановкой = Pmiss * INST RETIRED :
может быть еас-L1I MISSES =
CLK = CLK0 + K * Pmiss * (6)
* INST_RETIRED * (L2_lat + Pipe_ length).
Для приведенной программы численные значения следующие: CLKO = 2.15E11 (CPU_CLK_ UNHALTED.CORE при размере кода менее 32 Кбайта), L2_lat = 10 тактов, Pipe_length = 14 тактов, INSTRETIRED = 2.0Е10.
На рис. 3 представлено сравнение расчетов с экспериментальными результатами.
Пересчет профилей ресурсов [2]. Для учета задержек front-end во время измерения потребности в CPU помимо SLK_SPU_UNHALTED. SORE (полное количество тактов) следует снимать также значения счетчиков: UOPS_DIS-PATSHED.SYSLES_ANY - число тактов работы вычислительного устройства, дополнительное к нему UOPS_DISPATSHED.SYSLES_NONE; L1I_MISSES - количество промахов кеша инструкций; INST_RETIRED.ANY - количество инструкций.
Из этих данных можно извлечь следующую информацию об участке программы: CLK EXES = UOPS DISPATCHED.CYCLES
0 16384 32768 49152
-♦— CPU_CLK_U N H ALTED.CO RE ■ calcCycles
Рис. 3. Сравнение экспериментального и расчетного
времени выполнения программы, индуцирующей непредсказуемые косвенные переходы в зависимости от локальности кода
_ANY - количество «чистых» тактов, необходимых для исполнения; зависимость Pmiss(L1I _ size, L1I_ ways) - вероятность генерации промаха очередной инструкцией; K = CLK _ STALLj / L1I _ MIS SESX / (L2 _ lat, + + Pipe_length,) - коэффициент «непредсказуе-мости»промахов.
Грубый пересчет производительности программы для другого процессора состоит в нахождении вероятности промаха в зависимости от новых значений размера и ассоциативности кеша инструкций Pmiss2 = Pmiss(L1I_size2,L1I_ways2); по известным K и Pmiss2 вычисляем новое время задержки CLK _ STALL2 = K * Pmiss2 * INST _ RETIRED * . * (L2_lat2 + Pipe_length2); и, наконец, прибавляем время задержки к CKL_EXEC, получая оценку для времени исполнения CLK = CLK _ EXEC + CLK _ STALL .
Выполнено исследование влияния параметров кеша инструкций и front-end на производительность. Основным результатом служит формула (6), описывающая влияние латентости кеша L2, длины конвейера, параметров кеша L1I, разновидности перехода на производительность.
В эксперименте 1 наблюдалось отсутствие задержек при существенном числе промахов. В наших терминах это означает K' = 0 - о промахе было известно на ранней стадии конвейера.
В эксперименте 3 к задержкам приводило наличие непредсказуемых косвенных переходов. То
есть K = 1 - о промахе известно на этапе retirement, в конце конвейера.
В эксперименте 2 рассматривался смешанный случай, демонстрирующий взаимосвязь компонент конвейера. Очень большое количество вполне предсказуемых прямых переходов привело к задержкам front-end, т. к. количество логических инструкций между переходами было недостаточным, чтобы «скрыть» фоновую загрузку инструкций, вызванную промахом. Про-
махи здесь являлись следствием ограниченной ассоциативности кеша инструкций, и связанные с ними задержки составили около 90 % времени исполнения.
Формула [6] используется в предложенной методике пересчета затрат на исполнение задачи на другом процессоре. Эксперименты показали, что ошибка от неучета данных эффектов может составлять до 90 % процессорного времени.
список литературы
1. Антышев, Е.П. Моделирование распределения ресурсов процессора с помощью уравнений переноса [Текст] / Е.П. Антышев // Тр. 52 науч. конф. МФТИ Современные проблемы фундаментальных и прикладных наук. Ч. V--. Управление и прикладная математика; Т. 3. -М.: Изд-во МФТИ, 2009. -С. 4-6.
2. Антышев, Е.П. Модель распределения ресурсов процессора и сетевого устройства в многозадачной операционной системе [Текст] / Е.П. Антышев // Математические методы и задачи управления: Сб. науч. тр. -М.: Изд-во МФТИ, 2011. -С. 186-197.
3. -ntel® 64 and -A-32 Architectures Optimization Reference Manual [Электронный ресурс] / Режим доступа: http://www.intel.com/content/dam/doc/manual/ 64-ia-32-architectures-optimization-manual.pdf
4. Agner, Fog. The microarchitecture of -ntel, AMD
and VIA CPUs. An optimization guide for assembly programmers and compiler makers [Электронный ресурс] / Fog Agner // Режим доступа: http://www.agner. org/optimize/microarchitecture.pdf (2011-06-08)
5. Тормасов, А.Г. Модель потребления ресурсов вычислительной системой [Текст] / А.Г. Тормасов // Вестник НГУ Сер. Информационные технологии. -2006. -Т. 4. -Вып. 1.
6. Тименков, Ю.В. Кинематическая модель исполнения процесса [Текст] / Ю.В. Тименков, Д.В. Тимен-кова // Математические модели и задачи управления. -2011. -С. 177-186.
7. Press, William H. Flannery Numerical Recipes: The Art of Scientific Computing Text/ William H. Press, Saul A. Teukolsky, William T. Vetterling [et al.]; 3rd ed. -NY: Cambridge University Press, 2007. -1256 p.
УДК 51-77
Т.П. Васильева, Б.И. Мызникова, С.В. Русаков
о возможности моделирования процесса градообразования с помощью клеточных автоматов
В данной статье представлены результаты, полученные с помощью модели клеточного автомата. Этот подход получил в последнее время достаточно широкое распространение в виду своей простоты, прозрачности и разнообразных приложений в динамическом пространственном моделировании.
Как известно [1], клеточный автомат - это дискретная динамическая система, представляющая собой совокупность одинаковых клеток, организация которой подчиняется набору правил, по которому любая клетка на каждом шаге по
времени вычисляет свое новое состояние по состояниям ее близких соседей.
Моделированию процесса развития современных территориальных образований методом клеточных автоматов посвящен ряд исследований [2-4]. В [2], в отличие от классического клеточного автомата, рассмотрена его модификация, использующая динамические весовые коэффициенты, позволяющие более точно интерпретировать временные процессы в эволюции города. В [3] для планирования развития городской территории использован метод клеточного автомата в
