Спор «За и против» так называемых синтетических тестов стар, как мир. Или, по крайней мере, как сами синтетические тесты. Основная идея, на которой они основаны, заключается в оценке общей производительности компьютерной системы, и в теории это действительно отличная идея.

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

К сожалению, идеальных вещей не существует и именно по этой причине синтетические тесты, как и любая другая вещь, не являются совершенными. В частности, двум наиболее популярным и широко используемым тестовым программам подобного класса - 3DMark и PCMark от Futuremark - уже случалось быть в эпицентре серии скандалов. Конечно, не по вине самих разработчиков из Futuremark – причины, прежде всего, заключаются в различных подходах производителей к «оптимизации» своего оборудования, с которыми они ловко используют некоторые недостатки в процедурах тестирования и реализуют искусственно завышенные результаты, которые, однако, потом не подтверждаются на практике.

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

Однако в некоторых случаях этот тип тестов не применим с чисто прагматической точки зрения – например, когда речь идет о системах бизнес-класса, для которых производительность в играх не имеет ключевого значения. Причина в том, что игры создают ложное впечатление, когда дело доходит до вполне мощной машины как, скажем, Lenovo ThinkPad X1 Carbon или НР EliteBook 1040. Такие устройства ориентированы на совершенно иной круг пользователей – на людей, которым не важно, сможет ли Battlefield 4 «поехать» на их ноутбуке со скоростью 60+ кадров в секунду. Вместо этого им важны вещи, такие как прочность конструкции, надежная защита информации и максимальное время автономной работы.

Именно в таких случаях на помощь приходит «синтетика» – как PCMark, который измеряет общую производительность всей конфигурации. Однако это приводит к некоторым особенностям относительно надлежащего толкования результатов, которые различные системы показывают в тесте.

Конкретный пример: прямое сравнение игрового ноутбука Lenovo Y50 и бизнес-ультрабука НР EliteBook 1040 может пробудить недоумение. Причина в том, что результаты этих двух систем похожи, но одна из них основана на довольно мощной дискретной видеокарте (NVIDIA GeForce 860M), а другая на интегрированном графическом решении (Intel HD Graphics 4400). Однако если мы сравним их производительность в играх, быстро станет ясно, что в отличие от Lenovo Y50, EliteBook 1040 не может обеспечить оптимального игрового опыта… И не должен, так как в данном случае мы говорим о мобильной машине с совершенно другим предназначением.

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

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

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

И еще – позвольте мне в заключение повторить: результаты синтетических тестов, будь то 3DMark или PCMark, не следует понимать буквально. Они просто хороший ориентир, один из множества инструментов для оценки производительности компьютера, так что вы не должны придавать им слишком большого значения. Если вам нужна подробная, исчерпывающая информация, которая поможет выбрать ту или иную конфигурацию, будьте терпеливы и прочитайте ее обзор целиком (или лучше несколько обзоров в разных источниках), а не прокручивайте текст до конца, только чтобы увидеть результаты синтетических тестов.

Отличного Вам дня!

Благодаря началу продаж процессоров AMD Ryzen 5 раньше намеченного срока (11 апреля) первые обзоры данных процессоров появляются уже сейчас. Мы уже рассказывали вкратце о производительности 4-ядерного процессора Ryzen 5 1400 в синтетических тестах и современных играх . Теперь же наши испанские коллеги из El Chapuzas Informatico опубликовали обзор 6-ядерного процессора AMD Ryzen 5 1600.

Данный процессор обладает шестью физическими ядрами на каждое из которых приходится по два вычислительных потока, что в итоге даёт двенадцать потоков. Базовая частота процессора составляет 3.2 ГГц, и она может динамически повышаться до 3.6 ГГц. Объём общей кэш-памяти третьего уровня у AMD Ryzen 5 1600 составляет 16 Мбайт (8+8 Мбайт), а на каждое ядро приходится по 512 кБайт кэша второго уровня и по 64 и 32 кБайт кэша инструкций и данных первого уровня, соответственно. Как и другие процессор Ryzen, этот чип выполнен в корпусе Socket AM4, а его TDP составляет 64 Вт. Рекомендованная стоимость новинки для рынка США составляет $219.

Конфигурация тестового стенда, использованного нашими коллегами, представлена следующими комплектующими:

• Материнская плата: MSI X370 XPower Gaming Titanium;
• Оперативная память: G.Skill TridentZ DDR4 3600 МГц, работающая на частоте 2400 МГц;
• Видеокарта: MSI GeForce GTX 1070 Gaming Z;
• Блок питания: Be Quiet! Dark Power Pro11 1200 В;
• Твердотельные накопители: Kingston SSDNow KC400 128 Гбайт и Corsair LX 512 Гбайт;
• Система охлаждения: Wraith Spire;
• Операционная система: Windows 10 64 бит.

Производительность одного ядра процессора Ryzen 5 1600 ожидаемо не сильно отличается от производительности одного ядра Ryzen 7 1700X, так как они построены на одних и тех же кремниевых кристалла, только у шестиядерного процессора отключено два ядра.

В многопоточных же тестах CPU-Z и wPrime 2.1 (32M) новинка показала вполне ожидаемые результаты, продемонстрировав весьма неплохой уровень производительности.

В Cinebench 15 новинка опередила не только разогнанный до 4.9 ГГц и дополненный более быстрой памятью (3600 МГц) более дорогой четырёхъядерный Intel Core i7-7700K, но и шестиядерный Intel Core i7-5930K. А вот в кодировании видео последний оказался быстрее.

С памятью процессор Ryzen 5 1600 работает отнюдь не лучшим образом, хотя и немного лучше, по сравнению с Ryzen 7 1700X.

