Методика тестирования производительности компьютерных систем образца 2010 года (версия 4.5)


Преамбула

Продолжая вектор, заданный ещё в методике тестирования 4.0 2009 года, мы представляем вам обновлённую версию 4.5, которая будет использоваться для тестирования процессоров и компьютерных систем на протяжении всего оставшегося 2010 года и начала года 2011. Искушённые пользователи наверняка уже поняли по номеру версии, что никаких кардинальных изменений по отношению к предыдущей, мы вам не предлагаем: более-менее традиционным останется и подход, и список групп тестов, и список приложений. Однако отличий тоже немало: в методику введены (пока в качестве опциональных) три новые группы тестов, да и в старых иногда присутствуют не только обновлённые версии, но и ранее не используемое нами ПО. Напомним, вкратце, в чём состоит суть нашего подхода к тестированию и представлению результатов.

Группировка результатов

Объединение приложений в группы по неким признакам «родства» практикуется нами уже давно, равно как и публикация в теле статьи только диаграмм с общими баллами по группам. Подробные результаты по каждому тесту выкладываются в виде отдельной таблицы, ссылка на которую присутствует в статье. Причина такого подхода очевидна: результатов очень много. Так, например, после тестирования по методике, описанию которой посвящён данный материал, получается более 100 различных результатов. Представляете себе статью, в которой 100+ диаграмм? Вот и мы с трудом. И, тем более, трудно представить человека, который дочитает такую статью до конца.

Таким образом, объединение тестов в группы, и, соответственно, объединение результатов в некий общегрупповой балл, при использовании более-менее подробной методики (предполагающей достаточно большое количество тестов) — практически неизбежно. Однако от аккуратности планирования объединяющих групп напрямую зависит, что получится в результате: или просто несколько групп результатов вместо одной большой группы, или нечто стройное, логичное и осмысленное. Начиная с предыдущей версии методики, мы окончательно перешли к принципу объединения по сходству выполняемых задач.

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

Постоянная составляющая

При любых тестированиях в рамках методики версии 4.5, постоянными остаются следующие программные компоненты:

  • Microsoft Windows 7 Ultimate x64;
  • ATI Catalyst Drivers 10.3.

Также, если речь идёт о применении методики для тестирования производительности процессоров, постоянными остаются следующие аппаратные компоненты:

  • 22" монитор с разрешением 1680x1050.
  • Видеокарта ATI Radeon HD 5870, 1 GB GDDR5;
  • Блок питания Cooler Master Real Power M1000;
  • Винчестер Samsung HD103SJ, 1 TB.

Группы тестов

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

ПО, входящее в эту группу, представлено двумя большими классами: это пакеты для работы с трёхмерной графикой (3ds max, Maya, Lightwave) и системы автоматизированного проектирования (SolidWorks, Pro/ENGINEER, UGS NX). Особенности этих двух классов состоят в том, что каждый из них, кроме визуализации, выполняет и другие достаточно ресурсоёмкие операции: в случае пакетов трёхмерного моделирования это рендеринг, в случае САПР (CAD) — инженерные расчёты. Поэтому мы решили в рамках группы «3D-визуализация» результаты тестирования во всех этих программах объединить, а результаты, относящиеся к другим типам нагрузки, учитывать в других группах. Соответственно, для пакетов 3D-моделирования это группа «Трёхмерный рендеринг», а для САПР — группа «Инженерные и научные расчёты». Теперь рассмотрим более подробно представленное в группе ПО и тесты.

3ds max

Мы продолжаем с сожалением констатировать отсутствие теста SPECapc для актуальной на данный момент версии 3ds max, что вынуждает нас прибегать к всё большему количеству ухищрений, чтобы продолжать использовать с новой версией пакета бенчмарк, выпущенный ещё в 2007 году. Увы, равного по функционалу SPECapc for 3ds max 9 альтернативного бенчмарка, мы не знаем. Однако ситуация год от года ухудшается: не все фрагменты тестового скрипта корректно работают с новыми версиями, так что его приходится модифицировать, исключая несовместимые фрагменты. В этой версии методики, нам пришлось поступить ещё более радикально, чем в предыдущих: тесты на скорость рендеринга мы убрали вообще, создав свой собственный на основе одной из сцен из бенчмарка от SPEC, но в «усложнённой редакции» и с применением рендер-движка V-Ray. Таким образом, теперь, точно так же как ранее в Maya, тест от SPEC отвечает только за «графический» балл, а рендеринг тестируется отдельно, с помощью теста нашей собственной разработки.

