Процессорозависимость видеосистемы. Часть II – Влияние объема кэш-памяти CPU и скорости оперативной памяти

Предисловие ко второй части

С момента опубликования статьи «Процессорозависимость видеосистемы. Часть I – Анализ» мы получили много откликов от вас, уважаемые читатели. Наряду с вопросами, когда же выйдет вторая часть материала, также было много замечаний относительно приведенных графиков и сомнений относительно их достоверности в некоторых специфических случаях. Сегодня мы дадим объяснение нескольким нюансам, которые вызвали живой интерес у публики, но не были подробно описаны в первой части. Рассмотрим влияние объема кэш-памяти центрального процессора и скорости работы оперативной памяти на производительность в 3D-играх. А также вплотную подойдем к вопросу сравнения платформ в целом. Итак, начнем.

«Нестыковка» №1. Или - куда подевался «ноль»

Обратите внимание на график, приведенный ниже. Этот график взят нами из первой части статьи. Мы видим, что линии, отражающие производительность видеокарты в разных режимах, при уменьшении частоты центрального процессора сходятся к одной и той же наклонной линии. «Нестыковка» состоит в том, что если мы попытаемся продлить эту аппроксимирующую линию до пересечения с осью “FPS”, то увидим, что прямая приходит не в начало координат, а несколько выше. Получается, что при нулевой частоте центрального процессора мы можем играть, причем со скоростью целых 15 кадров в секунду?! Как такое может быть? Если отвлечься от условий тестирования, в которых мы получали результаты, то теоретически такая ситуация все-таки возможна. Допустим, мы загрузим в память видеокарты некоторые данные вместе с шейдерными программами, которые должен выполнять видеочип, и пусть себе все автономно крутится, центральный процессор тут не нужен. Примеры использования видеопроцессоров для математических расчетов известны. Но в наших условия тестирования такой результат получить физически невозможно. Кто-то же должен рассчитывать положение объектов в игровой сцене вместо CPU! Как же на самом деле должен вести себя график процессорозависимости, при стремлении частоты центрального процессора к нулю? Попытка провести эксперимент на реальном оборудовании осложняется тем, что более низкие значения множителя CPU уже недоступны, а если просто взять какой-то "совсем слабый процессор» – мы изменим платформу, то есть условия тестирования, как следствие, корректно сопоставить результаты тестирования уже не получится. Что же делать? Давайте попробуем предсказать «поведение» кривой процессорозависимости с помощью логики и реального «поведения» типичного персонального компьютера. Для этого нам придется несколько углубиться в принципы работы операционных систем с вытесняющей многозадачностью. Не пугайтесь этого длинного термина. Скорее всего, для работы и игр вы используете именно такую операционную систему. Ведь речь идет о хорошо всем известной операционной системе - Windows XP. Помимо Windows XP к операционным системам с вытесняющей многозадачностью относятся и Windows2000, и все клоны Linux. Особенность этих операционок, существенная для нашего рассмотрения, состоит в том, как они распоряжаются ресурсами «железа», а именно – распределение процессорного времени для одновременного выполнения нескольких задач. Нам, сидя за персональным компьютером, кажется, что все выполняется одновременно – и закачка файлов из Интернет, и воспроизведение музыки, и запись CD-диска, однако в реальности все выглядит несколько по-другому. Все приложения, которые вы запустили на своем компьютере, выполняются в строгой последовательности! Никакого противоречия здесь нет. Поскольку процессор один, то все приложения выполняются по очереди, по «кусочкам». Но эти кусочки настолько малы, а операционная система настолько быстро между ними переключается, что человек не в состоянии это заметить, и возникает иллюзия, что все выполняется одновременно. Если говорить кратко и упрощенно, то все время работы центрального процессора разбивается на некоторые промежутки, или «кванты» времени. А затем эти «кванты» времени «выдаются» приложениям, типа – нате поработайте, вот вам процессор на пару миллисекунд. При этом ядро многозадачной операционной системы и само потребляет некоторую часть этих «квантов» времени процессора, для того чтобы работали системные службы, да и просто – надо же операционке «подумать», какому приложению отдать следующий «квант». То есть, появляются некоторые «непроизводительные» (с точки зрения пользовательского приложения) потери времени процессора, которые идут на обслуживание собственно операционной системы. Все вышеизложенное имеет самое непосредственное отношение к нашей «нестыковке». И вот почему. Если операционная система для обеспечения своей работоспособности требует некоторого фиксированного количества «квантов» времени центрального процессора, то очевидно, что при уменьшении частоты CPU количество свободных «квантов», которые могут быть выделены для работы приложения (в нашем случае 3D-игры), будет уменьшаться быстрее, чем частота процессора. Можно это выразить и другими словами. Предположим, что при частоте процессора в 100 МГц его производительности хватит для обслуживания только операционной системы. Тогда для получения эквивалентной частоты CPU, то есть количества «мегагерц», которые доступны приложению, мы должны из реальной частоты процессора вычесть эти самые 100 МГц, отводимые для операционной системы. В этом случае получается, что при частоте CPU 1000 МГц величина «поправки на операционку» составляет 10%, при частоте CPU в 200 МГц – уже 50%, а при частоте CPU 100 МГц – мы получим 0 FPS. На следующем графике мы проиллюстрировали все сказанное выше. Красной прерывистой линией обозначено предполагаемое поведение кривой процессорозависимости при стремлении частоты CPU к нулю. Внимание - эта линия проведена произвольно и не является отображением каких-либо экспериментальных данных! Вам может показаться странным, зачем мы уделяем этому вопросу столько внимания и времени. Ведь процессоры со столь низкими частотами уже практически не используются в персональных компьютерах, да и практической пользы от эксперимента, даже если его удалось бы выполнить – на первый взгляд нет. Все так, но и не совсем так. Давайте зададимся вопросом – «а как можно исключить или минимизировать влияние операционной системы на скорость работы приложения?». То есть – возможно ли вообще получить график процессорозависимости, проходящий через начало координат? Забегая вперед, скажем – возможно, если операционная система будет выполняться… на другом процессоре. Но к этому вопросу мы вернемся чуть позже.

