Методика тестирования компьютеров на базе macOS, часть 1: профессиональные приложения и сценарии28.02.2017 14:17

Часть 1: профессиональные приложения и сценарии

Более двух лет назад мы представили вам мини-методику тестирования производительности компьютеров на macOS X (тогда еще операционная система называлась просто OS X) с помощью видеоредактора Apple Final Cut Pro X и видеокодировщика Apple Compressor. С тех пор мы использовали эту методику для каждого нашего обзора ноутбуков MacBook и настольных компьютеров iMac. Однако время идет, и пришло время обновить набор тестов, а заодно дорастить мини-методику до полноценной методики, включающей не только вышеупомянутые приложения, но бенчмарки различного плана и некоторые профессиональные задачи.

Традиционно считается, что под macOS провести полноценное тестирование производительности проблематично. Не без оснований. Однако постепенно появляются качественные бенчмарки, работающие понятным образом, удобные и результативные тестовые инструменты… А если дополнить это еще и реальными сценариями работы, когда в профессиональных приложениях запускаются типичные высоконагрузочные операции и просто секундомером засекается время их выполнения, то в сумме это даст нам вполне наглядную и показательную методику, на основе которой можно будет делать выводы и сравнивать результаты компьютеров, вышедших не одновременно.

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

В этой статье мы подробно обоснуем наш выбор, пошагово опишем, как именно мы проводим тесты, и сделаем выводы на примере трех (в некоторых тестах — большего количества) MacBook Pro.

Конфигурации тестовых компьютеров

По понятной причине все новые тесты и режимы будут проверяться только на трех моделях, которые были у нас непосредственно на руках в момент разработки методики. Это MacBook Pro 13″ (Late 2012) — самая первая и самая слабая модель с экраном Retina, MacBook Pro 13″ (Late 2016) — новейшая модель с панелью Touch Bar в базовой конфигурации, а также MacBook Pro 15″ прошлого поколения — без Touch Bar, но зато с дискретной графикой AMD Radeon R9 M370X.

Приводим таблицу, в которую сведены характеристики трех моделей, имеющие отношение к производительности.

Характеристики компьютеров, на которых использовалась предыдущая версия методики (мы возьмем из нее некоторые результаты), можно посмотреть здесь, а также в статьях про каждую конкретную модель.

Тестирование производительности в Final Cut Pro X и Compressor

На момент тестирования актуальными версиями этих программ были, соответственно, 10.2.3 и 4.3. В качестве операционной системы использовалась macOS Sierra 10.12.2 на двух более новых компьютерах, а на MacBook Pro 2012 года — El Capitan 10.11.6.

В первой версии методики мы использовали снятый на видеокамеру 10-минутный видеоролик Full HD 30 fps. Подробные параметры видеоролика приведены ниже (данные получены с помощью утилиты MediaInfo из Mac App Store). Файл можно скачать здесь. Внимание: это несжатое видео, поэтому размер соответствующий: 1,73 ГБ.

Однако сегодня, когда видео 4К стало уже обыденностью, было бы неправильным обходиться без его использования при тестировании производительности видеомонтажа. Поэтому мы сняли 5-минутный видеоролик 4K 30 fps на iPhone 7 Plus. Ниже — подробная информация о нем.

Теперь приступим непосредственно к тестированию и запустим Final Cut Pro X.

Тест 1: стабилизация 4К и Full HD

Итак, первая операция — стабилизация видео 4K. Открываем видеофайл на Timeline (дожидаемся, пока вся полоса заполнится изображением), выбираем в Inspector вкладку Video и нажимаем на квадратик напротив слова Stabilization, не меняя никакие настройки.

В момент нажатия на квадратик запускаем секундомер и ждем полного завершения процесса. Кружочек с процентами под окном видео трижды дойдет до 100%. Процесс будет завершен тогда, когда наверху Timeline (под шкалой времени) не будет оранжевой полосы.

Результаты приводим в таблице:

Не очень понятно, почему так мал разрыв между моделями 2015-го и 2016-го года: у «пятнашки» и графика дискретная, и более мощный 4-ядерный процессор (правда, предыдущего поколения), и памяти вдвое больше. Самый старый MacBook Pro Retina далеко позади — монтировать 4K-контент на нем будет сплошным мучением и постоянным ожиданием.

Тест 2: стабилизация Full HD

Второй тест — все то же самое, только с файлом Full HD. Создаем новый event, открываем файл на Timeline и повторяем описанное выше.

Здесь как раз расклад ожидаемый и показательный: разница между 13-дюймовым MacBook Pro 2016 года и 15-дюймовым MacBook Pro 2015 близка к двукратной — в полном соответствии с числом ядер у их процессоров.

Этот тест был в предыдущей методике, так что результаты вполне можно сравнить с другими компьютерами, которые мы тестировали за последние два года.

Тест 3: картинка в картинке

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

После этого — сразу нажать кнопку Done, именно тогда запускается секундомер. Вот результаты:

К сожалению, этот тест выявил неожиданную проблему, с которой мы столкнулись на младшем и самом старом MacBook Pro. И дело вовсе не в производительности, а в объеме места на накопителе. Оказалось, что при объеме SSD в 128 ГБ (которые в реальности дают около 120 ГБ) при наличии других установленных приложений тестовой методики пространства для кэша Final Cut просто не хватает. После первых двух тестов, описанных выше, объем файла данных Final Cut превысил 20 ГБ, и во время операции помещения картинки в картинку приложение сообщило, что ему не хватает места. Что ж, придется иметь в виду, что в моделях с накопителем на 128 ГБ нам удастся провести не все тесты и предпочтительнее брать на тестирование модели с емкостью SSD не меньше 256 ГБ.