Maya

SPEC таки выпустила обновлённую версию бенчмарка для Maya, однако «догнать» разработчика — Autodesk — ей всё равно не удалось. Поэтому в данной версии методики мы применяем тест SPECapc for Maya 2009 в комбинации с Autodesk Maya 2010. Благо, вышеупомянутые пакеты вполне хорошо «дружат» между собой, работая в паре без сбоев и выдавая вполне адекватные результаты. Традиционно, тест от SPEC содержит только интерактивную составляющую, и не оценивает скорость рендеринга. Мы исправляем этот недостаток опять-таки традиционным для нас способом: с помощью замера времени рендеринга нашей собственной сцены для Maya (используется рендер MentalRay). Можно сказать, что в данном тесте по отношению к предыдущей версии методики ничего не изменилось, за исключением версий бенчмарка и ПО. Правда, сам бенчмарк SPEC достаточно сильно переработала: появились совсем новые сцены, были существенно «утяжелены» старые.

Lightwave

Тест SPEC для Lightwave 3 D 9.6, мы впервые использовали в предыдущей версии методики, и по результатам более чем годичного использования, он оказался вполне адекватным. В эту методику данный тест перекочевал полностью без изменений, равно как и сам программный пакет — NewTek Lightwave 3D 9.6 x64.

SolidWorks

Этот программный пакет присутствует в нашей методике уже не первый год. Но, к сожалению, за все эти годы SPEC так и не выпустила ни одного обновления своего бенчмарка, поэтому с выходом каждой новой версии SolidWorks, мы, затаив дыхание, запускаем на ней в первый раз SPECaps for SolidWorks 2007... и облегчённо вздыхаем: опять повезло — работает. Сам бенчмарк, по сути, очень похож (даже внешне) на прочие тесты SPECapc — в том числе и для пакетов трёхмерного моделирования: он замеряет производительность в трёх аспектах — процессорозависимые операции, графика, операции ввода-вывода (де-факто речь идёт о скорости дисковой подсистемы). Результаты представляют собой количество секунд, которое было затрачено на выполнение соответствующих частей бенчмарка (соответственно, лучшим является меньший результат). Напомним, что в данном разделе участвует только один результат теста — «Graphics».

Pro/ENGINEER

Для Pro/ENGINEER мы используем OCUS Benchmark, так как этот тест развивается намного динамичнее SPECapc for Pro/ENGINEER — у него есть 64-битная версия, в которой задействуется большой объём ОЗУ (а это на практике оказалось одним из самых главных преимуществ 64-битных систем), бенчмарк поддерживает самую современную версию Pro/ENGINEER Wildfire. То есть нет ни одного повода использовать старый тест от SPEC. Несмотря на то, что OCUS Benchmark разрабатывается совершенно независимо, в нём также присутствуют три результата уже знакомого нам типа: «Graphics related tasks», «CPU related tasks» и «Disk related tasks». Как и в случае с предыдущим тестом, это сумма секунд, потраченных на выполнение заданий, относящихся к соответствующей группе. В разделе визуализации из всех баллов участвует только «Graphics related tasks».

UGS NX

Ещё один CAD/CAM пакет, и ещё один старый тест от SPEC — SPECapc for UGS NX 4 (в данной методике тестирования сам пакет представлен своей 6-й версией). К счастью, тест совершенно нормально работает с обновлённым пакетом. По сути, он как близнец похож на два предыдущих: три итоговых балла, один отвечает за производительность графики, второй за производительность процессора, третий — за производительность операций ввода-вывода. Нас в рамках данного раздела интересует, соответственно, первый — графический.

Используемые тесты и ПО:

Рендеринг трёхмерных сцен

