Методика тестирования производительности компьютеров под управлением macOS, версия 4.0: добавляем тесты под Apple M1

Не так уж много времени прошло с момента публикации третьей версии нашей комплексной методики тестирования производительности компьютеров под управлением macOS, как стала очевидна необходимость её обновления. Дело в том, что в 2020 году произошло важнейшее событие (нет, не связанное с пандемией): после многолетнего использования процессоров Intel компания Apple выпустила компьютеры на собственных чипах и перешла с архитектуры x86 на ARM. Соответственно, часть наших тестов устарела, а им на смену пришли приложения, оптимизированные для Apple M1.

Как и в прежних версиях, общий «каркас» методики останется прежним: это ряд разработанных нами сценариев работы в реальных приложениях. Однако мы существенно расширили список этих приложений, охватив почти все типичные задачи пользователя. Наряду с операциями в Final Cut Pro X, Compressor, Maxon Cinema 4D и Pro Logic X мы добавили компиляцию в Xcode, открытие «тяжелого» файла в Numbers, конвертацию видеофайла в HandBrake и архивацию в Keka. Разумеется, остались и синтетические бенчмарки. Подробности — в нашем материале.

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

Тестовый стенд

После описания каждого из тестов мы приведем результаты его выполнения теми компьютерами, которые были у нас во время подготовки данного материала. В большинстве случаев в таблицах будут фигурировать четыре устройства: один из самых мощных компьютеров Apple на базе Intel — iMac 27″ (Mid 2020) в топовой конфигурации, старый, уже неактуальный MacBook Pro 15″, который, однако, на момент выпуска был настоящим флагманом, а также две модели на Apple M1 — MacBook Air (Late 2020) и MacBook Pro 13″ (Late 2020), самая мощная и самая слабая. Вот их основные параметры, имеющие отношение к производительности.

На всех устройствах была установлена macOS Big Sur, версии конкретных приложений указаны ниже.

Увы, в некоторых совсем новых тестах нам придется ограничиться тремя моделями — одной на Apple M1 и двумя на Intel, поскольку только они и были в наличии.

Подчеркнем, что в описании методики тестирования мы не ставим задачу сравнить устройства между собой, поскольку это устройства совершенно разного класса и назначения. Но тесты как раз и должны убедительно показывать разницу между ними.

Видеомонтаж (Final Cut Pro X и Compressor)

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

Подтест 1: стабилизация видео 4К

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

Здесь вся информация о ролике, полученная с помощью утилиты Mediainfo. Само видео можно загрузить здесь.

Открываем FCP, создаем New Event, нажимаем Import Media и выбираем видеофайл в открывшемся окне.

Файл должен лежать на рабочем столе. И при импорте надо отметить Leave files in place, чтобы избежать копирования файла в медиатеку Final Cut и снижения производительности из-за этого.

После того, как видео добавилось, создаем новый проект и видим файл на Timeline. Нажимаем на него, в левом верхнем углу нажимаем на третью кнопку слева — открывается миниокно Background Tasks. Далее выбираем в Inspector в правой части вкладку Video, отмечаем галочкой Stabilization, не меняя никакие настройки. И тут же запускаем секундомер.

Видим, что в окне Background Tasks начался процесс Transcoding and Analysis. Сразу после его завершения начнется процесс Rendering. И только по окончании Rendering мы останавливаем секундомер и записываем получившееся время.

Интерфейс Final Cut Pro за последние годы практически не изменился, поэтому никаких поправок нет. Напоминаем, что во время измерения важно не трогать мышь и не совершать никаких действий в FCP, иначе процесс будет приостанавливаться, а следовательно, результаты уже не будут корректными.

Подтест 2: финальный рендеринг через Compressor

Для этого выбираем в Final Cut Pro X вкладку File / Send to Compressor.

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

После этого осталось нажать кнопку Start Batch в нижнем правом углу окна приложения — и процесс начнется. Мы же в момент нажатия Start Batch включаем секундомер. Никаких изменений по сравнению с прошлой версией методики здесь нет.

Подтест 3: стабилизация видео Full HD

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

Сохранение Full HD в методике пока еще необходимо, потому что и операция весьма популярная, и для слабых моделей это может быть оптимальный вариант. Кроме того, как показали тесты моделей на Apple M1, поскольку этот файл снят не на устройство Apple, он вызывает куда больше сложностей у компьютеров, чем даже 4К-файл с iPhone.