В некоторых синтетических тестах новинка AMD показывает лучшие результаты, по сравнению с Ryzen 7 1700X, а в некоторых незначительно проигрывает ему. В большинстве же синтетических тестов процессор Intel Core i7-6700K оказывается быстрее обоих представителей AMD.

Что касается игровой производительности, то она весьма впечатляет. В большинстве тестов в разрешении Full HD (1920 х 1080 точек) новинка несильно отстаёт, от более дорогого Intel Core i7-6700K, а в некоторых и опережает его. Интересно отметить, что в играх Doom (при использовании OpenGL) и Rise of Tomb Raider (при использовании DirectX 11) процессор Ryzen 5 1600 значительно опережает Ryzen 7 1700X.

В разрешении 4K UHD (3840 x 2160 точек) ситуация обстоит примерно таким же образом, и в случае с большинством игр всё упёрлось в производительность видеокарты.

Со штатной системой охлаждения частоту процессора получилось поднять до 3.9 ГГц, при этом напряжение на ядре составило 1.36 В. Интересно будет посмотреть, на сколько удастся разогнать новинку с жидкостным охлаждением, и какие частоты её покорятся в экстремальном разгоне.

Температура процессора AMD Ryzen 5 1600 в простое составляет 39 градусов по Цельсию, а под нагрузкой 62 – 65 градусов Цельсия. Потребление системы на базе новинки в играх составило 245 Вт, что примерно равно потреблению системы на базе Intel Core i7-6700K, которое равное 250 Вт.

Синтетические тесты

В оригинальном обзоре все тесты идут на разных страницах, я же их объединю для удобства, но разделю на синтетику и игровые.

Wprime 2.0

Известная утилита для тестирования многоядерных процессоров, определяет их мощность, производя определённые вычисления. Чем меньше времени затрачено на выполнение теста - тем лучше результат.

Самым шустрым (что не удивительно - с его-то тактовой частотой) оказался главный процессор сегодняшнего теста. Неприятно удивило, что Core i5 2300 отстал почти на секунду от i5 760 (при одинаковой частоте). Наверное сказался меньший размер кеша третьего уровня.

Fritz Chess Benchmar

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

"Старичка" Core i5 760 обогнали все представители семейства Sandy Bridge.

WinRAR 3.92

Данный архиватор не нуждается в представлении. Производительность будет определяться количеством КБ/с при сжатии определённых файлов. Чем больше - тем лучше.

Картина как и в первом тесте, лидирует 2500К, за ним с большим отставанием идёт 760-й, в двух шагах от которого - i5 2300.

7-Zip 9.13

Ещё один известный архиватор, который я лично многим порекомендовал (жмёт намного лучше, чем RAR и ZIP, хорошо дружит с многоядерными процессорами и ОСями х64, плюс полностью бесплатен) в своё время. Производительность рассчитывается также, как в предыдущем тесте.

Тест проходил в режиме компрессии (первый график) и декомпрессии (второй) файлов. Хорошо видно, кто лидирует и насколько.

Adobe Photoshop CS5

Знаменитый пакет для обработки графических файлов. Я не уловил как конкретно тестировались процессоры (есть идеи - выскажитесь), но тем не менее давайте посмотрим на результаты:

Видимо, результат в секундах. Чем меньше - тем лучше. Лидируют "Песчаные мосты"

POV-Ray 3.7

POV-Ray - популярная программа с открытым кодом для тестирования процессоров в операциях с плавающей точкой. Количество очков в тесте - это количество отрендеренных пикселей в секунду, чем их больше, тем лучше.

Ситуация из предыдущего теста повторяется. Обратите внимание, какое преимущество у i5 2300 перед i5 760 (напомню, что тактовая частота, у обоих процессоров, одинаковая)! Определённо, новая архитектура показывает характер. Или помогает Turbo-режим?

CineBench R11.5

"Синебенч" не нуждается в представлении, отличный тест производительности процессора (как в режиме 1 потока, так и нескольких) в условиях 3Д рендеринга.

Картинка точь в точь такая же, как в предыдущих нескольких тестах. "Мосты" впереди, 760-й - позади. И преимущество новинок очень солидное.

H.264 Encoder V2

Кодирование видео - задача, для которой частенько берут мощные процессоры. Чем меньше времени уходит на кодирование видеоматериала в h264, тем лучше.

Бедняга 760-й! Sandy Bridge"и не дают ему ни шанса на победу. Уже хочу такой процессор (только хексакор, хотя бы), лучше сразу разогнанный до 4.5-5ГГц. А то на Atom"е и Q9550 кодировать видео уже не так радостно, как раньше

Прошло довольно много времени с выхода операционной системы Microsoft Windows Vista и обновленного DirectX 10 API в её составе. Постепенно появляются игровые приложения с поддержкой новой версии Direct3D 10, правда, пока это лишь немного переделанные D3D 9 приложения, активного использования новых возможностей D3D 10 в них нет. Да и те игры, что уже вышли, удивляют полярными результатами на видеокартах двух основных чипмейкеров, использовать их в таком виде для сравнения, конечно, можно, но очень осторожно…

Обилия пакетов синтетических и игровых тестов с поддержкой Direct3D 10 пока тоже не наблюдается, тот же Futuremark так и не выпустил очередной 3DMark. Но у сайт есть свой пакет синтетических тестов, и мы давно планировали обновить RightMark3D, чтобы иметь возможность оценить пиковую производительность D3D10-ускорителей в разных задачах. Окончательная версия RightMark3D 2.0, предназначенная Direct3D 10 совместимых ускорителей в операционной системе MS Windows Vista, появилась недавно, и мы сразу приступаем к её использованию в наших материалах.

