Часть 2: AMD Phenom II, подсистема памяти

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

Конфигурация тестовых стендов

Для проведения тестирования использовался тот же тестовый стенд, что и в предыдущем материале, да и «базовые» результаты тоже были взяты из предыдущей статьи: это результаты Phenom II X4 940 Black Edition, работающего в штатном режиме, со всеми включенными ядрами, и со стандартной для нашей тестовой системы памятью: 6 ГБ (2 x (2+1)) DDR2-800 с таймингами 4-4-4-12.

Тестирование

Использовалась стандартная тестовая методика образца 2009 года версии 4.0. Мы решили отследить три возможных сценария:

1. Кардинальное ухудшение производительности подсистемы памяти. Чтобы сымитировать такую ситуацию, мы просто понизили частоту работы наших штатных DDR2-800 модулей ровно в 2 раза. Таким образом, ПСП уменьшилась в 2 раза, а латентность (при сохранении тех же таймингов) в 2 раза возросла. Разумеется, настолько «жёсткое» сравнение имеет мало отношения к реальности, но в данном случае нам как раз хотелось увидеть эффект не приближенный к реальности, а наоборот, максимизированный. Тем более что предыдущая наша попытка прочувствовать эффект падения скорости при уменьшении ПСП, наводила нас на мысли, что для того, чтобы увидеть хотя бы стабильно наблюдаемый (пусть и не очень сильный) эффект, снижать ПСП следует кардинально.
2. Переключение режимов работы встроенного контроллера памяти Phenom II. Напомним, что всего их два: ganged и unganged*. Некоторые, быть может, вспомнят, что данный аспект производительности мы уже исследовали. Однако тогда у нас на руках был «первый» Phenom, частота у него была ниже, да и приложения, в конце концов, тоже обновляются. Мы решили, что повторить такое исследование будет нелишним. Данная ситуация уже вполне реальна, особенно для любителей покопаться в настройках BIOS системных плат.

   * — Следует заметить, что у контроллера памяти Phenom II существует ещё один режим: одноканальный — когда все модули памяти подключены к одному каналу контроллера, второй же попросту бездействует. Однако поскольку наш материал имеет всё же в большей степени практическую направленность, мы не стали проводить тесты в одноканальном режиме т.к. не очень понятно, по каким причинам кто-либо мог бы добровольно выбрать для своей системы такой заведомо «неудобный», искусственно ограниченный режим функционирования.

3. Переход на более «плохие» (высокие) тайминги. Данная ситуация вполне актуальна для тех, кто задумывается о приобретении модулей памяти: плата за минус одну единичку в таком параметре как CAS, может составлять весьма существенную сумму, и хотелось бы знать, стоит ли её платить. Ответ на вопрос, почему были выбраны именно такие тайминги (6-6-6-18 при исходных 4-4-4-12), звучит очень просто: это были худшие тайминги, которые нам позволил выставить BIOS системной платы.

Как и всегда, более подробно со всеми результатами проведенных тестов, можно ознакомиться, скачав таблицу в формате Microsoft Excel. Также диаграммы, как и в предыдущем материале, дополнены таблицами с подробными результатами тестов в различных приложениях и указанием относительной производительности в процентах, по отношению к референсной системе. Референсной, разумеется, была выбрана стандартная схема функционирования тестового стенда, её результаты даны во втором столбце таблицы. Более ярким фоном мы выделяли наиболее показательные результаты — для тех, кто не любит анализировать большое количество цифр, представленных в табличной форме.

3D-визуализация

* — здесь и далее в таблицах стрелочкой вверх (↑) помечены те тесты, где лучшим является больший результат, стрелочкой вниз (↓) — тесты, где лучшим является меньший результат.

Здесь и далее расхождение в 1-2% мы будем считать вписывающимся в погрешность измерений — по крайней мере, если нет оснований для обратного. Соответственно, проще всего ситуация с повышенной латентностью: на неё практически не отреагировало ни одно приложение, и даже -3% у Lightwave смотрятся не очень убедительно: «и это — всё, что нам может дать память с низкими таймингами?» С переключением режимов контроллера ситуация интереснее: резко отрицательно отреагировал на включение ganged-режима 3ds max. Напомним, что традиционно, unganged-режим считается более предпочтительным для многопоточных и одновременно работающих приложений, а ganged — для однопоточных приложений, использующих почти все ресурсы системы в одиночку. Впрочем, глядя на итоговую диаграмму, мы видим, что, в среднем, включение ganged-режима привело к тому же эффекту, что и высокие тайминги: производительность по отношению к референсной системе упала на 1 балл — то есть, даже меньше, чем на 1%.