Подтест 4: работа с видео 8К

Далее мы добавляем в FCPX видео 8К H.265. В качестве тестового ролика мы решили использовать вот это видео. Раньше его можно было купить за небольшую сумму, теперь уже нельзя, но на YouTube ролик доступен бесплатно. Нам важен исходный файл, поэтому приводим его здесь. Его параметры — на скриншоте Mediainfo.

Обратим внимание на настройки импорта. При добавлении видео на Timeline появляется окно, предлагающее указать параметры — разрешение и частоту кадров. Раньше там по умолчанию стояло разрешение 4К и надо было выбирать Custom, чтобы получить верные параметры. Теперь же все происходит автоматически.

Открыв видео на Timeline, мы создаем прокси-файл. Это весьма жизненный сценарий, поскольку с такими тяжелыми видео лучше, конечно, работать через прокси-файл (фактически, дубль вашего файла, но в более низком разрешении; все дальнейшие монтажные операции будут делаться с ним, что сэкономит ресурсы и время, а уже при завершении работы изменения будут применены к исходному файлу). Чтобы сделать прокси-файл, надо кликнуть правой кнопкой мыши на видео в Events Browser, затем нажать Transcode Media, в появившемся окне отметить Proxy Media и нажать ОК. Не забудьте сразу в этот момент включить секундомер и следить за процессом через Background Tasks.

Подтест 5: экспорт 8К через Compressor в несколько файлов

Последняя операция — самая радикальная: финальный рендеринг видео 8К через Compressor с использованием четырех кодеков Apple ProRes: 442, Apple ProRes: 442 HQ, Apple ProRes 4444 и Apple ProRes 4444 XQ. Раньше мы отмечали, что она подойдет только для самых мощных компьютеров, но линейка устройств на Apple M1 показала, что теперь этот тест по зубам даже MacBook Air. Так что в новой версии методики мы считаем его одним из базовых.

Но для этого теста нам понадобится другой файл — тот, что в предыдущем подтесте, слишком большой для наших целей. Кроме того, это уже смонтированное видео. Поэтому мы берем исходник с профессиональной камеры Red Monstro 8K VV (прямая ссылка, 922,9 МБ). Обратите внимание: камеры Red пишут видео в своем формате — R3D. Чтобы открыть такие файлы в Final Cut Pro X, надо установить плагин отсюда.

После установки плагина импортируем файл в Final Cut, причем в настройках импорта указываем в качестве кодека для рендеринга Uncompressed 10-bit 4:2:2.

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

Пояснение в разделе поддержки на сайте Apple гласит:

The number of available Compressor instances is determined by your computer’s cores and memory. After meeting the minimum system requirement (four cores and 2 GB of memory), you can add one additional instance for every additional four cores and 2 GB of memory.

Под ядрами (cores) в данном случае понимаются потоки. Например, для iMac 27″ это четыре параллельных процесса, следовательно, файл будет одновременно рендериться во все эти форматы. В случае с моделями на Apple M1 возможны лишь два параллельных процесса. То есть сначала компьютер выведет два файла, затем займется следующими двумя.

Если же мы не сделаем эту настройку и запустим рендеринг файла с помощью четырех кодеков, то файлы будут кодироваться по очереди — пока не завершится процесс с первым, не запустится рендеринг второго, и так далее. Нам же здесь важно именно максимально загрузить железо. Во время теста на iMac 27″ и Mac Pro окно Compressor выглядит следующим образом.

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

3D-моделирование (Maxon Cinema 4D Studio и Cinebench)

В операциях по 3D-моделированию мы будем использовать, как и прежде, Maxon Cinema 4D Studio, который теперь оптимизирован под Apple M1.

Скачиваем, устанавливаем и открываем программу (можно пользоваться демо-версией). Далее скачиваем файл no_cm.c4d. Открываем его в Cinema 4D Studio (File / Open) и видим такую картину.

Далее жмем в верхнем меню самой программы Render / Render To Picture Viewer. И наблюдаем процесс рендеринга 3D-сцены.

По окончании рендеринга мы увидим время в окне History справа — в колонке Render Time. Вот оно нам и нужно.

Кроме того, у компании Maxon есть бенчмарк Cinebench, который работает на том же движке и, фактически, имитирует те же операции, что мы выполняли в Cinema 4D. Версия R23 оптимизирована под Apple M1. Поэтому мы заменяем ею версию R20, которая фигурировала в прошлой версии методики, но сохраняем версию R15, где есть GPU-тест (OpenGL). Вот здесь можно скачать Cinebench R15.

Бенчмарки мультиплатформенные, поэтому результаты в них вполне можно сравнить с результатами на ПК под управлением Windows.

Важный момент: в Cinebench R23 тест идет в течение 10 минут, делая такое количество проходов, которое возможно за это время. Это позволяет проверить, как ведет себя компьютер при длительной нагрузке — не перегревается ли, не сбрасывает ли частоты.

Монтаж аудио (Apple Pro Logic X)

Тест, который появился в прошлой версии методики, мы решили оптимизировать. Дело в том, что он выполнялся слишком быстро, и, вдобавок, после обновления в нем используется новый демо-проект — «Ocean Eyes» Билли Айлиш. Поэтому, открыв этот демо-проект, мы жмем на Edit / Repeat...

После чего выбираем Multiple, и в открывшемся окошке ставим количество копий — 9.

Таким образом, на таймлайне у нас теперь та же песня, но удесятеренная. Выглядит это следующим образом:

Далее мы выделяем все это (Cmd+A), в меню Files выбираем Bounce project or section и в открывшемся окне отмечаем галочками только верхний формат: PCM. Другие форматы нам погоды не делают. Нормализация отключена (Off). И запускаем процесс, включая секундомер.

В итоге у нас появится аудиофайл .aif. Время на его создание — и есть результат теста (округляем его до секунд). Вот что получилось с нашими моделями.

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

Программирование (Xcode)

Читатели давно просили нас добавить какие-нибудь операции в Xcode, основном инструменте Apple для разработки приложений подо все операционные системы этой компании, включая iOS. Но прежде мы не могли найти удобный подходящий способ это реализовать.

Теперь же благодаря читателю с ником Tarik02, приславшего в обсуждении статьи про MacBook Air ссылку на выложенный Xcode-бенчмарк на Github, всё, наконец, получилось. Вот эта ссылка. По ней — подробное описание на английском и все материалы. Здесь же пересказываем кратко и по-русски, что надо сделать.

Установить Xcode и позволить ему загрузить все необходимое (это происходит автоматически), скачать XcodeBenchmark здесь. Распаковать архив. Открыть Терминал. Ввести cd (с пробелом), затем перетащить в окно папку, получившуюся после распаковки архива, и нажать Enter. После этого набрать в Терминале sh benchmark.sh и снова нажать Enter. Бенчмарк начнет выполняться, результат будет выглядеть следующим образом:

Собственно, нужные нам значения видны в строчках Started и Ended. Считаем разницу, записываем результат.

Обратим внимание, что MacBook Air на Apple M1 практически догнал в этом тесте iMac 27″. Поразительно!

Автор бенчмарка утверждает, что он показывает релевантную производительность модели в Xcode. Внутри архива — фреймворк с 42 популярными библиотеками CocoaPods с более чем 70 зависимостями. Заметим, что тест действительно сильно нагружает компьютер.

Архивация (Keka)

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

Keka — один из самых популярных архиваторов для Mac, оптимизированный под Apple M1. Причем он есть и в Mac App Store (за 229 рублей или $2,99), и на официальном сайте в виде DMG. Мы будем для удобства пользоваться версией из Mac App Store до тех пор, пока она не обновится. Для тестов используем папку объемом 10,15 ГБ, включающую видео, фото и прочий контент. Сжимаем ее алгоритмом 7-Zip, на режиме «Обычный». В общем, с настройками по умолчанию.

В итоге получаем архив, а время его создания, измеряемое с помощью секундомера — и есть результат теста.

Кодирование видео (HandBrake)

Следующая «реальная» задача — кодирование видео с помощью HandBrake 1.3.3. В отличие от всех вышеописанных тестов, видеокодеры этой оболочки не имеют никакой оптимизации под Apple M1, поэтому данный тест показателен именно как пример работы Intel-программ на компьютерах Apple.

Мы использовали тот же видеофайл 4К, который применяли в Final Cut Pro X. А операцией, которую мы производили в HandBrake, была конвертация видео в Full HD со стандартными настройками.

Время создания файла замеряем секундомером, результаты следующие:

Офисные приложения (Numbers)

И еще один тест, добавленный по просьбам читателей: открытие большого (40,7 МБ) XLSM-файла в Numbers. Изначально мы хотели сделать тест в Excel, но столкнулись с рядом проблем. В частности, найденные нами файлы-бенчмарки некорректно работали под macOS (как оказалось, от операционной системы тут многое зависит) и в актуальной версии MS Office. Поэтому было решено пойти по самому простому пути: замерить время, которое занимает открытие файла с макросами в Numbers. Понятно, что Numbers — куда менее популярная и востребованная штука, чем Excel, но с точки зрения абстрактной производительности офисных приложений — вполне показательная.

Итак, скачиваем файл, открываем его с помощью Numbers. Тут же запускаем секундомер. Довольно долго видим такое окошко:

Потом, наконец, появляется собственно таблица, но в ней далеко не все столбцы заполнены, а внизу написано «Вычисление...» и крутится значок активного процесса.

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

Вот результаты нескольких тестовых моделей. Здесь MacBook Air на Apple M1 не только догнал, но и существенно обогнал iMac 27″!

Disclaimer: Дорогие читатели! Если вы считаете, что этот тест не очень показателен, не очень полезен, и знаете, как сделать тестирование в офисных приложениях более наглядным — напишите нам в комментариях и приложите ссылку на корректный файл. Мы всегда рады вашим пожеланиям, если они конструктивные и конкретные. То есть не просто «возьмите какой-нибудь большой файл с макросами», а «вот файл, надо его открыть с помощью Excel, нажать на кнопку такую-то и получить такой-то результат». Если совместными усилиями удастся разработать такой тест, мы обновим методику и укажем благодарности тем, кто принял в этом непосредственное деятельное участие.

Бенчмарки

Здесь, по большому счету, никаких изменений по сравнению с предыдущей версией методики нет. Разве что мы убрали один подтест Geeks3D GPU Test.

JetStream 2

Начнем с браузерного JavaScript-бенчмарка JetStream 2. В качестве браузера использовался Safari. Результаты округляем до целого числа.

Остальные браузерные бенчмарки, которые мы используем при тестировании мобильных устройств на iOS/Android, здесь запускать не имеет смысла, потому что мощи «взрослых» устройств Apple достаточно для того, чтобы не беспокоиться о скорости работы движка JavaScript в браузере. Поэтому мы приводим показатели лишь одного такого бенчмарка JetStream 2. Ну, и для сопоставления компьютеров и ноутбуков со смартфонами и планшетами, если кому интересно.

Geekbench 5

Разумеется, не обойтись и без Geekbench — пожалуй, самого популярного бенчмарка для macOS. В пятой версии, которую мы использовали и в 2020 году, есть тест CPU и тест GPU (Compute Benchmark) на основе OpenCL и Metal. Вот здесь детально объясняется, где, как и зачем может применяться OpenCL при разработке приложений для macOS. Что же касается Metal, то это основной инструментарий для разработки игр под macOS.

Важный нюанс: в подтесте Compute можно указать, какой GPU будет задействоваться, если в компьютере есть и интегрированная, и дискретная графика. Мы в таком случае будем использовать только дискретную графику.

Geeks 3D GPU Test

Переходим к тестированию графической производительности в бенчмарках. Здесь мы используем уже проверенный нами бесплатный, мультиплатформенный, компактный и лишенный привязки к интернету Geeks 3D GPU Test. Судя по информации в файле, он тоже довольно давно не обновлялся, но из-за простоты и отсутствия привязки к «внешнему миру» бенчмарк вполне может использоваться и сегодня. Однако ранее использовавшийся нами подтест FurMark продемонстрировал странные, не вполне корректные результаты на моделях с Apple M1. Поэтому мы его исключаем и ограничиваемся TessMark, который, к тому же, более соответствует реальным игровым проектам.

Итак, скачиваем бесплатный архив, в нем видим несколько файлов. Из них нас интересует GpuTest_GUI. Запускаем его, видим такой очень простой интерфейс.

Вверху можно выбрать тест. Среди них есть и TessMark. Его-то мы и запустим в версии х64, нажав на кнопку Run benchmark. Разрешение выставим на 1920×1080, а антиалиаcинг поставим на 8× MSAA.

Выполняемый тест выглядит так:

Результаты тестирований появляются через минуту-другую и выглядят следующим образом:

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

Что ж, разрыв между устройствами соответствует ожиданиям, но главное — запас по сложности достаточно велик, чтобы тестировать даже самые мощные модели, типа Mac Pro. Плюс к этому, TessMark мы используем для тестирования автономной работы ноутбуков — это хорошая имитация режима 3D-игр. При запуске надо выбирать не Run benchmark, как с тестированием производительности, а Run stress test. Тогда сцена будет крутиться просто нон-стоп.

Civilization VI Benchmark

Как и в прежней версии методики, для тестирования производительности в реальных играх воспользуемся встроенным бенчмарком Civilization VI. Для этого в главном меню игры выбираем Benchmark, и он автоматически стартует.

Суть его работы очень проста: демонстрируется сцена, измеряется FPS. По итогам бенчмарк выдает два значения: Average Frame Time (среднее время отрисовки кадра) и 99th Percentile (время отрисовки, которое обгоняют 99% кадров — т. е. отброшен результат отрисовки 1% кадров с самой низкой скоростью, чтобы избавиться от случайных тормозов). Оба значения выводятся в миллисекундах, однако мы решили переводить миллисекунды в более привычные FPS. Делается это просто: делим 1000 (поскольку в 1 секунде 1000 мс) на полученное значение и записываем результат. В таблице указываем его с округлением до одной десятой. Соответственно, чем больше FPS, тем лучше.

Однако здесь встает вопрос, какие настройки использовать. Опыт применения бенчмарка показал, что самое правильное — использовать настройки по умолчанию. Это дает представление о реальном игровом комфорте в одном из самых требовательных и известных проектов.

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

BlackMagic Disk Speed

Если перечисленные выше бенчмарки помогают нам оценить производительность CPU и GPU, то BlackMagic Disk Speed (доступен в Mac App Store) ориентирован на тестирование накопителя — скорости чтения и записи файлов.

Это очень простое приложение, в котором можно выбирать объем данных (от 1 до 5 ГБ), с помощью которых будет тестироваться быстродействие накопителя, но больше никаких настроек нет, так что остается только нажать кнопку Speed Test Start и запустить процесс.

Вот результаты наших «конкурсантов».

AmorphousDiskMark

Также, по совету наших читателей, мы добавляем тест скорости чтения/записи в программе AmorphousDiskMark 3.1, Mac-аналоге известной утилиты CrystalDiskMark. Так выглядят результаты:

Вот результаты наших компьютеров:

Измерение нагрева CPU и GPU

И последнее, без чего не обойтись при тестировании компьютеров и особенно ноутбуков: измерение нагрева. Зачастую именно недостаточно хорошее охлаждение становится причиной падения производительности и дискомфорта при использовании. Для тестирования нагрева мы, как и прежде, используем утилиту Tunabelly TG Pro.

Она демонстрирует нагрев всех основных компонентов, включая каждое ядро CPU и GPU в отдельности, а также умеет создавать лог и отображать температуру в режиме реального времени.

Tunabelly TG Pro имеет смысл использовать во время любого длительного тестирования, предполагающего максимальную нагрузку — например, в операциях видеомонтажа.

Также мы можем в случае необходимости измерить внешний нагрев корпуса и шум. Это может быть целесообразно в тех случаях, когда они явно выходят за рамки комфортных значений. Описание и примеры того, как это делается, можно найти в статьях из раздела «Ноутбуки и планшеты» (например, здесь).

Выводы

Итак, мы оптимизировали методику тестирования компьютеров под macOS в соответствии с реалиями 2021 года: акцент теперь на универсальных приложениях (то есть оптимизированных для Apple M1). К тому же, мы серьезно расширили блок профессиональных сценариев: появились операции в пакете программирования Xcode, редакторе таблиц Numbers, видеокодировщике HandBrake и архиваторе Keka. Как и прежде, мы сохраняем преемственность по отношению к предыдущей версии методики, поэтому результаты тестирования новых моделей вполне можно сравнить и со старыми.

Все описанные тесты вы можете проделать на своих моделях, сравнив результаты с полученными нами. То есть методика идеально прозрачна и повторяема. Но, как и прежде, мы будем благодарны вам за любые советы и предложения новых тестов — разумеется, желательно аргументировать, что́ они дадут такого, чего не могут дать описанные нами, и чем они лучше.