Методика тестирования компьютеров под управлением macOS, v2.0, часть 1: профессиональные приложения и сценарии использования
Год назад мы разработали первую версию комплексной методики тестирования производительности компьютеров под управлением macOS. С тех пор мы использовали ее при написании целого ряда статей и смогли на практике убедиться в полезности большинства тестов. Однако, время не стоит на месте, программы обновляются, производительность растет, поэтому самое время обновить методику и заодно протестировать с ее помощью актуальные конфигурации компьютеров Apple.
Прежде всего отметим, что общий «каркас» методики останется прежним: это ряд разработанных нами сценариев работы в реальных приложениях (в первую очередь — Final Cut Pro X), а также несколько бенчмарков, доказавших свою эффективность и репрезентативность. Так что необходимая преемственность сохранится. Но в деталях будет довольно много отличий, связанных и с изменениями ПО, и с накопившимся опытом применения первой версии методики.
Тестовый стенд
В качестве тестовых компьютеров мы использовали три модели Apple: новейший iMac Pro в стандартной конфигурации, 12-дюймовый MacBook последнего поколения (Mid 2017) и 15-дюймовый MacBook Pro (Mid 2015). В таблице ниже показаны основные характеристики этих моделей, относящиеся к производительности.
| iMac Pro (Late 2017) | MacBook Pro 15″ (Mid 2015) | MacBook 12″ (Mid 2017) | |
|---|---|---|---|
| Процессор (CPU) | Intel Xeon W-2140B (Skylake) | Intel Core i7–4870HQ (Haswell) | Intel Core m3–7Y32 (Kaby Lake) |
| Количество ядер CPU, частота | 8 ядер/16 потоков, 3,2 ГГц (Turbo Boost до 4,2 ГГц) | 4 ядра/8 потоков, 2,5 ГГц (Turbo Boost до 3,7 ГГц) | 2 ядра/4 потока, 1,2 ГГц (Turbo Boost до 3,0 ГГц) |
| GPU | AMD Pro Vega 56 | AMD Radeon R9 M370X | Intel HD Graphics 615 |
| Оперативная память | 32 ГБ LPDDR4 2666 МГц | 16 ГБ DDR3L 1600 МГц | 8 ГБ DDR3 1866 МГц |
| Хранилище | SSD 1 ТБ | SSD 512 ГБ | SSD 256 ГБ |
Почему именно эти модели (помимо чисто практического соображения — они были в наличии во время работы над методикой)? Потому что это новейший флагман, не самый новый середнячок и самый слабый вариант из актуальной линейки, то есть три очень показательные конфигурации (каждая — по-своему).
На iMac Pro и MacBook использовался одинаковый софт: операционная система macOS High Sierra 10.13, Final Cut Pro 10.4, а также актуальные версии тестовых приложений. На MacBook Pro была установлена предыдущая версия ОС — Sierra, а также Final Cut Pro 10.2.3, остальные приложения были в тех же версиях, что и на двух других компьютерах.
Видеомонтаж
Начнем с Final Cut Pro X. Видеомонтаж — одна из главных и наиболее показательных профессиональных задач. А пакет Final Cut Pro X — ведущее программное решение. Недавно FCP был обновлен, и начиная с версии 10.4 в нем появилась возможность работы с 360-градусными видео, а также с 8К-видео.
Новые режимы нам очень помогут при тестировании самых производительных конфигураций — например, iMac Pro. Правда, отказываться от тестирования видео разрешения Full HD и 4К мы, разумеется, не будем, просто сократим количество подтестов.
Подтест 1: стабилизация видео 4К
Итак, первая операция — стабилизация видео 4K. Как в год назад, в качестве первого тестового видео мы будем использовать 5-минутный видеоролик 4K 30 fps, снятый на iPhone 7 Plus.
Здесь вся информация о нем, полученная с помощью утилиты Mediainfo.
Открываем FCP, создаем New Event, нажимаем Import Media и выбираем видеофайл в открывшемся окне.
Обратите внимание, что должно быть отмечено Copy to library, но не должно быть отмечено Create proxy media и Create optimized media в настройках справа.
После того, как видео добавилось, перетаскиваем его мышкой на Timeline, нажимаем на него. В левом верхнем углу нажимаем на третью кнопку слева — открывается миниокно Background Tasks. Далее выбираем в Inspector в правой части вкладку Video, отмечаем галочкой квадратик напротив слова Stabilization, не меняя никакие настройки. И тут же запускаем секундомер.
Видим, что в окне Background Tasks начался процесс Transcoding and Analysis. Сразу после его завершения начнется процесс Rendering. И только по окончании Rendering мы останавливаем секундомер и записываем получившееся время.
Как мы видим, по сравнению с прошлым годом интерфейс Final Cut Pro заметно изменился, теперь под окном с видео уже нет отображения процентов выполнения операции, так что приходится использовать Background Tasks. Но — что поделать… Важно во время измерения не трогать мышь и не совершать никаких действий в FCP, иначе процесс будет приостанавливаться, а следовательно, результаты уже не будут корректными.
Подтест 2: финальный рендеринг через Compressor
Для этого нажимаем в Final Cut Pro X вкладку File / Send to Compressor.
Открывается Compressor (разумеется, он должен быть предварительно установлен на компьютере), в нем мы нажимаем на центральную кнопку Add Outputs и в открывшемся меню выбираем Publish to YouTube / Up to 4K. Почему именно его? Потому что получаемый файл — приемлемых размеров, что хорошо для тестирования (не всегда объем SSD бывает максимальным), а кроме того, это вполне понятный «жизненный» сценарий.
После этого осталось нажать кнопку Start Batch в нижнем правом углу окна приложения — и процесс начнется. Никаких изменений по сравнению с прошлой версией методики здесь нет.
Подтест 3: стабилизация видео Full HD
В третьем тесте мы повторяем действия и настройки первого, только с видеороликом разрешения Full HD. Его параметры — ниже.
Поскольку, например, прошлое поколение MacBook 12″ зависало на стабилизации видео 4К, сохранение Full HD в методике пока еще необходимо.
Подтест 4: работа с видео 8К
А вот это уже совершенно новый, хотя и очень простой тест. Теперь мы добавляем в FCP видео 8К H.265. В качестве тестового ролика мы решили использовать вот это видео (по ссылке предлагается его купить, поэтому мы не можем выкладывать его здесь бесплатно). Его параметры в Mediainfo — на скриншоте.
И здесь важный нюанс: кодек H.265 поддерживается только начиная с macOS High Sierra. Соответственно, в случае с компьютерами под управлением более старых ОС этот и следующие тесты с файлом 8К будут недоступны.
Обратим внимание на настройки импорта. При добавлении видео на Timeline появляется окно, предлагающее указать параметры — разрешение и частоту кадров. И там по умолчанию стоит разрешение 4К. Нам же надо выбрать Custom, и тогда автоматически будут подставлены нужные параметры и по разрешению, и по кодеку, и по частоте кадров.
Открыв видео на Timeline, мы переводим его в ч/б, используя предустановленный эффект Black & White. Эта операция слишком быстро выполняется с видео Full HD и даже 4К, но в случае с двухминутным видео 8К создает приличную нагрузку на компьютер. Опять же, с помощью Background Tasks и секундомера замеряем продолжительность операции.
Подтест 5: создание прокси-файла
Вторая операция с тем же видео — создание прокси-файла. Это весьма жизненный сценарий, поскольку с такими тяжелыми видео лучше работать, конечно, через прокси-файл (фактически, дубль вашего файла, но в более низком разрешении; все дальнейшие монтажные операции будут делаться с ним, что сэкономит ресурсы и время, а уже при завершении работы изменения будут применены к исходному файлу). Чтобы сделать прокси-файл, надо кликнуть правой кнопкой мыши на видео в Events Browser, затем нажать Transcode Media, в появившемся окне отметить Proxy Media и нажать ОК. Не забудьте сразу в этот момент включить секундомер и следить за процессом через Background Tasks.
Помимо вышеперечисленного мы планировали еще попробовать экспорт видео 8К через Compressor, но убедились в бесполезности этой операции: с использованием кодека Apple ProRes (а это пока единственный способ сохранить разрешение 8К) процесс получается слишком долгим, чтобы можно было его реально использовать. А остальное, в общем-то, не имеет особого смысла, потому что зачем работать с видео 8К, если потом мы его будем переделывать во что-то худшее?
Итак, у нас получилось 5 подтестов вместо 4 в предыдущей версии методики. При этом мы добавили два новых (с 8К), но убрали режим «Картинка в картинке» как не слишком показательный и, в общем-то, уже не особо нагружающий компьютеры.
| iMac Pro (Late 2017) | MacBook Pro 15″ (Mid 2015) | MacBook 12″ (Mid 2017) | |
|---|---|---|---|
| Тест 1 — стабилизация 4К (мин: сек) | 10:50 | 43:15 | неприменимо |
| Тест 2 — стабилизация Full HD (мин: сек) | 09:01 | 14:55 | неприменимо |
| Тест 3 — финальный рендеринг через Compressor (мин: сек) | 04:48 | 06:17 | неприменимо |
| Тест 4 — добавление эффекта Black & White к видео 8К (мин: сек) | 03:58 | — | неприменимо |
| Тест 5 — создание прокси-файла из видео 8К | 02:30 | — | неприменимо |
Последние два подтеста (работа с 8К-видео) стоит использовать только на действительно производительных компьютерах, то есть это явно не вариант для MacBook 12″ и старых моделей.
Воспроизведение видео 8К
Еще одна любопытная и весьма показательная операция — воспроизведение видео 8К. Да-да, просто воспроизведение. Даже для самых производительных компьютеров это по-прежнему задача не из легких, поэтому вполне показательная для сравнения.
Здесь мы поступаем просто: берем видео 8К, которое использовали для тестов в Final Cut Pro, открываем его в QuickTime Player и смотрим (с тем же успехом его можно воспроизвести и в самом FCP). Даже на iMac Pro были заметны легкие «подмораживания» по ходу воспроизведения, а в начале, с появлением первых кадров собственно съемок (после заставки), тормоза были вполне ощутимыми. То же видео на MacBook 12″ (Mid 2017) смотреть было вообще невозможно.
Кстати, полезно во время воспроизведения следить за температурой CPU и GPU (на скриншоте выше вы видите информационный блок справа). Но об этом мы подробнее расскажем далее.
Программирование
Следующий блок тестов — имитация работы, связанной с программированием: это компиляция и поиск по исходному коду. Здесь все остается без изменений по сравнению с предыдущей версией методики. Но мы будем рады вашим советам, как усовершенствовать эту линию, особенно если вы 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», получая каждый раз нулевой результат. Как показали эксперименты, погрешность получается в районе секунды, что при таких результатах — вполне приемлемо. Важный нюанс: тест лучше проводить после перезагрузки.
В итоге мы имеем таблицу с двумя результатами по каждой модели. Для удобства будем округлять результат до целых секунд.
| iMac Pro (Late 2017) | MacBook Pro 15″ (Mid 2015) | MacBook 12″ (Mid 2017) | |
|---|---|---|---|
| Компиляция Python 2, мин: сек | 0:36 | 0:42 | 1:00 |
| Текстовый поиск по исходному коду, мин: сек | 0:12 | 0:15 | 0:42 |
Здесь уже разброс в результатах не столь показателен, как в предыдущих тестах, но надо понимать, что компиляция и поиск не задействуют GPU, да и эффективность использования CPU здесь под вопросом.
3D-моделирование
В новую версию методики мы решили добавить операции по 3D-моделированию — это еще одна важная область применения высокопроизводительных компьютеров. И здесь мы будем использовать Maxon Cinema 4D Studio R19.
Скачиваем, устанавливаем и открываем программу (можно пользоваться демо-версией). Далее скачиваем файлы .c4d здесь. Из этого набора наиболее показательна сцена Bedroom interior (прямая ссылка на загрузку!). Открываем (File / Open) в скачанном архиве файл no_cm.c4d и видим такую картину.
Далее жмем в верхнем меню самой программы Render / Render To Picture Viewer. И наблюдаем процесс рендеринга 3D-сцены.
По окончании рендеринга мы увидим время в окне History справа — в колонке Render Time. Вот оно нам и нужно.
Кроме того, компания Maxon создала бенчмарк Cinebench, который работает на том же движке и, фактически, имитирует те же операции, что мы выполняли в Cinema 4D.
Его вполне имеет смысл включить в методику, тем более что бенчмарк мультиплатформенный, поэтому результаты в нем вполне можно сравнить с результатами на ПК под управлением Windows.
Ниже — результаты рендеринга в 4D Cinema R19 и Cinebench 15.
| iMac Pro (Late 2017) | MacBook Pro 15″ (Mid 2015) | MacBook 12″ (Mid 2017) | |
|---|---|---|---|
| Maxon Cinema 4D Studio, render time, мин: сек | 2:32 | 9:14 | 43:50 |
| Cinebench R15, OpenGL, fps | 125,6 | 63,0 | 12,1 |
Очень показателен огромный разрыв в скорости рендеринга между всеми тремя устройствами. При этом, что важно, это не синтетический бенчмарк, а реальная задача в популярном приложении для 3D-моделирования.
Итак, наш набор профессиональных приложений позволит оценить производительность основных комплектующих «в реальной жизни» — как вместе, так и с упором отдельно на GPU и CPU. Но помимо этого необходимо воспользоваться синтетическими и игровыми бенчмарками, чтобы сложить максимально полную картину. Об этом мы расскажем во второй части статьи.
Полный текст статьи читайте на iXBT
