Некоторое время назад мы опубликовали материал, посвященный новинке AMD: «Обзор и тестирование процессора AMD Athlon X4 845 в исполнении Socket FM2+: знакомство и нюансы разгона». В нем дотошно было рассмотрено большинство нюансов в поведении AMD Excavator-Carrizo (как в штатном режиме, так и в разгоне), а также проведена оценка частотного потенциала сразу восьми серийных образцов.
Но все это лишь теория, без практической части она являет собой своеобразного «сферического коня в вакууме»: процессор может демонстрировать сколь угодно хороший разгонный потенциал, но при этом быть абсолютно бестолковым. Intel NetBurst все помнят? Особенно в виде различных Intel Celeron? Наглядный пример. И обратно: не самый лучший разгон в момент дебюта, но очень хорошее соотношение «производительность на мегагерц». Конкуренты Intel NetBurst тех времен – AMD Athlon XP и AMD Athlon 64.
Именно производительность – определяющий факт того, несут ли полученные нами знания о процессоре практическое применение, или же они так и останутся лишь академическим интересом. Вот на этот вопрос мы и постараемся получить ответ при содействии со стороны нашего постоянного партнера – компании Регард. Как это водится, я снова подошел к вопросу чересчур дотошно: итоговое количество проделанных тестов оказалось столь велико, что оптимальным решением было разделение всего набора полученных результатов на два отдельных материала. И для начала мы ознакомимся с тестами 2D-приложений и синтетики.
Отметим еще один специфический момент. Дело в том, что в сети уже можно найти достаточное количество материалов, посвященных AMD Athlon X4 845. Но мало где сравнивают производительность самих архитектур, обычно все ограничивается сравнением на штатных частотах и в разгоне. И только. А мне при проведении тестов (да и не только мне) был интересен вопрос именно прямого сравнения Excavator, Godavari, Kaveri и Vishera на одинаковых частотах и в равных условиях. Поэтому если кто-то открыл данную статью в надежде увидеть очередной шаблонный материал серии «воткнули-прогнали-тесты-на-стандартных-настройках-забыли», может дальше не читать.
Как мы будем тестировать AMD Athlon X4 845? Чтобы узнать это, требуется определиться со списком основных вопросов, ответы на которые необходимо прояснить. На мой взгляд, он выглядит следующим образом:
Исходя из этих пунктов, я поочередно построил и настроил соответствующим образом несколько тестовых стендов.
Герой нашего материала тестировался в четырех режимах:
Таким образом, разгон по частоте CPU NB Core составил примерно 13%. Скудно, но на безрыбье и рак рыба. Даже такая скромная прибавка должна отразиться на результатах тестов, если частота CPU NB Core все же влияет на производительность и является узким местом в системе.
В качестве представителя Kaveri был взят AMD Athlon X4 840.
Честь Godavari взялся отстаивать AMD APU A10-7870K.
За Vishera выступил AMD FX-8350 с двумя отключенными модулями.
Как можно видеть, настройки всех трех систем были изменены таким образом, чтобы составить максимально близкие частоты по процессорным ядрам и оперативной памяти к тестируемому процессору Athlon X4 845 (а в случае с FX-8350 – еще и количество ядер).
Еще раз подчеркну: в практически постоянно активном режиме Turbo Core, а не формально штатной частоте для вычислительных ядер 3500 МГц. Подобрав близкие частоты, мы можем сравнить разницу именно в производительности архитектур, не отвлекаясь на отличие в тактовых частотах. Исключение сделано лишь для частоты CPU NB Core ядра Vishera – для него штатной частотой являются 2200 МГц, иных вариантов не существует.
Программные тесты Futuremark, помимо близости к нагрузке, создаваемой реальными пользовательскими приложениями, содержат один очень удобный инструмент. Это мониторинг и отображение текущей тактовой частоты ЦП на графике в окне результатов тестов, благодаря чему можно действительно видеть 3800 МГц в постоянном режиме под нагрузкой.
График PCMark8: там, где процессор не нужен, его частота снижается; там, где нагрузка полная (редактирование документов с проверкой орфографии, редактирование фото, игры) – все время на пределе.
Вторит ему и 3DMark:
Сначала идут два графических теста – процессор во многом не нагружен полностью и его частоты плавают. Запускается тест, имитирующий обсчет физики на CPU, и частота процессорных ядер сразу фиксируется на 3800 МГц. Комбинированный тест, где нагрузка идет и на видеокарту, и на ЦП – частота последнего также фиксируется на значении 3800 МГц. Именно поэтому правильнее будет считать штатной частотой AMD Athlon X4 845 именно 3800 МГц.
Среди процессоров Intel Skylake прямым противником в данной ценовой категории выступает Celeron G3920. К сожалению, мне он оказался недоступен. Возникла идея его имитации посредством бывшего у меня Intel Core i3-6100 («Обзор и тестирование процессора Intel Core i3-6100: разгон запретного»). Для этого требовалось отключить Hyper Threading и снизить частоту с 3200 до 2900 МГц, но с этим возникла проблема: у материнской платы ASRock Z170 Extreme6 в BIOS отсутствует параметр, позволяющий изменять множитель ЦП. Поэтому придется смириться с отсутствием в данном тесте CPU Intel.
Подавляющее большинство пользователей привыкло оценивать производительность системы в играх по такому параметру, как среднее количество кадров в секунду. В принципе, это достаточно правильно, но не до конца. На самом деле существует еще параметр «время вывода кадра», который напрямую влияет на возможность пользоваться полученными в тестах показателями fps.
Суть в том, что монитор (здесь и далее речь будет идти о традиционном ЖК-дисплее с частотой матрицы 60 Гц) работает с фиксированной частотой обновления экрана. В эту частоту должна «попадать» и видеокарта, отрисовывая картинку на интерфейсе подключения матрицы (DVI, D-Sub, HDMI и другие) каждые 16.7 миллисекунд (повторюсь: для модели с частотой 60 Гц). Однако продолжительность рендеринга кадра – вещь весьма непостоянная и зависит от постоянно изменяющейся сложности 3D-сцены (даже при полной неподвижности игрока может меняться количество игровых персонажей в кадре, освещение и прочее) и она может быть как меньше 16.7 мс, так и больше, причем в рамках одного отрезка.
В первом случае мы можем получить и два, и три кадра, из которых будет показан только один – те самые 16.7 мс, а в последнем случае – в течение 33.4 мс (или более – зависит от конкретной ситуации) будет показываться один кадр, либо в какие-то моменты времени картинка на самом деле будет состоять из двух кадров – часть изображения будет от предыдущего кадра, часть – от текущего, причем будет отчетливо видна полоса между ними. В общем зачете мы можем получить хорошие показатели среднего fps, но при этом изображение на экране будет дерганым («фризы») или рваным и мы не получим полного удовольствия от игры.
Для более полного ознакомления с сутью проблемы стоит перейти к этим обзорам:
Помимо рассмотрения проблемы, в этих материалах предлагается два разных метода проведения тестов для определения данного явления: полуаппаратный метод с использованием карт видеозахвата (Nvidia FCAT) и программный (с помощью разбора журналов программ мониторинга).
К сожалению, первый способ малоприменим, достаточно взглянуть на стоимость упомянутой карты захвата DataPath VisionDVI-DL (на момент написания этих строк ее ценник находится в районе $1600, например). Помимо самой цены, такое оборудование не так просто приобрести чисто физически: в российской рознице это большая редкость. И напротив, дешевые массовые решения далеко не всегда могут обеспечить стабильный захват видеопотока без пропуска кадров, что является критичным для точности теста параметром (по сути в российских магазинах сейчас засилье далеко не самой качественной продукции AverMedia, лично я уже зарекся связываться с ней). Поэтому остается вариант полностью программного теста. Он несколько менее точен и все же, в целом, обеспечивает достаточно достоверные результаты, на основании которых можно делать определенные выводы.
В ходе проведения тестов будут фиксироваться минимальное и среднее количество кадров в секунду, а также время вывода кадра.
За графическую часть будет отвечать новая видеокарта: вместо использовавшейся мною на протяжении уже нескольких лет модели AMD Radeon HD 280X была приобретена MSI GeForce GTX 970 Gaming 4G 4 Гбайт (Nvidia GeForce GTX 970 3.5 + 0.5 Гбайт).
Обзор видеокарты этой модели в свое время написал мой коллега Андрей wildchaser Понкратов. Но необходимо обратить внимание на одну особенность: вопреки заявленным на сайте MSI и наблюдаемым автором 1279 МГц, на данном экземпляре графическое ядро разгонялось под нагрузкой до 1329 МГц.
Ничего необычного здесь нет – таким образом работает технология GPU Boost 2.0, которая фактически зависит от индивидуальных условий эксплуатации (например, температуры) и конкретных характеристик (например, ASIC GPU) каждого конкретного экземпляра видеокарты. И эта частота держалась вполне стабильно.
Момент принципиальный: с того тестирования прошло немало времени, обновились драйвера и сменилась операционная система, да еще и отличается и частота, на которой работает графический процессор видеокарты, поэтому между проведенными тогда и сейчас тестами недопустимо пытаться ставить какие-либо знаки равенства.
Операционная система настраивалась на стабильное быстродействие штатными средствами: отключались режимы энергосбережения и файл подкачки. При подборе настроек в играх настройки изображения задавались, исходя из выбора лучшего качества картинки, а не «все бегунки качества и разрешения на минимум», в результате которого мы получаем красивые, но зачастую бессмысленные цифры. Ведь играть по принципу «с минимальными настройками качества и низким разрешением, но зато больше сотни кадров в секунду» мало кто будет, да и в реальных режимах качественной картинки нагрузка на процессор может быть совсем иной.
Монитор, используемый в тестировании, обеспечивает разрешение только 1920 х 1080 точек. Однако, во-первых, мы тестируем бюджетный, стоимостью меньше пяти тысяч рублей процессор, в пару к которому навряд ли будет приобретаться дорогой дисплей с разрешением 2560 х 1440 точек или тем более – строиться мультимониторная конфигурация. Во-вторых, согласно статистике Steam именно 1920 х 1080 пикселей на сегодняшний день являются самым распространенным разрешением – в 36.5% случаев (в январе, кстати, это число было 35.21%). Все остальное уступает ему: второе место в статистике Steam досталось 1366 х 768 (25.92%), третье – 1600 х 900 (6.6%).
Используемый тестовый стенд собирался из следующих комплектующих:
Программное обеспечение:
Бесплатный открытый архиватор файлов. Некоторое время проект практически не подавал признаков жизни, но затем ожил и сейчас регулярно получает обновления.
Результаты упаковки и распаковки по показаниям встроенного теста производительности (размер словаря – 32 Мбайт, количество потоков – по числу поддерживаемых процессором).
7-Zip 16.02 x64, упаковкаНа процедуре упаковки ядро Vishera – безусловный лидер. Второе место оказалось за Kaveri. Третьим же, как ни странно, с заметным отрывом стал Godavari, который технически является все тем же Kaveri, но с некоторыми доработками, нацеленными на повышение частотного потенциала.
Carrizo оказался аутсайдером. И пусть разгон спас положение, но фактически есть отставание в производительности и никуда не девается. Зато на распаковке AMD Athlon X4 845 отыгрывается в полной мере.
Альтернативный и более старый архиватор файлов. Он же – платный. Будем надеяться, что автор не обидится на нас за использование бесплатной пробной версии.
Результаты упаковки и распаковки по показаниям встроенного теста производительности (размер словаря – 32 Мбайт, количество потоков – по числу поддерживаемых процессором).
WinRAR 5.40 beta3 x64Здесь расстановка сил немного меняется и Carrizo смотрится более уверенно. Скорее всего, дело не в разнице между архиваторами, а в том, что показатель суммарный – общий и для распаковки, и для упаковки.
Тестирование скорости финального рендеринга в очень популярном программном пакете Blender. В качестве теста взят общедоступный 2.7x Cycles benchmark (Updated BMW). Результат теста – среднее значение по итогам трех проходов.
В финальном рендеринге наиболее сильными оказываются Kaveri и Godavari. Представитель Carrizo проигрывает всем и вся. Наиболее эффективным действом для данного процессора в этой ситуации будет разгон памяти.
Тестовый пакет немецкой компании Maxon, основанный на пакете для создания трехмерной графики и анимации Cinema 4D R15. Используется тест CPU. Приводится среднее значение по итогам трех запусков.
«Звездный час» Carrizo: все оппоненты оставлены позади. Интересно, что уровень производительности в нагрузке этого рода распределился четко в соответствии с возрастом ядер: самое слабое и старое – Vishera, затем идет Kaveri, потом Godavari и, наконец, Carrizo.
TrueCrypt умер, но дело его живо. На основе этого проекта в свое время было создано множество «форков», использующих его исходный код, но с некоторыми модификациями. VeraCrypt является одним из таковых и обладает графическим интерфейсом, очень похожим на оригинал.
Используются результаты встроенного теста производительности в подтесте «AES (Twofish(Serpent))» на объеме 1 Гбайт.
VeraCrypt 1.17 x64Шифрование данных также конек Carrizo: здесь Vishera, Kaveri и Godavari выступили примерно на одном уровне, Carrizo же – с заметным отрывом впереди. В плане разгона наиболее важными являются частоты CPU NB Core и ядра.
Сборка 1.4+5. Небольшой тестовый программный пакет, позволяющий оценить производительность системы при кодировании видео в формате Full HD перспективным кодеком нового поколения x265. Результат теста – среднее значение по итогам трех проходов.
Считается, что под кодирование мультимедиа наиболее приспособлено ядро Vishera, но, как мы видим, с кодеком x265 это уже не совсем так, мало того, оно и вовсе аутсайдер. Первое призовое место – Carrizo.
В качестве файла для распознавания был взят документ разработчика Phison (формат pdf), описывающий NAND-контроллер Phison PS3108-S8. Формально файл содержит пометку «Конфиденциально», но он свободно доступен на просторах сети.
Программа запускалась с настройками по умолчанию.
При работе с распознаванием текста в ABBYY FineReader 12 оптимальным выбором снова оказывается Carrizo – именно это процессорное ядро наиболее быстрое в данной задаче. И по разгону актуальным после увеличения частоты ядер стоит CPU NB Core.
Версия 2.7.613 Steam. Сценарий «Home».
Дабы не перегружать статью излишним количеством графиков, мы ограничимся только одним общим. Более подробно результаты можно посмотреть в базе Futuremark:
Тестовый пакет PCMark имитирует сразу все: игры, общение посредством видеочатов, написание и редактирование текстов, посещение онлайн-магазинов. И по результатам замеров между архитектурами Vishera, Godavari и Kaveri нет особой разницы. Carrizo – отстает, но незначительно.
Версия GUI 2.0.2724s64 + SystemInfo 4.47.597.0. Запускается тест Fire Strike со следующими настройками:
Дабы не перегружать статью излишним количеством графиков, мы ограничимся только одним общим. Более подробно результаты можно посмотреть в базе Futuremark:
А в этом тесте, имитирующем уже игровую нагрузку на систему, именно Carrizo является самым быстрым ядром. Разница невелика, но она есть и видна.
Специальный тест, работающий в браузере и имитирующий выполнение пользователем приложений на базе HTML5 и JavaScript при работе в интернете. Для запуска теста использовался штатный браузер, входящий в поставку Windows 10 x64 – Microsoft Edge (версия 13.10586).
Итоговым результатом являются условные баллы. Чем больше – тем лучше быстродействие системы в целом и процессора в частности.
WebXPRT 2015Carrizo снова демонстрирует своё стремление к лидерству, а в целом распределение идет по возрасту процессорных ядер.
Эта часть тестов пройдена. Какие же предварительные выводы мы можем сделать? В первую очередь стоит отметить тот факт, что разработчики AMD стараются поднять удельную производительность процессорных ядер – рост идет, хотя и очень медленно. И пусть сам по себе AMD Carrizo никакого принципиального прироста не принес, ряд положительных моментов налицо. Вплоть до того, что Carrizo порой успешно противостоит Vishera.
Наиболее важным моментом является то, что быстродействие Carrizo действительно ограничивается сниженной частотой CPU NB Core. Похоже, инженеры компании подобрали такое равновесие, чтобы и производительность страдала не слишком сильно, и в то же время можно было реализовать наибольшее количество неудачных кристаллов, не прошедших отбор для использования в ноутбуках.
Продолжение следует…
Выражаем благодарность:
