Методика тестирования производительности компьютеров под управлением macOS, версия 5.0

Через год после публикации четвертой версии нашей комплексной методики тестирования производительности компьютеров под управлением macOS пришло время ее обновить. За это время компьютеры Apple практически полностью (за исключением разве что Mac Pro) перешли на чипы семейства Apple Silicon, а все основные приложения сторонних производителей обновились и стали универсальными (то есть оптимизированными под архитектуру ARM). Кроме того, стало очевидно, что многие операции для компьютеров Apple слишком легкие. Поэтому мы пересмотрели набор тестовых заданий и бенчмарков, убрав неактуальные и добавив новые.

Напомним базовые принципы нашей методики, неизменные от версии к версии. Во-первых, она комплексная и призвана как можно шире и многограннее изучить аппаратную платформу компьютеров на macOS. Во-вторых, она ориентирована в первую очередь на реальные пользовательские задачи — видеомонтаж, конвертацию видео, 3D-моделирование, программирование, работу с офисными приложениями и так далее. Хотя, конечно, популярные бенчмарки мы тоже используем. В-третьих, методика максимально прозрачная и повторяемая. Это значит, что, прочитав описание методики, все наши результаты вы можете проверить самостоятельно — или протестировать таким же образом свой Мак. По возможности мы публикуем все исходные файлы, а также детально описываем настройки и порядок действий. И последнее: мы всегда открыты к обсуждению методики. Вам кажется, что какая-то операция будет более показательной, удобной и репрезентативной? Пишите в комментариях к данной статье — и, возможно, уже в следующую версию мы включим именно то, что вы советуете.

Добавим, что в сложившейся ситуации с продажей продукции Apple в России выход этого материала многим может показаться грустной иронией или даже издевкой. Однако здесь надо учитывать, что люди, которым Mac нужны для работы — видеомонтажеры, разработчики, графические дизайнеры, — при необходимости найдут способ их купить. Серый рынок никто не отменял. А кроме того, компьютеры Mac остаются актуальны не один год, так что когда официальные поставки возобновятся, статья и полученные по новой методике результаты будут по-прежнему полезны.

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

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

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

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

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

Однако перед началом собственно тестирования необходимо установить утилиту Tunabelly TG Pro для отслеживания нагрева и работы вентиляторов. Как показала практика, именно в Final Cut, с операций в котором начинается наша методика, наиболее показательно поведение компьютера под высокой нагрузкой: нам надо следить, сколько времени пройдет от старта стабилизации до достижения 100-градусной температуры CPU и начала тротлинга.

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

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

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

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

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

Подтест 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 в методике пока еще необходимо, потому что операция весьма популярная, а компьютеры она зачастую нагружает не меньше, чем 4K-видео. Дело в том, что Full HD-видео этого подтеста снято не на устройство Apple, поэтому на компьютерах с M1 / M1 Pro / M1 Max оно обрабатывается куда дольше, чем «понятное» им видео с iPhone.

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

Последняя операция — самая радикальная: финальный рендеринг «сырого» видео 8К через Compressor с использованием четырех кодеков Apple ProRes: 442, Apple ProRes: 442 HQ, Apple ProRes 4444 и Apple ProRes 4444 XQ. Мы берем исходник с профессиональной камеры Red Monstro 8K VV (ссылка, 922,9 МБ). Обратите внимание: камеры Red пишут видео в своем формате — R3D. Чтобы открыть такие файлы в Final Cut Pro X, надо установить плагин отсюда. Важно, что теперь в плагине появилась нативная поддержка Apple Silicon.

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

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

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

Для оценки скорости 3D-моделирования мы будем использовать, как и прежде, Maxon Cinema 4D Studio, который оптимизирован под Apple Silicon. Актуальная версия на момент написания методики — R25.

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

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

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

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

Бенчмарки мультиплатформенные, поэтому результаты в них вполне можно сравнить с результатами на ПК под управлением 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 M1.

По ссылке на GitHub — подробное описание на английском и все материалы. Здесь же пересказываем кратко и по-русски, что надо сделать.

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

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

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

Автор бенчмарка утверждает, что он показывает релевантную производительность модели в Xcode. Внутри архива — фреймворк с 42 популярными библиотеками CocoaPods с более чем 70 зависимостями. И напоминаем, что тест этот появился у нас благодаря читателю с ником Tarik02, приславшему в обсуждении одной из статей ссылку на выложенный Xcode-бенчмарк. Tarik02 молодец, будьте как Tarik02! :)

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

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

Keka — один из самых популярных архиваторов для Mac, оптимизированный под Apple M1. Причем он есть и в Mac App Store (за $2,99), и на официальном сайте в виде DMG. Раньше мы пользовались версией из Mac App Store, но теперь нам представляется более подходящим для «чистого» результата использовать все время один и тот же дистрибутив с официального сайта — чтобы минимизировать последствия возможных обновлений. Благо, разработчик позволяет скачивать и прошлые версии тоже. Поскольку мы использовали 1.2.3, пусть она и будет в дальнейшем. Эта версия уже оптимизирована для M1.

Для тестов используем папку объемом 10,15 ГБ, включающую видео, фото и прочий контент. Сжимаем ее алгоритмом 7-Zip, на режиме «Обычный». В общем, с настройками по умолчанию.

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

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

Бесплатное приложение для конвертации видео HandBrake проявило себя как один из самых простых, но в то же время надежных и полезных инструментов прошлой версии нашей методики. На момент ее публикации мы использовали сборку, еще не оптимизированную для Apple Silicon. Позже появился релиз 1.4.2, уже Universal, но поскольку часть устройств тестировалась на 1.3.3, нам пришлось задействовать обе сборки.