Нестыковка №2. Нелинейность «линии максимально возможных результатов»

Только что мы рассмотрели поведение «линии максимально возможных результатов» при уменьшении частоты CPU. Теперь давайте посмотрим, что происходит, если мы пойдем в другую сторону и будем увеличивать частоту CPU. Собственно, суть «нестыковки» хорошо заметна на все том же графике, который мы рассматривали выше. А именно – в какой бы точке «линии максимально возможных результатов» мы не строили касательную, при увеличении частоты CPU дальнейшие результаты отклоняются от касательной вниз. Почему график не следует линейному закону, а начинает «пригибаться» к оси Х? Приведем несколько причин, объясняющих данное явление. Первая причина – расход мощности центрального процессора на нужды операционной системы. Вопрос, который выше уже рассматривался. Вторая причина - влияние множителя CPU. Спрашивается, при чем тут коэффициент умножения CPU? А притом, что если увеличивать скорость процессора только за счет множителя, мы вроде бы увеличиваем мощность CPU по обработке данных, но ведь их еще надо ядру CPU доставить, а скорость процессорной шины остается неизменной. Для задач с большим количеством данных, которые надо обрабатывать и которые не помещаются в кэш-память процессора, может возникнуть момент, когда ядро CPU уже обсчитало имеющиеся данные, и ждет подкачки следующей порции. То есть, процессор начинает простаивать, что можно рассматривать как снижение «эффективной» частоты работы CPU. Третья возможная причина – характер распределения процессорного времени между графическим драйвером (который выполняется на CPU) и собственно расчетами игры (также выполняемыми на CPU). Ситуация выглядит несколько запутанно, поскольку обе задачи используют центральный процессор, да и графический драйвер можно отнести как к компоненту операционной системы (по архитектуре), так и к важному звену с точки зрения выполнения 3D-приложения. Другие возможные причины – латентность и пропускная способность оперативной памяти, шины процессора и т.д. Список приведенных причин не является окончательным и исчерпывающим, и при желании можно найти еще несколько факторов, из-за которых поведение «линии максимальных результатов» будет отличаться от прямолинейного. Определение степени влияния каждой из указанных причин и поиск «бутылочного горлышка» – довольно обширная тема для исследования. Прежде, чем перейти к рассмотрению частных вопросов, сформулируем общий постулат: В многофакторной среде линейная зависимость какой-либо величины от определенного параметра может быть достигнута только при условии отсутствия ограничений со стороны всех остальных параметров. Или же, другими словами, именно тот параметр, в зависимости от которого строится график, и должен быть наиболее ограничивающим фактором. Применительно к нашему рассмотрению процессорозависимости видеосистемы это означает, что кроме CPU, производительность всех остальных компонентов должна быть достаточной и не создавать каких-либо ограничений. То есть – видеокарта должна быть мощная и работать в наилегчайшем из режимов (например, 640x480 вместо 1600х1200 при прочих одинаковых настройках), оперативная память должна работать с максимальной скоростью, влияние операционной системы сведено к минимуму и т.д. Как бы там ни было, на практике, при увеличении частоты центрального процессора, мы все равно наблюдаем рост «линии максимально возможных результатов». И хотя этот рост не является строго линейным, для оценки «потолка» возможной производительности платформы в 3D-приложениях он вполне применим. Далее мы рассмотрим несколько факторов, которые влияют на производительность компьютера в 3D-приложениях. Но речь пойдет уже о вещах, которыми мы можем в той или иной степени управлять, выбирая центральный процессор и тип оперативной памяти, то есть – выбирая «платформу» для запуска 3D-приложений.