Некоторые ранее известные тесты в составе обновленного пакета были переписаны под DX10, добавились новые виды синтетических тестов: модифицированные тесты пиксельных шейдеров, переписанные под SM 4.0, тесты геометрических шейдеров, тесты выборки текстур из вершинных шейдеров. Эта статья будет первой по RightMark3D 2.0, она включает большой набор протестированных видеокарт, далее мы начнём использовать новый тест и в своих базовых материалах.

Нужно отметить, что все наши тесты — чисто синтетические, обычно они задействуют только определенные блоки видеочипа, влияние производительности остальных намеренно уменьшено до минимума. Во всех тестах центральный процессор не задействован, всё считается исключительно видеочипом. Приступим к долгожданным DirectX 10 тестам!

Условия тестирования

Используемая нами версия пакета синтетических тестов RightMark3D 2.0 с кратким описанием тестов доступна для скачивания по (4,5 Мбайт)

Для работы RightMark3D 2.0 требуется установленный пакет MS Visual Studio 2005 runtime, а также последнее обновление DirectX runtime.

Примечание: на скриншоте изображена специальная версия RightMark3D 2.0 с возможностью тестирования в пакетном (batch) режиме. Она предназначена для внутреннего использования и будет доступна позже.

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

• Компьютер на базе Intel Core 2 Duo (Socket 775)
  • процессор Intel Core 2 Duo Extreme X6800 (2930 MHz) (L2=4096K);
  • системная плата EVGA nForce 680i SLI на чипсете Nvidia nForce 680i;
  • оперативная память 2 GB DDR2 SDRAM Corsair 1142MHz (CAS (tCL)=5; RAS to CAS delay (tRCD)=5; Row Precharge (tRP)=5; tRAS=15);
  • жесткий диск WD Caviar SE WD1600JD 160GB SATA;
  • блок питания Tagan 1100-U95 (1100W).