Добавим, что на сайте разработчика доступны не только новые, но и старые версии, за что низкий поклон.

Но, так или иначе, теперь уже нет смысла использовать 1.3.3, а 1.4.2 мы заменим на более свежую 1.5.1. В плане производительности никаких отличий от 1.4.2 у нее нет, в чем мы убедились, протестировав одни и те же компьютеры и на 1.4.2, и на 1.5.1. Поэтому сравнению результатов это не мешает.

Итак, теперь в таблице результатов по HandBrake мы будем указывать значения для 1.4.2 или 1.5.1, не конкретизируя версию, а все новые модели будем тестировать на 1.5.1, вплоть до выхода следующей версии методики.

Внимательные читатели, впрочем, могут заметить, что на стартовом экране появился дополнительный пункт Passthru Common Metadata, и по умолчанию на нем стоит галочка. Но на результаты тестирования активность или неактивность данного пункта не влияют. Так что можно галочку не убирать и тестировать с настройками по умолчанию.

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

Пакетная обработка фотографий

Читатели давно просили нас включить какие-то операции по работе с фотографиями. И мы, наконец, разработали такой тест, задействовав приложение PhotoBulk (Eltima Software), ориентированное на пакетную обработку изображений. Итак, что мы будем делать?

Загрузим в приложение папку с 400 фотографиями HEIC, сделанными на iPhone 11 Pro Max, общим весом в 1 ГБ. Ссылку на папку не даем, поскольку среди фотографий есть личные, но вы можете с тем же успехом создать собственный аналогичный массив. При таком количестве и формате — 400 снимков HEIC — его размер вряд ли будет сколько-нибудь существенно отличаться.

Итак, в PhotoBulk жмем File / Open, указываем папку с фотографиями и в меню слева отмечаем галочками первые четыре пункта: Watermark, Resise, Optimize и Format.

Watermark — нанесение водяного знака на фотографии. Мы используем для этого логотип iXBT, его можно скачать здесь. Resize — изменение размера. Значение By width («по ширине») заменяем на Percentage, где ставим 70%. В Optimize (оптимизация размера файла) оставляем значение по умолчанию — Opt, в JPEG Quality — аналогично (там стоит 80%). И жмем Start. Продолжительность операции измеряем секундомером.

Обратите внимание, во сколько раз MacBook Pro 2021 обогнал топовую модель 2017-го. Более чем в девять! Хотя прошло всего четыре года.

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

И еще один тест, добавленный по просьбам читателей: открытие большого (40,7 МБ) XLSM-файла в Numbers. Он фигурировал и в предыдущей версии методики, так что не будем расписывать его полезность — просто напомним порядок действий.

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

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

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

Вот результаты нескольких тестовых моделей. Парадокс, но у MacBook Pro 14" на базе M1 Pro результат оказался хуже, чем у MacBook Air 13" на Apple M1. Видимо, дело не только в производительности как таковой, но и, например, в работе с оперативной памятью.

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

Бенчмарки

Здесь главное изменение — в том, что нам пришлось убрать Geeks 3D GPU Test, поскольку на моделях с Apple M1 он ведет себя просто некорректно, да вдобавок он давным-давно не обновлялся, поэтому просто некорректно его использовать с моделями на базе Apple Silicon. Однако вместо него мы возвращаем GFXBench Metal. Некоторое время назад он вел себя не совсем стабильно, не мог соединиться с сервером, но теперь, видимо, проблема исправлена (о чем и сообщает описание обновления в Mac App Store), так что нет оснований не пользоваться им.

JetStream 2

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

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

Geekbench 5

Разумеется, не обойтись и без Geekbench — пожалуй, самого популярного бенчмарка для macOS. Мы использовали его и раньше, но опыт показал, что нет смысла тестировать GPU в обоих подтестах — OpenCL и Metal. Результаты в них всегда отличаются незначительно, и разница примерно одинакова, так что для облегчения методики оставляем только OpenCL.

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

GFX Benchmark Metal

Для тестирования производительности в играх мы снова, как и два года назад, будем использовать GFX Bench Metal из Mac App Store. Он основан на OpenGL и ориентирован именно на тестирование GPU, причем с задействованием технологии Apple Metal (как видно из названия). Мы использовали его раньше и считаем необходимым включить этот тест в новую версию методики.

При этом мы включаем только Offscreen-подтесты — в них разрешение одно и то же, фиксированное. В тестах Onscreen же разрешение рендеринга соответствует разрешению экрана, поэтому сравнение, например, iMac и MacBook будет некорректным. Кроме того, в Onscreen-тестах T-Rex и Manhattan стоит ограничение в 60 fps, так что набрать больше нельзя физически.

BlackMagic Disk Speed

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

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

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

AmorphousDiskMark

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

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

Выводы

Нам не пришлось обновлять методику радикально, но все-таки ряд бенчмарков и подтестов ушли, а вместо них появились другие. Прежде всего, добавилась пакетная обработка фотографий, о чем читатели давно просили. Главное же — мы вовсе отказались от бенчмарков, не имеющих оптимизации под Apple Silicon. Таким образом, методика теперь состоит исключительно из Universal-приложений.

Учитывая, что Apple практически полностью перешла на ARM-процессоры, нет оснований сохранять необновленные приложения и нам.

Впрочем, мы всегда открыты к предложениям и замечаниям читателей, так что пишите, если у вас есть аргументированные и конкретные идеи включить в методику что-то еще!