Что касается сравнения двух более новых MacBook, то здесь расклад в целом тот же (с небольшими нюансами). MacBook Pro 15″ показал себя безусловным лидером.

Тест 4: финальный рендеринг через Compressor

И последняя операция с видео: сохраняем результаты нашего творчества с помощью Apple Compressor. Для этого нажимаем в Final Cut Pro X вкладку File / Send to Compressor.

Открывается Compressor (разумеется, он должен быть предварительно установлен на компьютер), в нем мы нажимаем на центральную кнопку Add Outputs и в открывшемся меню выбираем Publish to YouTube / Up to 4K. Почему именно его? Потому что получаемый файл — приемлемых размеров, что хорошо для тестирования (не всегда объем SSD бывает максимальным), а кроме того, это вполне понятный «жизненный» сценарий.

После этого осталось нажать кнопку Start Batch в нижнем правом углу окна приложения — и процесс начнется.

Что ж, давайте посмотрим, сколько времени это заняло у наших испытуемых:

И опять никаких сюрпризов, все предсказуемо. Ну, а на модели 2012 года мы и не запускали этот тест, так как предыдущий этап пройден не был.

BlackMagic DaVinci Resolve

Еще одно профессиональное приложение для работы с видео — BlackMagic DaVinci Resolve. Мы использовали версию 12.5. Основное предназначение этого пакета — цветокоррекция и постобработка видео. Разработчики характеризуют свой пакет как «комплексное решение для нелинейного редактирования и грейдинга, которое позволяет выполнять монтаж, установку цвета, финальную обработку и создание конечного продукта в одном приложении».

Нам оно может быть интересно потому, что здесь используются несколько иные алгоритмы, нежели в Final Cut Pro X, а кроме того, это одно из наиболее популярных сторонних профессиональных приложений на macOS. Следовательно, с помощью его можно понять, как аппаратная часть того или иного компьютера Apple работает без программной оптимизации самой Apple (хотя, разумеется, разработчики DaVinci Resolve тесно взаимодействуют с Apple).

Пока мы предлагаем только один, очень простой тест. Если среди наших читателей есть те, кто профессионально работает с пакетом DaVinci Resolve, будем рады предложениям, как можно расширить методику.

Итак, мы открываем приложение, добавляем наш файл с 4К-видео, нажимаем правую кнопку мыши и выбираем Generate Optimized Media.

Одновременно с нажатием на эту строчку включаем секундомер. Прогресс отображается в появившемся окне.

И вот что получилось:

Главная особенность результатов — огромный разброс между самым быстрым и самым медленным из взятых нами ноутбуков. Безусловный лидер — 15-дюймовый MacBook Pro. Правда, мы затрудняемся сказать, какие именно компоненты обеспечили ему выигрыш: наличие дискретной графики, 4-ядерный процессор, объем оперативной памяти или сочетание всех этих факторов.

Компиляция и поиск по исходному коду

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

Итак, скорость компиляции мы будем проверять на Python 2. Для этого скачиваем Python 2.7.13 отсюда (17,1 МБ). Далее переходим в папку, куда был скачан пакет. Если это «Загрузки», то команда будет выглядеть так: $ cd ~/Downloads

Следующим шагом распаковываем архив: $ tar xvzf Python-2.7.13.tar

Переходим в папку с исходниками Питона: $ cd Python-2.7.13

Настраиваем параметры компиляции на текущей системе: $ ./configure

Это может занять какое-то время. После настройки начинаем компиляцию и замеряем ее время: $ time make -j 3

(в данном случае »3» — это число ядер процессора + 1; если у нас четырехъядерная система, то ставим число 5 и т. д.).

В итоге мы получаем три значения: real — это затраченное астрономическое время, user — затраченное процессорное время снаружи системных вызовов ядра, sys — время внутри ядра. Для сравнения мы будем использовать первое значение — real.

Второй тест — текстовый поиск. Для этого скачиваем исходный код ядра Linux 4.9.6 отсюда (93,2 МБ), распаковываем архив встроенной утилитой архивации или любым сторонним инструментом (например, The Unarchiver), далее запускаем Terminal, заходим в папку командой $ cd ~/Downloads/linux-4.9.6 (если папка не «Загрузки», то заменяем Downloads на соответствующее название папки).

Далее командой $ time grep -R ixbt * мы проводим поиск слова «ixbt» по папке. Если подставить какое-то другое слово, например «linux», то результатов поиска будет множество, но на время поиска это почти не влияет, поэтому мы для чистоты эксперимента будем искать «ixbt», получая каждый раз нулевой результат. Как показали эксперименты, погрешность получается в районе секунды, что при таких результатах — вполне приемлемо. Важный нюанс: тест лучше проводить после перезагрузки.

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

Как мы видим, расклад сохраняется, но разброс не столь сильный.

Выводы

Итак, мы существенно расширили мини-методику тестирования в профессиональных приложениях, «дорастив» ее до полноценной методики, включающей не только Final Cut Pro X и Compressor, но и один сторонний пакет для работы с видео (который, кстати, дал нам очень показательные результаты), а также тесты в Terminal, условно ориентированные на использование компьютера для программирования. Все вместе это позволяет не только увидеть производительность конкретных конфигураций для различных профессиональных применений, но и понять, насколько важно наличие тех или иных компонентов в конфигурации: например, что дает дискретная видеокарта, увеличенный объем памяти, количество и частота ядер процессора.

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

Полный текст статьи читайте на iXBT