В этой группе участвуют пакеты 3ds max, Maya и Lightwave с результатами тестирования скорости рендеринга. Сама по себе, эта задача относится к достаточно узкому и специфическому классу. Во-первых, это почти идеально распараллеливаемый процесс: прирост быстродействия при добавлении ещё одного ядра (процессора) в систему зачастую составляет цифру, приближающуюся к 100%. Таким образом, будет вполне логично сравнивать между собой процессоры с различным количеством ядер обособленно в рендеринге: с одной стороны, так виднее преимущество систем с большим количеством ядер, а с другой — результаты рендеринга не разбавляют собой производительность, например, в области визуализации (где количество ядер по-прежнему не очень сильно влияет на скорость). Во-вторых, отнюдь не для всех (даже работающих с пакетами трёхмерного моделирования) пользователей скорость рендеринга на их рабочих системах важна. Если речь идёт о крупной дизайнерской компании — то там для финального рендеринга сцен зачастую используются компьютеры, специально выделенные исключительно для этой задачи (а иногда и рендер-фермы из нескольких компьютеров). Если речь идёт о дизайнере, работающем индивидуально, — то он, как правило, довольно редко запускает процесс финального (не preview) рендеринга, и даже когда делает это — сам за компьютером в это время не работает (например, запускает процесс рендеринга на ночь, когда ложится спать). Таким образом, данная группа с одной стороны представляет несомненный интерес как образец одной из весьма ресурсоёмких реальных задач, с другой же стороны — интересна далеко не всем, что и обусловило выделение рендеринга в отдельную группу.

Используемые тесты и ПО:

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

В этом разделе аккумулируются результаты, относящиеся к всевозможным расчётам. Его прообразом был раздел методики 2008 года, посвящённый научно-математическим пакетам. В методике 2009 года, мы решили аккумулировать в одном разделе все результаты подобного плана, и практика показала, что решение оказалось в целом удачным. Действительно: понятно, что MAPLE, Mathematica, MATLAB — это инструменты для учёных и инженеров. Однако те же CAD/CAM-пакеты — SolidWorks, Pro/ENGINEER, UGS NX — тоже осуществляют инженерные вычисления, и в тестах для этих пакетов тоже существует обособленный вычислительный результат. При этом, несмотря на внешне видимые различия, суть остаётся той же: да, Pro/ENGINEER может красиво повертеть деталь или механизм на экране, однако перед этим он всё равно должен их просчитать. Таким образом, в этот раздел методики вошли как тесты для научно-математических пакетов, так и процессорные баллы бенчмарков SolidWorks, Pro/ENGINEER и UGS NX. Поскольку последние уже были описаны ранее, остановимся на математических пакетах.

Для Mathematica мы по-прежнему используем два теста: встроенный бенчмарк и сторонний MMA. Правда, после обновления теста MMA до версии 7, у него появилась многопроцессорная имплементация, и теперь мы, естественно, используем именно её. Тест для MAPLE остался таким же, как в методике 2009 года. В MATLAB мы с 2009 года отказались от использования встроенного бенчмарка ввиду крайней нестабильности выдаваемых им результатов, и перешли на бенчмарк от Sciviews.org. С тех пор ничего не изменилось, лишь обновилась версия самого пакета.

Используемые тесты и ПО:

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

В группе «Растровая графика» для тестирования производительности используется 4 графических пакета, три из которых предназначены для редактирования, и ещё один — для просмотра растровых изображений: Adobe Photoshop (куда же без него?), Corel PhotoImpact (бывший Ulead PhotoImpact), Corel PaintShop Pro Photo (бывший Jasc PaintShop) и самый популярный графический вьювер — ACDSee. Последний выполняет задачу конвертации RAW-форматов в JPEG. В качестве объектов для конвертации выступают файлы формата NEF (Nicon) и CR2 (Canon), собранные в единый файловый набор размером около 1 ГБ, в примерно равном отношении. Таким образом, в бенчмарке ACDSee по сравнению с прошлым годом ничего не изменилось, за исключением версии пакета. К сожалению, из методики 2010 года пришлось исключить тест в графическом редакторе Paint.NET: автор бенчмарка, судя по всему, забросил эту разработку, а старая версия под Windows 7 и с последними версиями Paint.NET просто не работает.

Тесты для Photoshop, PhotoImpact и PaintShop Pro Photo были унифицированы: теперь все они выдают один результат — средний балл по всем операциям. Напомним, что суть тестирования состоит в выполнении тестового скрипта, который засекает время выполнения над тестовым изображением некоторых наиболее распространённых действий: эффекты размытия и повышения резкости, световые эффекты, изменение размера изображения, вращение, преобразование из одной цветовой модели в другую, трансформация, «артистические» фильтры. Быть может, некоторые читатели будут сожалеть о «пропавшей» детальной информации в тесте Photoshop, однако в данном случае искусство, к сожалению, требует жертв: в новой методике количество тестов снова выросло по сравнению с предыдущей, и нам просто необходимо «укрупнять точку зрения», чтобы не утонуть в массе результатов.