Кардинальное понижение ПСП в 2 раза не оставило равнодушным ни одно приложение, однако свой рекордсмен есть и тут: это Maya, где производительность при визуализации упала на четверть (!). Как мы увидим позднее, это один из самых «громких» результатов во всём тестировании. Забавна ситуация с 3ds max: падение скорости от урезания ПСП не смогло сравниться с падением от включения ganged-режима. Среднее падение производительности составило около 15%. По крайней мере, эту цифру нельзя назвать малозначащей.

Трёхмерный рендеринг

Рендеринг (как мы уже неоднократно отмечали в более ранних материалах) мало к чему чувствителен, кроме вычислительной мощности процессорного ядра, и их количества. Даже не очень большой кэш (если он не совсем мизерный) позволяет достичь вполне приемлемой скорости. Было логично ожидать, что от подсистемы памяти рендер-движки будут зависеть в ещё меньшей степени. Так оно и вышло. Интересно, что 3ds max при рендеринге совершенно не реагирует на включение ganged-режима, хотя как раз рендеринг намного лучше задействует все 4 ядра, чем интерактивная работа. Впоследствии мы ещё не раз встретимся с ситуациями, когда «официальное позиционирование» ganged- и unganged-режимов, мягко говоря, входит в некоторое противоречие с наблюдаемой в реальности ситуацией.

Научные и инженерные расчёты

Если мы посмотрим на аналогичную диаграмму из первой серии, и попытаемся привести в соответствие умение задействовать многоядерность с реакцией на включение ganged-режима… то у нас опять ничего не получится. Так, SolidWorks, не умеющий толком задействовать многоядерность (и, соответственно, по идее, он должен отдавать предпочтение ganged-режиму) — при переключении на ganged-режим производительность снизил. А MATLAB, который лучше всего задействует многоядерность в данной группе — наоборот, даже повысил. Впрочем, мы уже договорились, что 1% «не считается»… хорошо — по крайней мере, не понизил точно. На «плохие» тайминги приложения отреагировали единодушно негативно, но очень слабо.

Понижение ПСП в 2 раза больше всего «задело» математические пакеты — MATLAB, MAPLE, Mathematica. В принципе, этому есть объяснение: MATLAB должен был отреагировать как самое многопоточно-оптимизированное ПО в группе, а MAPLE и Mathematica работают с символьными вычислениями, и поэтому должны быть критичны к скорости обработки больших массивов информации.

Растровая графика

Абсолютно шокирующий результат: ПО для работы с растровой графикой оказалось абсолютно индифферентно и к переключению режима контроллера и к ухудшению таймингов. Даже понижение ПСП в 2 раза привело к понижению производительности всего у двух приложений, и при этом понижение совершенно не фатальное (по сравнению с двумя разами!) Почему в лидерах чувствительности оказались Photoshop и ACDSee, понятно — они оба умеют задействовать многопоточность. ACDSee существенно хуже Photoshop — поэтому проиграл меньше. Очень поучительно смотрится полное безразличие к чему-либо графического редактора Paint.NET — как единственного представителя ПО, написанного на платформе Microsoft.NET.

Сжатие данных без потерь

Ещё один холодный душ: казалось бы, какие ещё приложения могут более чувствительно отреагировать на малейшие изменения в подсистеме памяти, как не архиваторы?! Но нет: совершенно нулевая реакция на режим контроллера, и вполне «вялая» — на ухудшение таймингов. Понижение ПСП в 2 раза приводит к более заметному эффекту, однако, повторимся: минус 50% по ПСП — дало всего лишь минус 17% по производительности. И это в приложениях, которые традиционно считаются одними из самых «памятелюбивых».

Компиляция

Более скромное падение, чем у архиваторов, при кардинальном понижении ПСП — и полное отсутствие какой-либо реакции на включение ganged-режима и ухудшение таймингов. Заметьте, опять мы наблюдаем полную индифферентность очень хорошо многопоточно оптимизированного теста к ganged-режиму.

Кодирование аудио

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

Кодирование видео

Результаты переключения режимов контроллера и повышения таймингов, традиционно, абсолютно безынтересны. Впрочем, можно отметить, что первый раз «попал с позиционированием» ganged-режим: XviD, действительно, нельзя назвать хорошо оптимизированным многопоточным приложением, и от включения данного режима ему стало на 3% лучше. Падение производительности при понижении ПСП в 2 раза продемонстрировали все участники, при этом за исключением XviD, наблюдается полная корелляция между величиной падения и многопоточной оптимизированностью (чем лучше вторая — тем больше первая).

