Архитектура микропроцессора Intel и основные факторы, влияющие на его производительность

Качество предсказания переходов.

В программе есть некая управляющая логика, и эта логика включает в себя различные переходы внутри кода. Если встречаются if’ы и на основании вычисления какого-то условия принимается решение, какую выполнять инструкцию дальше? Как быть с загрузкой конвейера, в случае если встречается зависимость по управляющей логике? Можно остановить конвейер и ждать, пока вычислится условие перехода и после этого определить, какую инструкцию выполнять дальше и загружать ее на конвейер. Понятно, что в этом случае произойдет замедление работы конвейера, поэтому выбран другой метод. Процессор пытается предсказать по какому-то пути будет передаваться управление и продолжает выполнять инструкции с этого направления. Причем пока процессор не убедится, что выполняются правильные инструкции, они недействительны . Как только процессор убеждается, что путь угадан верно, все инструкции признаются правильными. Если предсказатель ошибся и реальное управление пошло по другому пути, недействительные инструкции удаляются из буферов, где они ожидали своей судьбы. Это приводит к некой задержке, приходится тратить время на то, чтобы инструкции удалять и загружать правильные инструкции на конвейер. Ошибка предсказателя (branch misprediction) вызывает замедление работы конвейера.

В процессоре есть статический и динамический предсказатель.

Статический предсказатель действует по простым правилам и принимает решения для тех переходов для которых нет собранной статистики.

Если встречается условный переход вперед, то статический предсказатель считает, что перехода не будет (в случае с оператором if управление пойдет по ветке if а не else).

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

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

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

Одна из целей vtun’а — это определение таких событий, как неверное угадывание перехода, например. Вы можете этим устройством проанализировать ваше приложение и увидеть, что в определенном месте вашего кода есть плохо предсказуемый переход или цепочка переходов влияющих на производительность. Зачастую такие проблемы могут быть решены творческим модифицированием кода.

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

Суперскалярность.

Теперь обсудим суперскалярность. Мы рассуждали о командном управляющем устройстве и об арифметико-логических устройствах. Суперскалярность — это процессор, который имеет несколько исполняющих устройств, то есть одновременно он может выполнять несколько арифметических и логических операций. Мы обсуждали конвейер, где обрабатывались инструкции, и была часть конвейера, которая выполняла операцию и называлась "исполняющее устройство", где непосредственно делалась основная работа, для которой эта инструкция была написана. Суперскалярность означает, что построен конвейер имеющий несколько исполняющих устройств и одновременно может исполняться несколько различных команд. Исполняющие устройства специфицированы, они не могут исполнить любую инструкцию, у них у каждого своя должность (один выполняет одни виды команд, другой – другие и так далее). То есть у нас появилась возможность выполнять одновременно несколько инструкций на этих исполняющих устройствах. Например до 6 инструкций на микропроцессорах семейства IA32 последних моделей.

Первым суперскалярным процессором интеловской архитектуры был Pentium, и в нем было реализовано исполняемое устройство U и исполняемое устройство V. Одно умело делать все операции, а второе — самые простенькие, например, инкрементирование.

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

Упрощенная модель процессора

Теперь мы берем и изменяем несколько упрощенную модель нашего микропроцессора, чтобы схематично отобразить на ней те свойства, которые мы только что обсуждали. На системной шине работает упреждающая выборка, которая из памяти подгружает данные в систему КЭШа, базируясь на логике железного предсказателя. Отображаем систему КЭШей. В микропроцессоре будет работать конвейер и предсказатель переходов, то есть управляющее устройство будет брать не только те инструкции, которые оно в данный момент собирается выполнять, а также те, которые ему рекомендует брать предсказатель переходов (чтобы конвейер более плотно нагружать). Регистров увеличенное количество, ну и суперскалярность, которую мы можем отобразить как наличие нескольких вычислительно-логических устройств.

Конвейеризация, суперскалярность — это некие варианты параллелизации. Они несколько разные по их специфике, но в целом приводят к тому, что мы одновременно работаем с несколькими инструкциями.

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

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

Процессор поддерживает разные наборы векторных инструкций: SSE2, SSE3 и так далее. Обсуждая полноту набора инструкций мы уже затронули вопрос, что приложение будет работать оптимальнее на архитектуре, если при создании приложения вы будете специально создавать его для работы на данной архитектуре. Это верно и в случае с векторными инструкциями.

Out-of-order execution – одно из определяющих свойств архитектуры x86. Реализация этого механизма усложняет процессор. В качестве противоположного примера от Интел можно упомянуть архитектуры Itanium и Atom. На этих архитектурах инструкции выполняются в порядке, заданном приложением.

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

Т.е. в микроархитектурах семейства IA32 реализовано исполнение с изменением последовательности операций (out-of-order-execution). То есть программисты написали какие-то инструкции, подали их на процессор, а он сам выбрал, в каком порядке их выполнять. В данном случае важная часть работы – планирование инструкций выполняется непосредственно микропроцессором.