Используемые тесты и ПО:
  • Adobe Photoshop CS4 x64;
  • Corel PhotoImpact X3;
  • Corel PaintShop Photo Pro X3;
  • ACDSee Photo Manager 2009 build 115 + RAW Plugin 4.0.76.

Сжатие данных

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

Наш бенчмарк, традиционно, состоит в архивации с помощью каждого из используемых в тесте архиваторов одинакового файлового набора, состоящего из примерно равных объёмов файлов следующих типов: BMP (несжатая картинка), DBF (база данных), DLL (динамическая библиотека), DOC (документ Microsoft Word 97/2003), PDF (документ формата PDF) и TXT (простой текст в кодировке Win-1251). В нынешней методике мы добавили ещё один актуальный тест: на скорость распаковки зашифрованного архива. Данная операция достаточно ресурсоёмка (существенно более, чем просто распаковка), и, как пишут нам наши читатели, достаточно часто встречается на практике. В данном подтесте участвует только RAR-архив т.к. архив 7-Zip, даже зашифрованный, обрабатывается поразительно быстро — соответственно, измерение производительности в данном случае теряет практический смысл. Также можно отметить, что за счёт обновления версии 7-Zip, наш тест на скорость упаковки с помощью этого архиватора, теоретически, теперь может задействовать до 16 процессоров (ядер). Насколько сильно это скажется на результатах, покажет практика.

Используемые тесты и ПО:
  • 7-Zip 9.12 beta x64;
  • WinRAR 3.93 x64.

Компиляция

Данный тест остался неизменным: мы по-прежнему компилируем с замером времени свободный проект с открытым исходним кодом Ogre 3D с помощью компилятора C++, входящего в состав Microsoft Visual Studio 2008.

Используемые тесты и ПО:

Java