Java

Второе «попадание» ganged-режима: тест имеет достаточно неплохую многопоточную оптимизацию, и от включения данного режима скорость понизилась. В остальном, результат очень напоминает архиваторы.

Трёхмерные игры

Ganged-режим традиционно безынтересен, на тайминги внятно отреагировали две игры — и, заметьте, это одни из лучших игр, с точки зрения многопоточной оптимизированности. Но самая интересная ситуация наблюдается при понижении ПСП в 2 раза: падение производительности около 10% является нормой, около 20% — весьма нередким явлением, а World in Conflict становится рекордсменом данного тестирования, продемонстрировав снижение fps почти на треть. Впрочем, для нас это не было сюрпризом: игры и архиваторы были признаны самыми «памятечувствительными» группами ещё в прошлом тестировании на аналогичную тематику.

Заключение

Несмотря на то, что мы увидели очень много всевозможнейших цифр и процентов, обобщённый результат нашего сегодняшнего исследования может быть сформулирован в двух словах: ни переключение режимов встроенного контроллера памяти, ни «игры» с таймингами, никакого существенного влияния на производительность систем на базе Phenom II не оказывают. Да, можно, при желании, найти аж целое одно приложение, которое в режиме 6-6-6-18 потеряло 8% скорости. Но в общей массе результаты на «хороших» и «плохих» таймингах отличаются примерно в пределах погрешности измерения. Ganged/unganged-режимы тоже, на поверку, оказались не более чем забавной игрушкой для энтузиастов: мы снова наблюдаем одно-единственное приложение, которое видит существенную разницу между ними. Правда, можно хотя бы констатировать, что unganged-режим чаще оказывается в плюсе, что даже выразилось в итоговом балле: он у него ровно на единицу выше, чем у ganged, при всех прочих одинаковых параметрах. Таким образом, практическая рекомендация владельцам систем на базе Phenom II может выглядеть достаточно кратко: включить с помощью BIOS unganged-режим — и навсегда забыть о существовании этой опции. Память с низкими таймингами, похоже, тоже никому не нужна, кроме оверклокеров. Впрочем, как раз они обычно её и покупают, так что здесь всё нормально.

С другой стороны, нельзя сказать, что подсистема памяти совсем никак не влияет на быстродействие: когда мы взяли и ухудшили все её параметры ровно в 2 раза — производительность упала, в среднем, на 11%, а некоторым приложениям и вовсе «поплохело» — скорость упала на четверть и более (кстати, заметьте, в основном, это были трёхмерные игры). Правда, чтобы увидеть реальное замедление, нам пришлось «установить» в тестовый стенд настолько медленное ОЗУ, что в реальности, наверное, таких модулей сейчас ни у кого и не найдётся (разве что на серверах, но там используется регистровая DDR2-400 с поддержкой ECC). Собственно, только в данной, по большому счёту, почти синтетической ситуации, мы смогли увидеть некие следы влияния давно уже озвучиваемой разработчиками новых стандартов памяти концепции: что, дескать, чем больше в процессорах ядер, и чем лучше многопоточная оптимизация приложений — тем острее будет проявляться необходимость в высокой ПСП.

Мы бы сказали, что результаты данного исследования хоть и несколько разочаровывают, но зато приносят реальную, большую пользу — всем тем, кто задумывался об апгрейде с DDR2-800 на DDR2-1066, или даже на какую-нибудь ещё более быструю DDR3 (с заменой процессора). Результаты прироста производительности при переходе с DDR2-400 на DDR2-800, вы видите перед собой (правда, вы видите результаты падения при переходе с DDR2-800 на DDR2-400, но это уже не суть. Понятно, что любое падение при взгляде с противоположной стороны превращается в прирост). Это, напомним — были последствия двукратной разницы в скорости подсистемы памяти. То есть даже если предположить, что масштабируемость Phenom II идеальна, для повторения данного эффекта с DDR2-800 в качестве исходного материала, вам придётся проапгрейдиться сразу на DDR3-1600. Решайте сами, стоит ли овчинка выделки.

В cледующих сериях мы рассмотрим влияние различных факторов на производительность другой популярной современной платформы — Intel Core i7.

Следующая статья серии: Intel Core i7, технологии Turbo Boost и Hyper-Threading