Это не единственный возможный вариант работы микропроцессора. Есть микропроцессор Intel Atom, предназначенный для различных планшетных устройств, который последовательно выполняет получаемые микроинструкции, или например, процессор Itanium, в котором в процессор поступают инструкции уже объединенные в группы. То есть работа по определению того, какие инструкции независимы и в каком порядке их подавать процессору переложена на компилятор. В этом случае работа по определению оптимального порядка инструкций выполняется один раз — во время компиляции. Это должно быть выгодно с точки зрения энергопотребления.

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

Приведу две схемы из Intel® 64 and IA-32 Architectures Software Developer’s Manual. Они дают примерное представление о архитектуре процессора.

Из этой схемы видно, что FE микропроцессора (пред)выбирает инструкции из памяти и декодирует их в микроинструкции. Эти микроинструкции заполняют Trace Cache. Из Trace Cache микроинструкции передаются для выполнения в Execution Out-Of-Order Core. После выполнения микроинструкции дожидаются решения о своей валидности в Retirement секции.

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

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

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

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

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

Теперь, плавно переходя от факторов влияющих на производительность процессора к факторам влияющим на производительность приложения, сформулируем какие характеристики приложения влияют на его производительность.

Основные характеристики приложения, влияющие на его производительность:

Эффективность выполнения. Я подразумеваю, что мы не делаем какую-то ненужную работу: все, что можно было посчитать по время компиляции, мы посчитали. Мы не делаем повторных вычислений там, где была возможность вычислить один результат и сохранить его во временной переменной и т.п. Эффективность вычислений — это качество кода, которое определяетя компилятором. Когда мы говорили про работу микропроцессора, то этот фактор не упоминался, но его необходимо упомянуть, когда мы начинаем говорить уже о приложениях.

Правильное предсказание переходов. Мы можем повлиять на этот фактор, удалив лишние переходы, правильно if’ы и else’ы расставить, чтобы у нас статический предсказатель реже ошибался.

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

Измерение производительности – довольно сложная тема. Как вы должны были догадаться из предыдущих рассуждений производительность зависит от двух факторов: от непосредственной качественной работы микропроцессора (МП) и от качества работы оптимизирующего компилятора. То есть качество работы оптимизирующего компилятора влияет непосредственно на результаты измерения производительности. Есть специальная организация – Standard Performance Evaluated Corporation — некоммерческая организация, которая делает аудиторскую независимую оценку производительности разных вычислительных систем. Она занимается сбором типичных задач, предоставляет своим пользователям некую универсальную систему тестирования и гарантирует независимое мнение о производительности микропроцессоров.

Соответственно, если вас интересует вопрос о производительности, вы можете зайти на сайт этой организации, заплатить небольшие деньги и скачать оттуда пакет для измерения производительности, получить доступ к двум различным вычислительным системам, взять этот пакет, инсталлировать его. Пакет позволяет построить и прогнать специальные программы, получить цифры и сказать: "с использованием представительной выборки задач из сюиты такой-то мы получили результат, что вот эта система в таких-то задачах эту систему превосходит, а на таких задачах немного проигрывает". В мире существуют аналитики, которые на этом зарабатывают деньги. Перед публикацией в научных компьютерных журналах своих отчетов, они используют этот пакет. Есть различные пакеты CPU2006, OMP2001 и так далее для тестирования различных аспектов производительности. Поскольку производительность зависит от микропроцессора и от компилятора, то компилятор — это важная часть в борьбе за признание высокой производительностей изделий. Если появляется новый микропроцессор, которые реализует какие-то новые команды, трудно показать улучшение его производительности из-за этих команд если не будет компилятора способного использовать эти команды в исполняемой программе. Другой фактор влияния компилятора на производительность связан с тем, что если в процессе эксплуатации процессора обнаружены какие-то инструкции, которые на процессоре почему-либо выполняются медленно, то с помощью компилятора мы можем каким-то образом заменить плохие инструкции на хорошие. Компилятор также активно используется при тестировании и разработке новых архитектур.

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

Можно провести некую аналогию на использование компилятора. Например, выполнение какой-то расчетной задачи мы можем сравнить с прохождением человеком некоего маршрута по пересеченной местности из точки А в точку В. Примерную схему маршрута и контрольные точки определил разработчик, написавший алгоритм и запрашивающий результаты рассчетов. Процессор в данном случае будет отвечать за физические кондиции того человека, который пойдет через лес. То есть он может быть очень сильный и может идти по ровной местности со скоростью 6 км/ч. Другой процессор может идти со скоростью 5 км/ч. А дальше вопрос стоит в выборе маршрута. Умный компилятор найдет места, где мы можем срезать путь и пойти более короткой дорогой. Формально, может случиться так, что процессор, который обеспечивает меньшую скорость, за счет компилятора данную задачу по перемещению из точки А в точку В выполнит быстрее.