Этот бенчмарк впервые был опробован в методике прошлого года, и вполне «прижился» на наших тестовых стендах, демонстрируя хорошую поддержку многопроцессорности, достаточно нейтральное отношение к двум основным производителям процессоров, и способность создавать хорошую вычислительную нагрузку. Тем более что с точки зрения выполнения на компьютерах конечных пользователей, Java действительно является самым распространённым из языков программирования, а её Windows-реализация от Sun Microsystems — самой распространённой реализацией JRE (Java Runtime Environment). Мы по-прежнему используем бенчмарк от SPEC: SPECjvm2008. Он достаточно подробен, и включает в себя много подтестов из самых разных областей: Compiler (компиляция с помощью OpenJDK), Compress (сжатие данных по методу LZW), Crypto (шифрование по протоколам AES/DES, RSA, верификация по методам MD5withRSA, SHA1withRSA, SHA1withDSA и SHA256withRSA), Derby (тест использует open source БД, целиком написанную на Java), MPEGAudio (декодирование mp3 на базе LGPL-библиотеки JLayer), Scimark (популярный в научной среде бенчмарк вычислений с плавающей точкой, кстати, — мы используем его адаптированную под MAPLE версию в соответствующем тесте), Serial (параллельно-последовательное преобразование), Sunflow (визуализация с помощью многопоточно-оптимизированного движка рендеринга с поддержкой global illumination), XML (наложение таблиц стилей на XML-документы и валидация XML-документов по схеме (xsd).

Используемые тесты и ПО:

Аудио

Начиная с 2009 года, мы используем для кодирования аудио оболочку dBpoweramp, т.к. она умеет запускать несколько процессов кодирования одновременно, делая, таким образом, процесс кодирования многопоточным, даже при использовании однопоточных кодеков. Дополнительным плюсом dBpoweramp является то, что у программы имеется собственный бенчмарк, выдающий в качестве результата соотношение между скоростью кодирования аудиопотока и скоростью его проигрывания (то есть, например, результат в 20 баллов означает, что аудиопоток длительностью 20 минут был закодирован за 1 минуту). В нынешней методике не изменилось ничего, за исключением версий оболочки и некоторых кодеков.

Используемые тесты и ПО:
  • dBpoweramp Music Converter R13.4;
  • FLAC 1.2.1;
  • Monkeys Audio 3.99;
  • LAME 3.98.3;
  • Ogg 1.1.3, Vorbis 1.2.0.
  • Nero AAC Encoder 1.5.3.0.

Видео

Достаточно традиционный для наших методик раздел, который от версии к версии развивается, скорее, эволюционно, чем революционно. В нынешней версии методики, несмотря на традиционность подхода, наблюдается достаточно большое количество изменений. Во-первых, один из «старых» тестов был исключён — это тест на скорость кодирования MPEG2 с помощью Canopus ProCoder. Этот пакет уже ни с какими натяжками не может быть назван современным, обладает достаточно предсказуемым поведением, не очень-то хорошей многопроцессорной оптимизацией, поэтому нам показалось бессмысленным продолжать тестирования с его помощью. В конце концов, база результатов тестирований по старым методикам у этого ПО более чем солидная, так что те, кто по-прежнему интересуются его производительностью, имеют более чем достаточно данных для делания собственных выводов.

Перекочевали из предыдущей методики (разумеется, с обновлением ПО до актуальных версий) тесты на скорость кодирования в форматы DivX и XviD (посредством VirtualDub + Avisynth), x264, и VC-1 посредством Mainconcept Reference.

Добавились тесты в Sony Vegas Pro и Adobe Premiere. Оба теста одинаковы по смыслу: замеряется время рендеринга проекта, содержащего снятый на бытовую камеру видеоряд с наложением на него различных эффектов.

Также обновился тест на проигрывание видео высокой чёткости. Суть его, напомним, состоит в следующем: при помощи программного плеера Media Player Classic Homecinema проигрывается 10-минутный ролик с видео высокой чёткости, и в это время производится мониторинг параметра CPU usage (всех имеющихся ядер). В прошлой версии методики мы имели возможность сравнить загрузку процессора только для двух режимов: программного и аппаратного (DXVA) проигрывания ролика в формате H.264. В нынешней методике данный тест расширен — добавилось сравнение загрузки при программном и аппаратном (также с применением DXVA) проигрывания формата VC-1.

Используемые тесты и ПО:
  • AVISynth 2.58;
  • VirtualDub 1.9.8;
  • DivX Pro 7;
  • XviD 1.2.2;
  • x264 rev 1510;
  • Mainconcept Reference 2.0;
  • Adobe Premiere CS4 / Encoder CS4;
  • Sony Vegas Pro 9;
  • Media Player Classic Home Cinema x64 1.3.1249.

Игры

Игровой раздел — один из традиционных для нашей методики, и самыми крупными нововведениями в нём традиционно являются сами игры. В этом году список игр был весьма сильно обновлён, хотя некоторые особенно показательные «старички» и были оставлены. Также впервые в нашей практике здесь присутствует бенчмарк в несколько «нетрадиционной» для большинства геймеров игре — это… шахматы! Впрочем, вполне традиционных бенчмарков тоже более чем достаточно. Вторым нововведением стало повсеместное (где это можно) включение в играх 2X AA. Всё-таки 2010 год на дворе — пора бы, наверное… ;) Разрешение используется общее для всей методики — 1680x1050 при 32-битной глубине цвета, настройки качества графики в играх — «высокие» (используется следующее правило: если самые высокие настройки условно обозначены как «high», то используются они, если же самые высокие настройки имеют дополнительный атрибут вида «ultra» или «extra» — тогда используются просто «high» настройки т.е. на одно деление меньше максимума).

Используемые тесты и ПО:
  • Batman: Arkham Asylum (с PhysX и без );
  • Borderlands;
  • Colin McRae: DiRT 2;
  • Far Cry 2;
  • Fritz Chess Benchmark;
  • Grand Theft Auto IV;
  • Resident Evil 5;
  • S.T.A.L.K.E.R.: Call of Pripyat Benchmark;
  • Unreal Tournament 3 + PhysX Mod (c PhysX и без );
  • Crysis: Warhead;
  • World In Conflict.

Браузеры