• операционная система Windows Vista Ultimate 32-bit; DirectX 10;
• монитор Dell 3007WFP (30").
• драйверы ATI CATALYST версии 8.3891; Nvidia ForceWare версии 158.45.

Синтетические тесты проводились на видеокартах:

• RADEON HD 2900 XT со стандартными параметрами
• RADEON HD 2600 XT со стандартными параметрами
• RADEON HD 2600 PRO со стандартными параметрами (версия с GDDR3 видеопамятью)
• RADEON HD 2400 XT со стандартными параметрами
• Geforce 8800 Ultra со стандартными параметрами
• Geforce 8800 GTX со стандартными параметрами
• Geforce 8800 GTS со стандартными параметрами (версии с 320 и 640 Мбайт видеопамяти показывают близкую производительность)
• Geforce 8600 GTS со стандартными параметрами
• Geforce 8600 GT со стандартными параметрами
• Geforce 8500 GT со стандартными параметрами

Для сравнения видеокарт друг с другом будут использоваться пары моделей AMD и Nvidia, совпадающие по позиционированию на рынке: HD2900XT — GF8800GTS, HD2600XT — GF8600GT, HD2600PRO — GF8500GT. Некоторых из видеокарт на рынке ещё нет, и если их реальные цены будут иными, нужно делать поправки к выводам статьи. Цены также постоянно изменяются, и многие из выводов статьи справедливы только для времени её выхода. Конечно, это не относится к теоретическому сравнению младших и старших чипов одной компании, оценка их относительной производительности от цен не зависит.

Описания и результаты тестов

Напоминаем, что результаты синтетических тестов унифицированных DirectX 10 архитектур нужно анализировать осторожно, нагрузка в них часто лежит только на одном или двух типах шейдеров: вершинных, геометрических, пиксельных. И если на обычной архитектуре при сбалансированной нагрузке на все перечисленные блоки производительность не снизится, то на унифицированной суммарная работа ляжет сразу на все, и скорость рендеринга упадёт.

Тесты пиксельных шейдеров PS 4.0 (текстурирование, циклы)

В новую версию RightMark3D 2.0, используемую в этой статье, вошли два уже знакомых нам PS 3.0 теста, самых сложных из наших синтетических тестов пиксельных шейдеров для Direct3D 9, а также два полностью новых теста. Первые были переписаны под DirectX 10, также в них добавились самозатенение и возможность включения суперсэмплинга, что еще сильнее увеличивает и так немалую нагрузку на видеочипы.

• Fur — процедурный шейдер, визуализирующий мех
• Steep Parallax Mapping — «тяжелая» разновидность техники parallax mapping, пока что не применяющаяся в играх, ранее описанная в статье

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

Первым тестом пиксельных шейдеров у нас будет Fur. При самых низких настройках в нём используется от 15 до 30 текстурных выборок из карты высот и две выборки из основной текстуры. Режим Effect detail — «High» увеличивает количество выборок до 40-80, включение «шейдерного» суперсэмплинга — до 60-120 выборок, а режим «High» совместно с SSAA отличается максимальной «тяжестью» — от 160 до 320 выборок из карты высот. Выглядит это вот так:

Очень сложный тест, даже судя только по описанию. Посмотрим, как с ним справляются все доступные нам DirectX 10 видеокарты. Проверим сначала режимы без включенного суперсэмплинга, они относительно просты, и соотношение результатов в режимах «Low» и «High» должно быть примерно одинаковым.

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

Цифры, показанные в разных режимах, неплохо соотносятся друг с другом — результаты в «High» примерно в полтора раза ниже, чем в «Low». Что касается соотношения производительности между топовыми картами и картами среднего уровня, то можно сказать, что урезание исполнительных блоков достаточно сильно бьёт по чипам среднего и нижнего уровней у обоих производителей, особенно это относится к решениям Nvidia (да и к AMD, если предположение о недостатках текущих версий драйвера верно) — G84 отстает от G80 раза в три, а G86 показывает результат ещё в два раза ниже. Судя по этим цифрам, производительность данного теста зависит не только от количества и скорости блоков TMU, иначе разница была бы меньшей.

Посмотрим на результат этого же теста, но с включенным «шейдерным» суперсэмплингом, который увеличивает объёмы работ ещё в четыре раза:

Такая сложность теста под силу только топовым чипам, показанные значения частоты кадров в секунду красноречиво говорят об этом. В целом картина вырисовывается примерно такая же, что и в предыдущем случае, но явно видно, что по мере увеличения сложности шейдера и нагрузки на видеочип, решения AMD начинают догонять видеокарты Nvidia. Geforce 8600 уже не выигрывает у HD 2900 XT, хотя и близок к нему, а Geforce 8500 GT начинает даже немного проигрывать своему конкуренту по ценовому диапазону — HD 2600 PRO.

Включение суперсэмплинга теоретически увеличивает нагрузку ровно в четыре раза, но на видеокартах семейства G8x оно снижает скорость более чем в 5 раз, а на R6xx — лишь в 3 с небольшим, за счет чего последние в таких условиях и получают улучшенные относительные результаты. Скорее всего, при соответствующей доработке драйверов Nvidia сможет снизить падение производительности при включении SSAA, но ведь и у AMD есть подобные возможности по улучшению…

Второй тест, измеряющий производительность выполнения сложных пиксельных шейдеров с циклами при большом количестве текстурных выборок — Steep Parallax Mapping. При низких настройках он использует от 10 до 50 текстурных выборок из карты высот и три выборки из основных текстур. При включении тяжелого режима с самозатенением число выборок возрастает в два раза (от 20 до 100), суперсэмплинг увеличивает это число в четыре раза (от 40 до 200 выборок). Наиболее сложный тестовый режим с суперсэмплингом и самозатенением использует от 80 до 400 текстурных выборок, то есть в восемь раз больше, по сравнению с простым режимом.

То же самое — проверяем сначала простые варианты без суперсэмплинга:

Второй тест более интересен с практической точки зрения, так как разновидности parallax mapping уже применяются в играх, а тяжелые варианты, вроде нашего steep parallax mapping, скоро будут в них использоваться. И в этом тесте, помимо суперсэмплинга, можно включить самозатенение, которое увеличивает нагрузку на видеочип примерно в два раза. Такой режим называется «High», а обычный — «Low».

В наших Direct3D 9 тестах parallax mapping, решения ATI (а затем и AMD) традиционно были сильны, в этот раз выигрыша не получилось, наоборот, без включения суперсэмплинга чипы Nvidia справляются с задачей быстрее. Сразу же отмечаем и несколько большее падение производительности при переходе от режима «Low» к «High» у видеокарт AMD. Изменение результатов при включении самозатенения у решений Nvidia равно примерно 1.5 раза, а у AMD — более двух раз. За счет этого результаты в режиме «High» у последних и оказываются относительно низкими. В общем, по результатам проведенных тестов можно ещё раз отметить победу решений Nvidia во всех ценовых диапазонах, особенно заметен выигрыш в верхнем сегменте.

Чипы среднего и нижнего ценового диапазонов в этом тесте показывают себя примерно так же или чуть лучше: средние отстают от топовых более чем в два раза, и во столько же раз отстают от средних самые слабые. Посмотрим, что изменит включение суперсэмплинга, в прошлом тесте он вызывал большее падение скорости на Nvidia, а это может улучшить положение карт AMD.

По цифрам FPS в очередной раз можно оценить сложность наших задач даже для high-end решений. Посмотрите на полученную частоту кадров в секунду при включенных суперсэмплинге и самозатенении (последний график), совместное включение их увеличивают нагрузку почти в восемь раз, вызывая катастрофическое падение производительности. Разница между скоростью видеокарт из разных ценовых сегментов сохраняется.

Включение суперсэмплинга сказывается почти как и в предыдущем случае — карты на чипах AMD R6xx улучшают свои показатели относительно Nvidia G8x. Странно, что у Nvidia получилось падение в 4 раза (равно теоретическому), а у AMD — только в 3 раза. Несмотря на это, общей победы у AMD не получается, разве что в нижнем ценовом сегменте Geforce 8500 GT (G86) привычно проигрывает HD 2600 PRO (RV630). В остальных парах констатируем еще одну победу решений Nvidia.

Тесты пиксельных шейдеров PS 4.0 (вычисления)

Следующая пара тестов пиксельных шейдеров содержит минимум текстурных выборок, это сделано для снижения влияния скорости блоков TMU на общую скорость. Зато используется очень большое количество арифметических операций (sin, cos, возведение в степень и т.п.). Эти тесты измеряют именно математическую производительность видеочипов, скорость выполнения арифметических инструкций в пиксельном шейдере. Влияние всех остальных исполнительных блоков сведено к минимуму.

Первый математический тест — Mineral. Его можно назвать тестом сложного процедурного текстурирования, в нём используются лишь две выборки из текстурных данных и 65 инструкций типа sin и cos, всего более тысячи инструкций на пиксель.

В соответствии с результатами наших исследований при помощи прошлой версии пакета Direct3D 9 синтетических тестов, в вычислительно сложных задачах архитектура AMD показывает себя очень хорошо, все их решения опережают конкурентов. Но Nvidia G8x отстают не так уж сильно. Да, решения AMD оказываются быстрее во всех ценовых сегментах, но в high-end, наиболее важном стратегически, опережение небольшое, особенно учитывая, что у Nvidia есть и более дорогие решения. Вот в нижнем и среднем сегментах решение на чипе G86 не может противостоять натиску нижнего RV630 и примерно соответствует решению на основе RV610, а быстрый вариант на основе G84 отстаёт от верхнего RV630. В целом, если учитывать реальные и предполагаемые цены всех решений, победа в этот раз за AMD.

Производительность решений среднего уровня обоих производителей в этом тесте примерно в два раза ниже скорости ближайших топовых, low-end чипы выступают хуже ещё в два раза. Наблюдается традиционное соотношение уже который раз, в полном соответствии с урезанием с точки зрения теории, учитывая и тактовые частоты. В общем, не всё так плохо у DirectX 10 чипов среднего и низшего уровней… Хотя, речь в любом случае не идёт о максимальных настройках будущих D3D 10 игр, в них и high-end картам будет несладко.

Второй тест этого блока носит название Fire, и он ещё более тяжёл для ALU. В нём текстурная выборка есть только одна, зато количество инструкций типа sin и cos увеличено до 130, всего более тысячи инструкций.

Смотрим, что изменилось при увеличении нагрузки:

Сразу отмечаем, что полноценного сравнения в тесте «Fire» не получается — налицо явная ошибка в драйверах AMD, которая не позволяет их продукции показывать соответствующие реальной силе результаты. Прежде чем делать выводы, дождемся исправлений в драйверах.

Разница между младшим вариантов G80 и старшим G84 в очередной раз получилась чуть более двух раз, что примерно соответствует разнице в частотах и количестве исполнительных блоков. То же самое касается и low-end чипа Nvidia.

Тесты геометрических шейдеров

В пакет RightMark3D 2.0 включены два теста скорости геометрических шейдеров в разных условиях. Первый вариант носит название «Galaxy», техника аналогична «point sprites» из предыдущих версий Direct3D. В нем анимируется система частиц на GPU, геометрический шейдер из каждой точки (всего от 0.5 до 2.0 миллионов) создает четыре вершины, образующих частицу (quad expansion). Судя по всему, подобные алгоритмы будут широко использоваться в будущих DirectX 10 играх, поэтому показанные результаты в тесте особенно интересны.

Важно отметить, что изменение балансировки в наших тестах геометрических шейдеров не изменяет визуальный результат, в обоих случаях итоговая картинка абсолютно одинакова, изменяются лишь способы обработки сцены. Параметр «GS load» определяет, в каком из шейдеров производятся вычисления — в вершинном или геометрическом, но количество вычислений в обоих случаях одинаково.

Рассмотрим первый вариант теста «Galaxy», с вычислениями в вершинном шейдере, для трёх уровней геометрической сложности:

Видно, что соотношение скоростей при разной геометрической сложности сцен получилось примерно одинаковым для всех условий, отличаются только абсолютные значения. Показываемая всеми решениями производительность полностью соответствует количеству точек, с каждым шагом падение FPS составляет около двух раз. Видеокарты Nvidia в таких условиях чувствуют себя чуть лучше, показывая большие результаты во всех сравниваемых парах: Geforce 8800 GTS быстрее HD 2900 XT, Geforce 8600 GT быстрее HD 2600 XT, Geforce 8500 GT быстрее HD 2600 PRO. Разница хоть и небольшая, но она есть.

Задача не такая уж сложная для современных видеокарт, топовые решения незначительно обогнали видеокарты среднего уровня, разница не достигает и двух раз. Хотя low-end отстают от mid-end всё в те же два раза. Возможно, при переносе части вычислений в геометрический шейдер ситуация изменится, как при сравнении решений разных производителей, так и ценовых сегментов. Сейчас мы это проверим.

Действительно, произошли некоторые изменения. Теперь решения на базе чипов G8x не всегда выигрывают у решений на основе R6xx во всех случаях с разным количеством геометрии. Хотя Geforce 8600 GT всё равно опережает RADEON HD 2600 XT, а Geforce 8500 GT немного опережает HD 2600 PRO, топовая видеокарта AMD вырывается вперед. Интересно, что между цифрами Geforce 8800 GTX и GTS почти нет разницы, хотя число активных исполнительных блоков у этих чипов отличается. В итоге, AMD продолжает проигрывать, что немного странно, учитывая отмеченную в наших прошлых тестах высокую эффективность выполнения вершинных шейдеров их чипами. Посмотрим, может быть во втором тесте результат изменится…

«Hyperlight» — это второй тест геометрических шейдеров в новой версии RightMark3D, который демонстрирует использование сразу нескольких интересных техник: instancing, stream output, buffer load. В нем используется динамическое создание геометрии при помощи отрисовки в два буфера, также этот тест использует новую возможность DX10 — stream output. Первый используемый шейдер генерирует направление лучей, скорость и направление их роста, эти данные помещаются в буфер, который используется вторым шейдером для отрисовки. По каждой точке луча строятся 14 вершин по кругу, всего до миллиона выходных точек.

Новый тип шейдерных программ используется для генерации «лучей», а с параметром «GS load», выставленном в «Heavy» — ещё и для их отрисовки. То есть, в режиме «Balanced» геометрические шейдеры используются только для создания и «роста» лучей, вывод осуществляется при помощи «instancing», а в режиме «Heavy» выводом также занимается геометрический шейдер. Сначала рассматриваем лёгкий режим:

Результаты разных видеокарт относительно друг друга практически не отличаются, вне зависимости от геометрической сложности сцены. Производительность хорошо масштабируется и почти соответствует теоретическим параметрам, по которым каждый следующий уровень «Polygon count» должен быть в два раза медленней.

Большое преимущество видеокарт Nvidia наблюдается и в этот раз, когда нагрузка на геометрические шейдеры не так велика. RADEON HD 2900 XT уступает даже Geforce 8600 GT, а нижнее решение Nvidia незначительно опережает HD 2600 XT. Про G80 и говорить не стоит — они далеко впереди, и их производительность явно ограничена чем-то другим, так как по сравнению с G84 они не слишком много выигрывают.

Интересно, что производительность HD 2400 XT почти равна скорости HD 2600 PRO и обе цифры сильно отстают от HD 2600 XT, в прошлые разы такого не было. Все эти цифры могут измениться в следующем нашем тесте, где геометрические шейдеры используются ещё активнее. Особенно интересно будет сравнить цифры, полученные в «Balanced» и «Heavy» режимах друг с другом.

Согласитесь, ситуация получилась совсем другая! Можно четко сказать, что чипы серии AMD R6xx выполняют такую работу значительно быстрее чипов Nvidia G8x, имея преимущество в 2 раза и даже более. Производительность данных тестов очень сильно зависит от сложности работы для геометрических шейдеров. Чипы AMD выполняют работу не просто быстрее решений Nvidia, с усложнением геометрии эта разница растёт. Получается, что чем сложнее работа для геометрического шейдера, тем быстрее будут R6xx по сравнению с G8x.

Но, сравнивая результаты в разных режимах, когда выводом занимаются разные типы шейдеров, нужно отметить, что у Nvidia результаты в «Balanced» получились лучше, чем в «Heavy» у AMD. При том, что выводимая картинка не отличается. Это в очередной раз грозит разработчикам 3D приложений тем, что им придётся оптимизировать свой код для двух столь разных архитектур, чтобы добиться максимальной производительности от обеих.

При переходе от использования «instancing» к геометрическому шейдеру при выводе, видеокарты Nvidia сильно теряют в производительности, от 2 до 6 раз. Причем, чем младше чип, тем большая разница в скорости рендеринга между двумя режимами. У AMD же всё наоборот, результаты в режиме использования геометрического шейдера для вывода больше, чем с «instancing», пусть и не в разы. Получается, что сами по себе геометрические шейдеры при увеличении работы (количества генерируемых вершин) работают лучше на чипах AMD, но реальность тем и отличается от синтетических тестов, что разработчики вольны выбирать свой путь сами, и если использование для их задач вершинных шейдеров будет выгоднее, они вполне могут так и сделать.

Крайне любопытна и разница между скоростью в режимах «Balanced» и «Heavy» для разных чипов одной линейки. Забавная ситуация со сравнением HD 2400 XT и HD 2600 PRO усугубилась — теперь младший чип даже выигрывает у старшего. И «виновата» тут, скорее всего, более высокая частота младшего решения и ограничение скорости triangle setup. У Nvidia такого не наблюдается, все чипы показали результаты строго по линейке — G84 медленнее G80 в 2-3 раза, а G86 — в 4-6 раза. С HD 2600 PRO связана ещё одна загадка, объяснить которую не получается — только эта видеокарта производства AMD теряет в производительности при смене режима с «Balanced» на «Heavy» в режиме с большим количеством геометрии.

Нужно отметить и ошибку в драйверах AMD, которая проявляется только на HD 2900 XT, вызывая в наиболее сложном режиме теста «Hyperlight» отсутствие выводимой картинки и аномально высокий результат, который нельзя принять за корректный. Поэтому в последней диаграмме результата для этой видеокарты нет.

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

Скорость выборки текстур из вершинных шейдеров

В тестах «Vertex Texture Fetch» измеряется скорость большого количества текстурных выборок из вершинного шейдера. Тесты похожи друг на друга, теоретически, соотношение между скоростями тестов «Earth» и «Waves» должно быть примерно одинаковым. В обоих тестах используется на основании данных текстурных выборок. Отличие в том, что в тесте «Waves» используются условные переходы, а в «Earth» — нет.

В первом тесте («Earth») делается 32 (для режима «Effect detail Low») или 48 («Effect detail High») билинейных текстурных выборки на каждую вершину. Количество вершин также можно изменять, для трех возможных режимов эти числа соответствуют: 30000, 124000 и 280000.

Рассмотрим режим «Effect detail Low»:

Все три графика показывают примерно одинаковую картину производительности видеокарт относительно друг друга, разве только производительность Geforce 8500 GT при увеличении нагрузки «проседает» быстрее, чем производительность конкурирующего HD 2600 PRO, если в «Low» выигрывает первая видеокарта, то в «High» впереди уже решение AMD. У пары HD 2600 XT и Geforce 8600 GT всё с точностью до наоборот, при небольшой нагрузке впереди решение AMD, а в «High» оно уже чуть-чуть отстаёт. Среди топовых решений борьбы не получилось, все варианты G80 быстрее R600.

Соотношение между производительностью верхних решений и видеокарт среднего и низшего уровней остаётся прежним, до 2-3 раза между первыми и 2-3 раза между вторыми. Интересно лишь слишком большое отличие в производительности между HD 2600 PRO и HD 2600 XT, его не объяснить отличающимся количеством текстурных модулей (TMU), так как используются одинаковые чипы. На результаты теста может влиять и пропускная способность памяти, которая у PRO и XT вариантов сильно отличается.

Посмотрим на результаты этого же теста с увеличенным количеством текстурных выборок:

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

Посмотрим результаты второго теста VTF, интересно, проявятся ли там схожие проблемы? Тест «Waves» отличается меньшим количеством выборок, зато используются условные переходы. Количество билинейных текстурных выборок в данном случае до 14 («Effect detail Low») или до 24 («Effect detail High») на каждую вершину. Сложность геометрии изменяется аналогично предыдущему тесту, общее количество вершин может быть равно примерно 124000, 498000 и 1122000 для режимов «Polygon count Low», «Medium» и «High», соответственно.

«Waves» не показывает нам чего-то нового, всё примерно так же, как и в предыдущем тесте «Earth». Видно, что некоторые чипы Nvidia (G80 и G86) теряют кадры в секунду с ростом сложности геометрии чуть быстрее, чем конкуренты от AMD (R600 и RV630), но лучшими в большинстве случаев всё равно оказываются решения Nvidia.

Последние результаты также примерно соответствуют показанным в предыдущих случаях, лишь преимущество решений Nvidia видно чуть лучше. В целом, хорошо видно, что видеокарты на основе чипов Nvidia G8x выполняют наши тесты текстурных выборок из вершинных шейдеров быстрее, чем решения AMD на основе архитектуры R6xx. Это и есть основной вывод из данной серии VTF тестов.

Заключение и выводы по синтетическим тестам

Итак, дебют применения RightMark3D 2.0 для исследований на нашем сайте состоялся. Тесты в его составе затрагивают почти все аспекты нововведений в Direct3D 10, они гибко настраиваются, позволяя нам оценить сравнительную производительность всех линеек Direct3D 10 чипов от AMD и Nvidia. Обе унифицированные архитектуры этих компаний показали себя в наших новых Direct3D 10 тестах вполне неплохо, больших провалов производительности не обнаружено, за исключением пары случаев с явными ошибками в драйверах AMD. Оба семейства: R6xx и G8x отличаются высокой вычислительной и текстурной производительностью, они хорошо справляются со сложными шейдерами всех типов.

• Если брать результаты в целом, то у решений Nvidia есть некоторое преимущество перед конкурентами от AMD, на данный момент их видеокарты оказываются впереди в большинстве случаев. Но в некоторых тестах чипы AMD показывают лучшие результаты, например, в сложных тестах геометрических и пиксельных шейдеров. Преимущество чипов AMD в таких тестах при увеличении нагрузки даже растёт. Так что исход сражения в DirectX 10 играх пока что не определён, нельзя сказать однозначно, кто из соперников его выиграет. Можно лишь предположить, что там будут аналогичные нашим результаты — в основной массе приложений R6xx и G8x будут близки друг к другу, в некоторых будут лидировать решения на основе решений компании Nvidia, в других — AMD. И зависеть это будет во многом от разработчиков и от используемых ими методов и алгоритмов.
• Тесты пиксельных шейдеров версии 4.0 показали, что с множественными текстурными выборками при сравнительно небольшой загрузке ALU лучше справляются видеочипы Nvidia. Решения AMD, в свою очередь, опережают конкурентов в вычислительных тестах пиксельных шейдеров. В одном из них видеокарты на основе чипов архитектуры R6xx показали очень неплохие результаты и опередили конкурентов из стана Nvidia, а ситуация во втором тесте пока не ясна из-за ошибок в драйверах.
• Как мы уже отмечали, тесты геометрических и вершинных шейдеров дают отличающиеся результаты, в одних лидируют решения Nvidia, в других — AMD. Так как при росте сложности работы для геометрического шейдера вперед выходят видеокарты AMD, то можно предположить, что в приложениях с активным использованием геометрических шейдеров, если таковые появятся в ближайшее время, будут лидировать чипы этой компании.
• Последняя пара тестов RightMark3D 2.0 — тесты на скорость выборки текстур из вершинных шейдеров. Показанные в них результаты отчетливо говорят о том, что видеокарты на основе чипов Nvidia G8x выполняют наши тесты текстурных выборок из вершинных шейдеров быстрее, чем решения AMD на основе архитектуры R6xx. Это связано с традиционно разным балансом между текстурными и вычислительными возможностями у чипов двух конкурирующих компаний.
• «Урезание» количества шейдерных блоков, блоков TMU и ROP довольно существенно ударило по решениям среднего и низшего уровней, значительно снизив их производительность. Недорогие видеокарты отстают от топовых в разы, лучшие из mid-end в 2-3 раза (от HD 2900 XT и Geforce 8800 GTS), а low-end ещё больше — до 4-8 раз. Что подтверждается и результатами игровых тестов, пока что только Direct3D 9.
• Судя по полученным нами результатам, драйверы AMD для Vista явно хуже доработаны по сравнению с драйверами Nvidia. Если у продукции второй компании в наших тестах никаких ошибок не было обнаружено, то у решений AMD наблюдались две явные проблемы: у всей линейки чипов во втором «вычислительном» тесте пиксельных шейдеров («Fire»), а также у топового решения HD 2900 XT в наиболее сложном режиме теста на скорость выборки текстур из вершинных шейдеров «Earth». Очень хотелось бы верить, что эти недостатки будут устранены в ближайших версиях драйверов CATALYST.

Мне не нравится, когда кто-то пытается использовать созданные вручную примеры кода для оценки возможностей статического анализатора кода. Сейчас на конкретном примере я продемонстрирую, почему негативно отношусь к синтетическим тестам.

Не так давно Bill Torpey написал в своем блоге заметку "Even Mo" Static ", где рассказал, как, на его взгляд, показали себя инструменты Cppcheck и PVS-Studio при анализе проекта itc-benchmarks . Проект itc-benchmarks - это static analysis benchmarks from Toyota ITC.

Мне не понравилось, что после прочтения статьи создается впечатление, что анализаторы Cppcheck и PVS-Studio приблизительно равны в своих возможностях. Из статьи следует, что один анализатор показывает себя лучше в одном, второй в другом, но в целом их диагностические возможности похожи.

Я думаю, что это не так. Мое мнение - наш анализатор PVS-Studio в несколько раз мощнее, чем Cppcheck. И вообще, это не «мнение», я знаю это!

Однако, раз со стороны не видно, что PVS-Studio в 10 раз лучше Cppcheck, то надо попытаться понять причину. Я решил посмотреть на этот самый itc-benchmarks и разобраться, почему PVS-Studio показал себя на этой тестовой базе не лучшим образом.

Чем дальше я разбирался, тем большее раздражение я испытывал. А один пример совсем вывел меня из равновесия, и о нем я расскажу чуть ниже. Мои выводы такие: у меня нет претензий к Bill Torpey. Он написал хорошую, честную статью. Спасибо, Bill. Зато у меня есть претензии к Toyota ITC. Мое личное мнение: их тестовая база - хрень. Это, конечно, громкое заявление, но я считаю, что имею достаточную квалификацию и опыт, чтобы рассуждать о статических анализаторах кода и способах их оценки. По моему мнению, itc-benchmarks не может быть использован для адекватной оценки возможностей того или иного анализатора.

А вот собственно тест, который окончательно вывел меня из душевного равновесия.

Так что же получается, PVS-Studio на этом примере слабее чем Cppcheck? Нет, он как раз сильнее!

Анализатор PVS-Studio понимает, что этот код написан сознательно и никакой ошибки здесь нет.

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

Void GpuChildThread::OnCrash() { LOG(INFO) << "GPU: Simulating GPU crash"; // Good bye, cruel world. volatile int* it_s_the_end_of_the_world_as_we_know_it = NULL; *it_s_the_end_of_the_world_as_we_know_it = 0xdead; }
Поэтому в анализаторе PVS-Studio в диагностике V522 реализовано несколько исключений, чтобы как раз не ругаться на такой код. Анализатор видит, что null_pointer_001 является ненастоящей функцией. Не бывает в реальном коде ошибок в функциях, когда ноль записывают в указатель и сразу его разыменовывают. Да и имя функции говорит анализатору, что «нулевой указатель» здесь неспроста.

Для подобных случаев, в диагностике V522 реализовано исключение A6. Под него же попадает и синтетическая функция null_pointer_001 . Вот как опасно исключение A6:

Разыменование переменной находится в функции, в названии которой есть одно из слов:

• error
• default
• crash
• null
• test
• violation
• throw
• exception

Синтетический тест полностью подошел под это исключение. Во-первых, в названии функции есть слово «null». Во-вторых, присваивание нуля переменной происходит как раз на предыдущей строке. Исключение выявило ненастоящий код. И код действительно не настоящий, это синтетический тест.

Вот из-за подобных нюансов я и не люблю синтетические тесты!

У меня есть к itc-benchmarks и другие претензии. Например, всё в том же файле, мы можем видеть вот такой тест:

Void null_pointer_006 () { int *p; p = (int *)(intptr_t)rand(); *p = 1; /*Tool should detect this line as error*/ /*ERROR:NULL pointer dereference*/ }
Функция rand может вернуть 0, который затем превратится в NULL. Анализатор PVS-Studio пока не знает, что может вернуть rand и поэтому не видит в этом коде ничего подозрительного.

Я попросил коллег научить анализатор лучше понимать, что из себя представляет функция rand . Деваться некуда, придётся подточить напильником анализатор, чтобы он лучше себя показывал на рассматриваемой тестовой базе. Это вынужденная мера, раз для оценки анализаторов используют подобные наборы тестов.

Но не бойтесь. Я заявляю, что мы по-прежнему будем работать над настоящими хорошими диагностиками, а не заниматься подгонкой анализатора под тесты. Пожалуй, мы немного подретушируем PVS-Studio для itc-benchmarks, но в фоновом режиме и только в тех местах, которые имеют хоть какой-то смысл.

Я хочу, чтобы разработчики понимали, что пример с rand ничего на самом деле не оценивает. Это синтетический тест, который высосан из пальца. Не пишут так программы. Нет таких ошибок.

Кстати, если функция rand вернёт не 0, а 1400 лучше не будет. Все равно такой указатель разыменовывать нельзя. Так что разыменование нулевого указателя какой-то странный частный случай совершенно некорректного кода, который просто был выдуман и который не встречается в реальных программах.

Мне известны настоящие программистские беды. Например, это опечатки, которые мы выявляем сотнями, скажем, с помощью диагностики V501 . Что интересно, в itc-benchmarks я не заметил ни одного теста, где проверялось, может ли анализатор обнаружить опечатку вида «if (a.x == a.x)». Ни одного теста!

Таким образом, itc-benchmarks игнорирует возможности анализаторов по поиску опечаток. А читатели наших статей знают, насколько это распространенные ошибки. Зато содержит, на мой взгляд, дурацкие тестовые кейсы, которые в реальных программах не встречаются. Я не могу представить, что в настоящем серьезном проекте можно повстречать вот такой код, который приводит к выходу за границу массива:

Void overrun_st_014 () { int buf; int index; index = rand(); buf = 1; /*Tool should detect this line as error*/ /*ERROR: buffer overrun */ sink = buf; }
Пожалуй, такое можно встретить разве только в лабораторных работах студентов.

При этом я знаю, что в серьезном проекте легко встретить опечатку вида:

Return (!strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1) && !strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1));
Эту ошибку анализатор PVS-Studio