Мне не нравится, когда кто-то пытается использовать созданные вручную примеры кода для оценки возможностей статического анализатора кода. Сейчас на конкретном примере я продемонстрирую, почему негативно отношусь к синтетическим тестам.
Не так давно 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:
Разыменование переменной находится в функции, в названии которой есть одно из слов:
При этом, переменной присваивается 0 строчкой выше.
Синтетический тест полностью подошел под это исключение. Во-первых, в названии функции есть слово "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 нашел в коде компилятора GCC. Два раза сравниваются одни и те же строки.
Получается, что тесты на поиск экзотического кода с rand есть, а на классические опечатки нет.
Предлагаю всем установить и попробовать мощнейший анализатор кода PVS-Studio .
Спор «За и против» так называемых синтетических тестов стар, как мир. Или, по крайней мере, как сами синтетические тесты. Основная идея, на которой они основаны, заключается в оценке общей производительности компьютерной системы, и в теории это действительно отличная идея.
В идеальном мире результат такого теста может дать вам ясное и, что более важно, реалистичное представление о том, что вы могли бы ожидать от компьютера, будь то настольного или мобильного, в различных практических сценариях – от работы и просмотра интернета до мультимедийных развлечений и игр.
К сожалению, идеальных вещей не существует и именно по этой причине синтетические тесты, как и любая другая вещь, не являются совершенными. В частности, двум наиболее популярным и широко используемым тестовым программам подобного класса - 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.
Конфигурация тестового стенда, использованного нашими коллегами, представлена следующими комплектующими:
Производительность одного ядра процессора 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 Вт.
Мне не нравится, когда кто-то пытается использовать созданные вручную примеры кода для оценки возможностей статического анализатора кода. Сейчас на конкретном примере я продемонстрирую, почему негативно отношусь к синтетическим тестам.
Не так давно 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:
Разыменование переменной находится в функции, в названии которой есть одно из слов:
Синтетический тест полностью подошел под это исключение. Во-первых, в названии функции есть слово «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
Методика тестирования
Настройки AMD Catalyst Control Center | |
---|---|
Antialiasing | Use application settings |
Anisotropic Filtering | Use application settings |
Tesselation | Use application settings |
Catalyst A.I., Texture Filtering Quality | Quality, Enable Surface Format Optimization |
Mipmap Detail Level | Quality |
Wait for V-Sync | Off, unless application specifies |
Anti-Aliasing Mode | Multi-sample AA |
Direct3D Settings, Enable Geomery Instancing | On |
Triple buffernig | Off |
Настройки NVIDIA Control Panel | |
Ambient Occlusion | Off |
Anisotropic Filtering | Application-controlled |
Antialiasing — Gamma correction | On |
Antialiasing — Mode | Application-controlled |
Antialiasing — Settings | Application-controlled |
Antialiasing — Transparency | Off |
CUDA — GPUs | All |
Maximum pre-rendered frames | 3 |
Multi-display/mixed-GPU acceleration | Multiple display performance mode |
Power management mode | Adaptive |
Texture filtering — Anisitropic sample optimization | Off |
Texture filtering — Negative LOD bias | Allow |
Texture filtering — Quality | Quality |
Texture filtering — Trilinear optimization | On |
Threaded optimization | Auto |
Triple buffering | Off |
Vertical sync | Use the 3D application settings |
Набор бенчмарков | ||||
---|---|---|---|---|
Программа | API | Настройки | Режим тестирования | Разрешение |
3DMark 2011 | DirectX 11 | Профиль Extreme | - | - |
3DMark | DirectX 11 | Тест Fire Strike (не Extreme) | - | - |
Unigine Heaven 2 | DirectX 11 | DirectX 11, макс. качество, тесселяция в режиме Extreme | AF 16x, MSAA 4x | 1920х1080 / 2560х1440 |
Crysis Warhead + Framebuffer Crysis Warhead Benchmarking Tool | DirectX 10 | DirectX 10, макс. качество. Демо Frost Flythrough | AF 16x, MSAA 4x | 1920х1080 / 2560х1440 |
Metro 2033 + Metro 2033 Benchmark | DirectX 11 | DirectX 11, макс. настройки, DOF, тесселяция, NVIDIA PhysX выкл. | AF 16x, MSAA 4x | 1920х1080 / 2560х1440 |
Crysis 2 + Adrenaline Crysis 2 Benchmark Tool | DirectX 11 | DirectX 11, макс. качество, текстуры высокого разрешения. Миссия A Walk in the Park | AF 16x, Post MSAA + Edge AA | 1920х1080 / 2560х1440 |
Far Cry 3 + FRAPS | DirectX 11 | DirectX 11, макс. качество, HDAO. Начало миссии Secure the Outpost | AF, MSAA 4x | 1920х1080 / 2560х1440 |
Battlefield 3 + FRAPS | DirectX 11 | Макс. качество. Начало миссии Going Hunting | AF 16x, MSAA 4x + FXAA | 1920х1080 / 2560х1440 |
Crysis 3 + FRAPS | DirectX 11 | Макс. качество. Начало миссии Post Human | AF 16x, MSAA 4x | 1920х1080 / 2560х1440 |
Batman: Arkham City. Встроенный бенчмарк | DirectX 11 | Макс. качество | AF, MSAA 4x | 1920х1080 / 2560х1440 |
DiRT Showdown. Встроенный бенчмарк | DirectX 11 | Макс. качество, Global Illumination вкл. Трасса Shibuya, 8 машин | AF, AA 4х | 1920х1080 / 2560х1440 |
Unigine Heaven 2 (DirectX 11)
Crysis Warhead (DirectX 10)
Metro 2033 (DirectX 11)
Crysis 2 (DirectX 11)
Far Cry 3 (DirectX 11)
Crysis 3 (DirectX 11)
Battlefield 3 (DirectX 11)
Batman: Arkham City (DirectX 11)
DiRT Showdown (DirectX 11)
Практические замеры производительности систем с двумя видеокартами среднего класса в режиме SLI или CrossFireX нас нешуточно удивили. Честно говоря, изначально тестирование задумывалось исключительно как курьезный эксперимент, лишенный какого-либо практического смысла. А выяснилось, что средства распараллеливания нагрузки на несколько GPU при 3D-рендеринге уже настолько вылизаны, что две видеокарты из ценовой категории для прижимистых геймеров запросто опережают по производительности один мощный флагманский (или недавно бывший таковым) видеоадаптер.
Комбинация пары Radeon HD 7790, казалось, уж точно была обречена на неудачу. Ну что могут противопоставить флагманским адаптерам два GPU Bonaire, в которых совокупное количество потоковых процессоров и текстурных модулей меньше, чем у HD 7970 с чипом Tahiti XT, да еще и со скромной шиной памяти разрядностью 128 бит? Оказывается, в двух HD 7790 достаточно пороху, чтобы отбросить HD 7950 и на равных биться c HD 7970. Но только при одном важном условии, что игре достаточно скромного кадрового буфера объемом 1 Гбайт (напомним, в CrossFireX, как и в SLI, объемы памяти двух видеокарт не складываются). Ибо если его недостаточно, то всё преимущество от второго GPU сводится на нет необходимостью гонять данные из системной памяти по шине PCI-Express, пусть даже версии 3.0
Адаптеры Radeon HD 7850 избавлены от такого ярма, поскольку, согласно официальным спецификациям, комплектуются 2048 Мбайт RAM. Такого объема пока хватает для игры с самыми хардкорными настройками при разрешении 2560х1440, хоть и хватает в обрез. В результате в большинстве бенчмарков независимо от разрешения связка двух HD 7850 как минимум эквивалентна одиночной карте Radeon HD 7970 GHz Edition. Это не только совершенно неожиданный результат, но и возможность реально сэкономить деньги. Десять тысяч рублей за два самых дешевых варианта HD 7850 — это, согласитесь, заметно меньше, чем 14 тысяч за HD 7970 GHz Edition. К тому же, как ни странно, тандем потребляет меньше энергии по сравнению с одиночным флагманом AMD.
Не менее впечатляют результаты «двухголовых» конфигураций на платформе NVIDIA. Сборка двух GeForce GTX 650 Ti BOOST почти никогда не уступает бывшему флагману NVIDIA — GTX 680 — и нередко достигает уровня GeForce GTX 770. Впрочем, GTX 650 Ti BOOST и находится в более выгодном положении, чем его ближайший соперник из стана AMD — Radeon HD 7790: по количеству ядер CUDA и текстурных блоков это ровно половина чипа GK104, лежащего в основе GTX 680 и GTX 770, шина памяти — 192 бит, а объем — 2 Гбайт. Опять-таки можно сэкономить небольшую сумму, купив два GTX 650 Ti BOOST (примерно 10 500 руб.) вместо единственного GTX 680 или тем паче GTX 770.
Два GeForce GTX 660 в режиме SLI выглядели наиболее жизнеспособной из всех четырех тестовых комбинаций, ибо в совокупности два ядра GK106 с полностью функциональными вычислительными блоками по сравнению с GTX 680 имеют неплохой запас теоретической производительности. Но коль скоро даже более слабые связки составили серьезную конкуренцию одиночным видеокартам высшей категории, то неудивительно, что тандем GTX 660 стабильно опережает GeForce GTX 770 и несколько раз поравнялся с GeForce GTX 780. Увы, сменив мощный адаптер на два GTX 660, придется поступиться энергетической эффективностью, ибо две такие видеокарты потребляют больше. А стало быть, сильнее греются и наверняка сильнее шумят.
С одной стороны, за столь впечатляющие результаты надо поблагодарить программистов, которые точат и точат без устали драйверы GPU и игровые движки под SLI и CrossFireX. С другой — фактором успеха «двухголовых» систем могла стать чисто аппаратная особенность, связанная с шинами памяти. Коль скоро два GPU в тандеме работают с копиями одних и тех же данных, их можно уподобить одному процессору с количеством вычислительных блоков, примерно соответствующим оному у более крупных чипов этого же производителя. Но если GPU Tahiti имеет 384-битную шину памяти, то два GPU Pitcairn уже набирают в совокупности 512 бит. Или возьмем GK104 от NVIDIA. Он имеет 256-битную шину, а два GK106 вместе дают 384 бит. Впрочем, автор статьи не берется утверждать, что такое представление на самом деле корректно с точки зрения архитектуры SLI или CrossFireX.
Возвращаясь к практической стороне вопроса, мы все-таки не осмелимся рекомендовать две бюджетные видеокарты в качестве универсальной замены видеоадаптеров категории « для энтузиастов» . Использование SLI или CrossFireX все еще не гарантирует одинаково эффективного масштабирования производительности во всех играх. Взгляните на диаграмму Batman: Arkham City, где CrossFireX не работает по причинам либо технологического, либо политического характера. Наверняка есть и обратные примеры, когда не работает уже SLI. Кроме того, встречаются неприятные проблемы, специфические именно для CrossFireX (сильный разброс частоты смены кадров и разрывы картинки), с которыми AMD все ещё борется. Но если есть желание немного рискнуть, попробовать необычное сочетание железа и попутно сэкономить пару тысяч рублей, то пожалуйста. И конечно же, покупка второго бюджетного адаптера в дополнение к старому открывает для экономных геймеров заманчивые перспективы апгрейда малой кровью.