Совершенно новая группа тестов, измеряющая производительность систем при исполнении JavaScript и проигрывании flash-роликов в браузерах. Здесь сразу же сделаем одно небольшое лирическое отступление, чтобы развеять весьма распространённое, как выяснилось, заблуждение: Java и JavaScript из общего, имеют только буквосочетание « Java» в своём названии. В остальном это совершенно разные языки, причём если исполнением кода Java занимается специализированная, отдельно устанавливаемая Java-машина, то исполнением кода JavaScript занимается сам браузер (соответственно, в различных браузерах JavaScript может исполняться с существенно различной скоростью). В качестве эксперимента, мы решили использовать два относительно популярных Java Script-бенчмарка от Sun Microsystems (Spider) и от Google (V8 Benchmark Suite). Ну и чтобы никому не было обидно, исполняются эти бенчмарки во всех 5 самых популярных браузерах. Бенчмарк для flash выбрать было и вовсе несложно — честно говоря, это единственный достаточно прилично сделанный flash-бенчмарк, который нам удалось отыскать на просторах интернета. Кроме того, судя по результатам предварительных тестирований, он способен создавать весьма достойную нагрузку даже для самых мощных современных систем.

Используемые тесты и ПО:

Виртуализация

Ещё одна экспериментальная группа тестов для ранее не исследованной нами области применения. Ввиду вышесказанного, мы решили, что начинать проще с простого, поэтому особой изысканностью разработанные нами тесты не отличаются: в данном случае гораздо важнее была стабильность работы и результатов, и предсказуемость поведения. Суть тестов состоит в следующем: на систему устанавливается бесплатная для некоммерческого использования (это, следует заметить, немалое достоинство) виртуальная машина Sun VirtualBox, после чего на неё инсталлируются две «гостевые» ОС: Windows XP Professional x86 SP3 и Ubuntu Linux x86. Далее, под управлением обоих «виртуальных» и основной «нативной» ОС (напомним, что это Windows 7 Ultimate x64), исполняется один и тот же бенчмарк, после чего мы имеем возможность оценить процент падения производительности под «виртуальными» ОС. Бенчмарк, который одновременно достаточно прост и предсказуем, не зависит от дисковой подсистемы (с этим аспектом производительности у виртуальных машин, исполняемых под управлением другой ОС, дела традиционно «не очень»…), существует в версии как для Windows, так и для Linux, и при этом создаёт ощутимую нагрузку хотя бы на две подсистемы — процессор и память, найти было не очень легко, но мы с данной задачей справились. Это оказался встроенный бенчмарк 7-Zip. Конечно, можно посетовать на то, что он несколько «синтетичен», однако вышеперечисленный список достоинств, с нашей точки зрения, перевешивает недостатки.

Используемые тесты и ПО:
  • 7-Zip 9.04 beta x86 для Windows;
  • P7zip 9.04 beta x86 для Linux (порт);
  • Sun VirtualBox 3.1.6;
  • Windows XP Professional x86 SP3;
  • Ubuntu Linux x86 9.10.

Скорость загрузки приложений

Данный экспериментальный тест является, пожалуй, единственным, который изначально разрабатывался нами не для тестирования процессоров, а сразу же для комплексного тестирования готовых систем. Суть его проста: одновременно даётся команда на запуск 10 достаточно «тяжёлых» приложений (список см. ниже), после чего замеряется время от подачи команды до появления на экране окна последнего открывшегося приложения. Влияют на результаты этого теста практически все ключевые параметры системного блока, за исключением, пожалуй, лишь видеосистемы: и быстродействие одиночного ядра, и их количество, и размер процессорного кэша, и быстродействие жёсткого диска, и объём ОЗУ. Разумеется, как чисто процессорный, данный тест вряд ли приобретёт большую популярность, однако для сравнения готовых систем или даже ноутбуков, он может оказаться весьма полезным.

Используемые тесты и ПО:
  • Maya 2010 x64;
  • Lightwave 3D 9.6 x64;
  • Pro/ENGINEER Wildfire 5.0 x64;
  • SolidWorks 2010 x64;
  • UGS NX 6 x64;
  • Adobe Photoshop CS4 x64;
  • Corel PhotoImpact X3;
  • Corel PaintShop Photo Pro X3;
  • Microsoft Visual Studio 8 (IDE);
  • Microsoft Visual Studio 8 (Developer Environment).

Заключение

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




Дополнительно

iXBT BRAND 2016

«iXBT Brand 2016» — Выбор читателей в номинации «Процессоры (CPU)»:
Подробнее с условиями участия в розыгрыше можно ознакомиться здесь. Текущие результаты опроса доступны тут.

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.