Методика тестирования производительности компьютеров под управлением 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 года, который, однако, на момент выпуска был флагманским устройством. Вот их основные параметры, имеющие отношение к производительности.
| MacBook Pro 14″ (Late 2021) | iMac 27″ (Mid 2020) | MacBook Pro 15″ (Mid 2017) | |
|---|---|---|---|
| Процессор (CPU), количество ядер CPU, частота | Apple M1 Pro (Apple Silicon), 8 ядер (6 высокопроизводительных и 2 энергоэффективных), 3,2 ГГц | Intel Core i9-10910 (Comet Lake), 10 ядер, 20 потоков, 3,6 ГГц, Turbo Boost до 5,0 ГГц | Intel Core i7-7820HQ (Kaby Lake), 4 ядра, 8 потоков, 2,9 ГГц, Turbo Boost до 3,9 ГГц |
| GPU | Apple M1 Pro, 16 ядер | AMD Radeon Pro 5700 XT c 16 ГБ памяти GDDR6 | AMD Radeon Pro 560 |
| Оперативная память | 16 ГБ объединенной памяти | 64 ГБ LPDDR4 2666 МГц | 16 ГБ 2133 МГц LPDDR3 |
На всех устройствах была установлена 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 выглядит следующим образом.
Итак, у нас получилось четыре подтеста. В предыдущей версии методики их было пять, но мы убрали создание прокси-файла. Современные конфигурации справляются с этой задачей слишком быстро, поэтому смысл теряется. Результаты для тестовых систем следующие.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | |
|---|---|---|---|
| Тест 1 — стабилизация 4К (мин:сек) | 1:25 | 7:23 | 21:20 |
| Тест 2 — финальный рендеринг 4К через Compressor (мин:сек) | 6:43 | 5:11 | 6:56 |
| Тест 3 — стабилизация Full HD (мин:сек) | 6:11 | 7:32 | 19:23 |
| Тест 4 — экспорт 8К в четыре формата Apple ProRes через Compressor (мин:сек) | 1:55 | 1:45 | неприменимо |
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.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | |
|---|---|---|---|
| Maxon Cinema 4D Studio R25, render time, мин:сек (меньше — лучше) | 1:34 | 1:38 | 5:01 |
| Cinebench R23, многоядерный режим, pts, (больше — лучше) | 8568 | 14273 | 4067 |
Обратите внимание: в Cinebench R23 тест идет в течение 10 минут, делая такое количество проходов, которое возможно за это время. Это позволяет проверить, как ведет себя компьютер при длительной нагрузке — не перегревается ли, не сбрасывает ли частоты.
Монтаж аудио (Apple Pro Logic X)
По сравнению с прошлой версией методики этот тест остается у нас неизменным, но больше у нас нет необходимости для сохранения преемственности результатов сохранять результаты ранее использованного демо-проекта. Теперь мы используем только «Ocean Eyes» Билли Айлиш.
Напомним последовательность действий. После установки приложения загружаем его, затем, открыв жмем на Edit / Repeat.
После чего выбираем Multiple, и в открывшемся окошке ставим количество копий — 9.
Таким образом, на таймлайне у нас теперь та же песня, но удесятеренная. Выглядит это следующим образом:
Далее мы выделяем все это (Cmd+A), в меню Files выбираем Bounce project or section и в открывшемся окне отмечаем галочками только верхний формат: PCM. Другие форматы нам погоды не делают. Нормализация отключена (Off). И запускаем процесс, включая секундомер.
В итоге у нас появится аудиофайл .aif. Время на его создание — и есть результат теста (округляем его до секунд). Вот что получилось с нашими моделями.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | |
|---|---|---|---|
| Apple Pro Logic X bounce (мин:сек) | 4:14 | 4:22 | 7:44 |
Удлинив время выполнения теста, мы снизили влияние погрешности измерений на восприятие результатов (погрешность в пару секунд теперь не столь критична) и добились более долгой равномерной нагрузки.
Программирование (Xcode)
Сохраняем неизменным мы и тест в среде Xcode, хотя уже в следующей версии методики придется, видимо, заменить его чем-то другим — уж очень быстро идет процесс даже на Apple M1.
По ссылке на GitHub — подробное описание на английском и все материалы. Здесь же пересказываем кратко и по-русски, что надо сделать.
Установить Xcode и позволить ему загрузить все необходимое (это происходит автоматически), скачать XcodeBenchmark здесь. Распаковать архив. Открыть Терминал. Ввести cd (с пробелом), затем перетащить в окно папку, получившуюся после распаковки архива, и нажать Enter. После этого набрать в Терминале sh benchmark.sh и снова нажать Enter. Бенчмарк начнет выполняться, результат будет выглядеть следующим образом:
Собственно, нужные нам значения видны в строчках Started и Ended. Считаем разницу, записываем результат.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|
| Xcode, бенчмарк (мин:сек) | 1:42 | 2:19 | 5:37 | 2:25 |
Обратим внимание, что 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, на режиме «Обычный». В общем, с настройками по умолчанию.
В итоге получаем архив, а время его создания, измеряемое с помощью секундомера — и есть результат теста.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Pro 13″ (Late 2020), Apple M1 | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|---|
| Keka 1.2.3 | 3 минуты 20 секунд | 4 минуты 21 секунда | 10 минут 49 секунд | 5 минут 30 секунд | 5 минут 37 секунд |
Кодирование видео (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, и по умолчанию на нем стоит галочка. Но на результаты тестирования активность или неактивность данного пункта не влияют. Так что можно галочку не убирать и тестировать с настройками по умолчанию.
Время создания файла замеряем секундомером, результаты следующие:
| iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Pro 13″ (Late 2020), Apple M1 | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|
| HandBrake (конвертация файла, мин:сек) | 3:22 | 10:17 | 9:02 | 9:38 |
Пакетная обработка фотографий
Читатели давно просили нас включить какие-то операции по работе с фотографиями. И мы, наконец, разработали такой тест, задействовав приложение 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 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | |
|---|---|---|---|
| PhotoBulk (добавление водяного знака на 400 фотографий, мин:сек) | 00:29 | 01:35 | 04:30 |
Обратите внимание, во сколько раз MacBook Pro 2021 обогнал топовую модель 2017-го. Более чем в девять! Хотя прошло всего четыре года.
Офисные приложения (Numbers)
И еще один тест, добавленный по просьбам читателей: открытие большого (40,7 МБ) XLSM-файла в Numbers. Он фигурировал и в предыдущей версии методики, так что не будем расписывать его полезность — просто напомним порядок действий.
Скачиваем файл, открываем его с помощью Numbers. Тут же запускаем секундомер. Довольно долго видим такое окошко:
Потом, наконец, появляется собственно таблица, но в ней далеко не все столбцы заполнены, а внизу написано «Вычисление. » и крутится значок активного процесса.
И только когда этот значок пропадает и последний столбец заполняется цифрами, мы останавливаем секундомер и записываем полученное значение.
Вот результаты нескольких тестовых моделей. Парадокс, но у MacBook Pro 14" на базе M1 Pro результат оказался хуже, чем у MacBook Air 13" на Apple M1. Видимо, дело не только в производительности как таковой, но и, например, в работе с оперативной памятью.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|
| Numbers (открытие файла, мин:сек) | 2:52 | 3:46 | 5:22 | 2:05 |
Disclaimer: Дорогие читатели! Если вы считаете, что этот тест не очень показателен, не очень полезен, и знаете, как сделать тестирование в офисных приложениях более наглядным — напишите нам в комментариях и приложите ссылку на корректный файл. Мы всегда рады вашим пожеланиям, если они конструктивные и конкретные. То есть не просто «возьмите какой-нибудь большой файл с макросами», а «вот файл, надо его открыть с помощью Excel, нажать на кнопку такую-то и получить такой-то результат». Если совместными усилиями удастся разработать такой тест, мы обновим методику и укажем благодарности тем, кто принял в этом непосредственное деятельное участие.
Бенчмарки
Здесь главное изменение — в том, что нам пришлось убрать Geeks 3D GPU Test, поскольку на моделях с Apple M1 он ведет себя просто некорректно, да вдобавок он давным-давно не обновлялся, поэтому просто некорректно его использовать с моделями на базе Apple Silicon. Однако вместо него мы возвращаем GFXBench Metal. Некоторое время назад он вел себя не совсем стабильно, не мог соединиться с сервером, но теперь, видимо, проблема исправлена (о чем и сообщает описание обновления в Mac App Store), так что нет оснований не пользоваться им.
JetStream 2
Начинаем, как и раньше, с браузерного JavaScript-бенчмарка JetStream 2. В качестве браузера используем везде Safari. Результаты округляем до целого числа.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Pro 13″ (Late 2020), Apple M1 | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|---|
| Баллы (больше — лучше) | 208 | 206 | 140 | 175 | 174 |
Остальные браузерные бенчмарки, которые мы используем при тестировании мобильных устройств на iOS/Android, здесь запускать не имеет смысла, потому что мощи «взрослых» устройств Apple достаточно для того, чтобы не беспокоиться о скорости работы движка JavaScript в браузере. Поэтому мы приводим показатели лишь одного такого бенчмарка JetStream 2.
Geekbench 5
Разумеется, не обойтись и без Geekbench — пожалуй, самого популярного бенчмарка для macOS. Мы использовали его и раньше, но опыт показал, что нет смысла тестировать GPU в обоих подтестах — OpenCL и Metal. Результаты в них всегда отличаются незначительно, и разница примерно одинакова, так что для облегчения методики оставляем только OpenCL.
Важный нюанс: в подтесте Compute можно указать, какой GPU будет задействоваться, если в компьютере есть и интегрированная, и дискретная графика. Мы в таком случае будем использовать только дискретную графику.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Pro 13″ (Late 2020), Apple M1 | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|---|
| Одноядерный 64-битный режим (больше — лучше) | 1763 | 1291 | 936 | 1728 | 1736 |
| Многоядерный 64-битный режим (больше — лучше) | 9975 | 10172 | 3696 | 7557 | 7560 |
| Compute OpenCL (больше — лучше) | 34335 | 56181 | 12877 | 19238 | 18388 |
GFX Benchmark Metal
Для тестирования производительности в играх мы снова, как и два года назад, будем использовать GFX Bench Metal из Mac App Store. Он основан на OpenGL и ориентирован именно на тестирование GPU, причем с задействованием технологии Apple Metal (как видно из названия). Мы использовали его раньше и считаем необходимым включить этот тест в новую версию методики.
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | GFXBenchmark для Mac на MacBook Pro 16″ (Late 2021), Apple M1 Max | GFXBenchmark для Mac на iMac 24″ (Early 2021), Apple M1 | GFXBenchmark для Mac на iMac 27″ (Mid 2020), Intel Core i9-10910 | |
|---|---|---|---|---|
| GFXBenchmark 1440р Aztec Ruins (High Tier Offscreen) | 147 fps | 310 fps | 81 fps | 195 fps |
| GFXBenchmark 1080р Aztec Ruins (Normal Tier Offscreen) | 395 fps | 757 fps | 215 fps | 490 fps |
| GFXBenchmark 1440p Manhattan 3.1.1 Offscreen | 243 fps | 487 fps | 131 fps | 382 fps |
| GFXBenchmark 1080p Manhattan 3.1 Offscreen | 495 fps | 944 fps | 273 fps | 625 fps |
| GFXBenchmark 1080p Manhattan Offscreen | 816 fps | 1281 fps | 403 fps | 798 fps |
При этом мы включаем только 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 и запустить процесс.
Вот результаты наших «конкурсантов».
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Pro 13″ (Late 2020), Apple M1 | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|---|
| Запись / чтение, МБ/с (больше — лучше) | 4113 / 5396 | 2998 / 2576 | 1590 / 2226 | 2036 / 2688 | 2846 / 2869 |
AmorphousDiskMark
Хорошо себя показал и тест скорости чтения/записи в программе AmorphousDiskMark 3.1, Mac-аналоге известной утилиты CrystalDiskMark.
Вот результаты наших компьютеров:
| MacBook Pro 14″ (Late 2021), Apple M1 Pro | iMac 27″ (Mid 2020), Intel Core i9-10910 | MacBook Pro 15″ (Mid 2017), Intel Core i7-7820HQ | MacBook Air 13″ (Late 2020), Apple M1 | |
|---|---|---|---|---|
| SEQ1M QD8 Read/Write (МБ/с) | 6949 / 4683 | 3473 / 3407 | 3054 / 2189 | 3417 / 3012 |
| SEQ1M QD1 Read/Write (МБ/с) | 3389 / 4618 | 2091 / 2428 | 1089 / 1796 | 2372 / 3060 |
| RND4K QD64 Read/Write (МБ/с) | 661 / 138 | 1116 / 73 | 1016 / 40 | 1278 / 128 |
| RND4K QD1 Read/Write (МБ/с) | 58 / 30 | 25 / 137 | 48 / 55 | 67 / 32 |
Выводы
Нам не пришлось обновлять методику радикально, но все-таки ряд бенчмарков и подтестов ушли, а вместо них появились другие. Прежде всего, добавилась пакетная обработка фотографий, о чем читатели давно просили. Главное же — мы вовсе отказались от бенчмарков, не имеющих оптимизации под Apple Silicon. Таким образом, методика теперь состоит исключительно из Universal-приложений.
Учитывая, что Apple практически полностью перешла на ARM-процессоры, нет оснований сохранять необновленные приложения и нам.
Впрочем, мы всегда открыты к предложениям и замечаниям читателей, так что пишите, если у вас есть аргументированные и конкретные идеи включить в методику что-то еще!
Geekbench 5 — утилита для тестирования CPU и GPU
Geekbench 5 — кроссплатформенная утилита для тестирования CPU и GPU от компании PrimateLabs.
Есть минус, она платная. Однако, если воспользоваться триальным периодом, то протестировать своё железо вполне возможно.
Geekbench начинался как тест для Mac OS X и Windows. Автор Джон Пул, который руководил сайтом Geek Patrol, который уже не существует. На сайте анализировалось аппаратное и программное обеспечение, разработанное для компьютеров Mac, а также публиковались статьи и интервью для сообщества Mac.
Сейчас утилита поддерживает операционные системы:
- MacOS
- Windows
- Linux
- Android
- iOS
Начиная с пятой версии Geekbench только 64-битный. В процессе работы тест разделяет одноядерную и многоядерную производительность CPU выставляя, соответственно две оценки. Для GPU измеряется вычислительная мощность графического процессора.
Тест можно скачать. В зависимости от конфигурации и использованной памяти, результаты тестирования могут отличаться.
Есть готовые результаты тестирования разных процессоров, можно поискать там свой процессор.
Установка Geekbench 5
Выбираем свою операционную систему. Я буду тестировать в Windows 11. Скачиваем инсталлятор и запускаем его.
Открывается мастер установки Geekbench 5. Next.
Принимаем лицензионное соглашение. I Agree.
Можно изменить путь установки. Next.
Установка завершена. Можно оставить галку Run Geekbench 5. Finish.
Тестирование процессCPU и GPU утилитой Geekbench 5
Тестировать буду процессор AMD Ryzen 7 5800U на ноутбуке HP ProBook 455 G8 (16 ГБ ОЗУ) в операционной системе Windows 11. Там же встроенную графику AMD Redeon(TM) Graphics.
Открывается окно программы. Вверху отображается информация о системе и процессоре. Ниже есть разделы для тестирования CPU и GPU.
Для тестирования процессора достаточно нажать одну кнопку: Run CPU Benchmark.
Тест может занять от 2 до 20 минут.
Данные передаются на сайт Geekbench и в браузере отображается результат тестирования. Как видим, я получил в одноядерном тесте 1384, а в многоядерном 6278. Можно пролистать ниже и посмотреть подробности.
Для тестирования GPU нужно выбрать GPU, Compuеte API (Доступно OpenCL и Vulkan) и нажать кнопку Run Compute Benchmark.
Тест может занять от 2 до 10 минут.
Результат AMD Redeon(TM) Graphics с OpenCL API у меня 12142.
Меняю Compute API на Vulkan и повторяю тестирование.
Результат AMD Redeon(TM) Graphics с Vulkan API у меня 13297.
Вот и всё, никаких сложностей.
Вместо заключения
Линус Торвальдс оспаривал полезность оценок Geekbench из более ранних версий (до версии 3), потому что тест Geekbench раньше объединял результаты тестов в одну оценку. Начиная с Geekbench 4, эти проблемы были решены путем разделения целых чисел, чисел с плавающей запятой и криптографии на отдельные оценки. Однако, Линус по-прежнему отмечает, что результаты могут вводить в заблуждение и использоваться для искусственного преувеличения преимуществ одного процессора над другим.
Феном, пингвин и оверклокинг (часть 2)
Как уже было сказано в предыдущей части, целью моей оверклокерской возни является повышение производительности системы процессор-память путем разгона оных. Для этого мне понадобятся тесты стабильности работы процессора и памяти, а если со стабильностью все ок, можно переходить к тестам непосредственно производительности обоих компонентов, в которых, помимо нагрузки, должны присутствовать и измеренные «попугаи», для оценки качества проделанной работы, а то ведь можно доразгоняться до того, что весь прирост улетит в троттлинг. Исходя из таких соображений, я и буду подбирать утилиты.
реклама
Пару слов о железе. Оно с прошлого раза не изменилось: процессор Phenom II x6 1090T, материнка MSI 750-G55 под AM3, две планки по 4 ГБ памяти DDR3 1600 МГц Kingston FURY HyperX и видеокарта Palit JetStream 1060 с 3 ГБ памяти. ОС: Ubuntu MATE 16.04 x86_64.
Процессор
Начнем рассматривать инструментарий линуксового оверклокера с тестов процессора. Особенность найденной в сети информации по теме заключается в том, что тестируются в основном сервера или рабочие станции, в которых не подразумевается разгона и задачи сводятся к работе с базами данных, сетями или компиляции кода. Если выйти за эти рамки, первым, что мне попалось в поиске, был Stress-ng.
Stress-ng
реклама
Это консольный тестовый пакет, внутри которого есть множество тестов для различных подсистем компьютера. Устанавливается из репозитория командой sudo apt install stress-ng, однако, понять сходу, какие тесты и как запускать — не просто. В интернетах часто советуют такую команду для проверки процессора:
stress-ng —class cpu —sequential 6 —timeout 60s —metrics-brief
Она запускает один за другим все тесты, относящиеся к классу процессорных. Каждый тест запускается в шести экземплярах (по количеству ядер моего процессора) на одну минуту. В конце будет выведена информация о затраченном на каждый тест времени. Получится около получаса разнообразной нагрузки на процессор. В принципе, неплохо, но есть причина для поиска более подходящей команды — низкая эффективность тестов. Большинство из них прогревают процессор не слишком сильно, да и времени тратится много. Методом перебора всех используемых этой командой тестов, я нашел наиболее эффективный вариант. Выглядит так:
stress-ng —lsearch 6 —timeout 300s —metrics-brief
реклама
Эта команда запускает шесть экземпляров теста lsearch на пять минут (например) и выводит результаты. Тест представляет собой линейный поиск среди 32-битных элементов массива. Кроме процессора, он также сильно загружает контроллер памяти. Видимо, это и способствует его эффективности — тест выдает максимальный нагрев среди всех, относящихся к классу процессорных. Выводимые результаты (для 30 с теста с тремя запущенными экземплярами) выглядят так:
Представлена информация о том, что запущены три экземпляра теста, задействующие весь феномовский кэш третьего уровня в 6 МБ. Тест закончен за 30 с без ошибок. Столбцы в табличке несут следующую информацию (перевод цитат из «STRESS_NG General Commands Manual»):
Bogo ops
реклама
Количество законченных итераций теста за заданное время работы. Это показатель выполненного количества работы за время теста.
Real time (secs)
Средняя продолжительность теста в секундах. Это полное время выполнения всех задач отдельного теста, деленное на количество запущенных экземпляров теста.
Usr time (secs)
Полное время пользователя (в секундах), затраченное на запуск всех задач теста.
Sys time (secs)
Полное время системы (в секундах), затраченное на запуск всех задач теста.
Bogo ops/s (real time)
Количество выполненных итераций теста в секунду, вычисленное по средней продолжительности теста. Это время отражает явно затраченное на тест время. При наличии в системе более чем одного процессора, больше работы может быть распределено между ними, из-за чего средняя продолжительность теста уменьшается, а показатель bogo ops растет. По-существу, это и есть наглядный рейтинг производительности системы.
Bogo ops/s (usr+sys time)
Количество выполненных итераций теста в секунду, вычисленное по суммарному времени пользователя и времени системы. Это реальный рейтинг производительности, учитывающий действительное время окончания теста по всем процессорам (ядрам). Этот показатель меньше расчетного, в основном, из-за конкуренции нескольких процессоров (ядер) за доступ к кэшу, памяти, исполнительным устройствам, шинам и устройствам ввода/вывода.
Из всего вышеназванного нас интересуют два показателя Bogo ops/s (real time) и Bogo ops/s (usr+sys time). Первый показывает суммарную производительность процессора, а второй — производительность на ядро. Таким образом, с помощью этого теста можно не только проверить стабильность работы процессора, но и оценить его производительность.
Выглядит Stress-ng неплохо и для экспресс тестирования его должно быть достаточно, но мне захотелось узнать о возможности использовать что-то аналогичное популярным Windows-тестам типа LinX или Prime95
LinX
LinX представляет собой GUI для теста Linpack. Теоретически, есть его версия и под Linux (лежит тут ), а практически, мне запустить ее на Феноме не удалось. Тест (этот вариант теста, не используемый алгоритм) создан компанией Intel и лежит на ее сайте, так что отсутствие поддержки AMD по умолчанию понятно. Возможно, надо его просто пересобрать (по ссылке есть и исходники, правда серверной, а не десктопной версии) под амдешные процессоры, но, на мой взгляд, это уже выходит за рамки доступного простым юзерам. Других же вариантов запуска Linpack я не нашел, потому придется обойтись без него. Но есть ведь другой кроссплатформенный тест — Prime95.
Prime95
Это клиентская программа для проекта распределенных вычислений GIMPS. Одна из функций этой программы — стресс-тест железа. Она производит вычисления и сравнивает результат с заранее известным, что позволяет выявить ошибки, являющиеся результатом нестабильной работы системы. Но, кроме этого, она еще и отлично прогревает процессор, используя целочисленные вычисления, вычисления с плавающей запятой, задействуя кэш и заданное количество ядер. Скачать можно с сайта проекта: https://www.mersenne.org/download/ . Установка проста — распаковываем скачанный архив в папку и запускаем программу следующей командой:
./mprime -m
Очевидно, программа также консольная и интерфейс не сказать, чтобы интуитивно понятный. При первом запуске, для использования только в качестве теста нужно выбрать вариант «Just Stress Testing«. При дальнейшем использовании вывод этой команды будет выглядеть так:
Здесь нужно выбрать пункт 15 («пыточный» тест), а затем задать количество потоков (в моем случаем — 6).
Теперь выбирается тип теста процессора. Первый — максимальный нагрев, тестируется исключительно процессор. Второй — максимальное энергопотребление, немного задействована память. Третий — тестируем все понемногу, задействован максимум памяти. Если система не проходит третий тест, но проходит первые два — возможно, есть какие-то проблемы с памятью или контроллером памяти. Для тестирования стабильности работы процессора, я обычно выбираю первый вариант, т.к. в плане нагрева он лучший — температура на несколько градусов больше, чем в lsearch. После применения новых параметров, начнется тест. Выглядит это так:
Запускаются шесть экземпляров теста и, по мере выполнения, программа рапортует об их завершении. По нажатию Ctrl+C тесты останавливаются, выдавая отчет о количестве ошибок. Если ничего не нажать, тест будет крутиться бесконечно, что, в общем-то от него и требуется — тестирование стабильности системы может длиться часами. Запустить уже настроенные тесты можно так:
./mprime -t
Никаких проблем с работой Prime95 под Linux нет, свою задачу (прогрев процессора) тест выполняет на отлично. Единственный его недостаток — он не показывает производительность системы, то есть годится исключительно для тестирования стабильности работы. Попугаев же приходится добывать чем то иным. И тут на сцену выходит PTS.
Phoronix Test Suite
Описание (перевод) с сайта разработчиков:
«Phoronix Test Suite это наиболее полная платформа для тестирования и оценки производительности с гибкой структурой, в которую легко могут быть добавлены новые тесты. Программа создана для эффективной оценки количественных и качественных показателей производительности посредством четких, воспроизводимых и легких в использовании методов. Phoronix Test Suite можно использовать для простого сравнения производительности вашего компьютера и компьютеров ваших друзей и коллег или для проверки оборудования внутри вашей организации.»
Очевидно, это не тест, а набор инструментов для работы с различным тестовым ПО. Опенсорсный, фриварный и консольный. Больше подробностей о работе с ним на русском языке тут: Phoronix Test Suite, или как тестировать процессоры it-шнику. Часть 1: Intel vs AMD . Второй части, увы, не будет — автор больше не пишет на оверах. Это довольно таки плохая новость, потому как информации о работе с PTS в рунете очень мало. Вот, разве что, еще одна интересная заметка нашлась: Утилита тестирования Phoronix Test Suite . А дальше пришлось разбираться самому по англоязычным манам.
Устанавливается PTS из репозитория следующей командой:
sudo apt-get install phoronix-test-suite
После установки можно посмотреть список доступных для установки тестов из категории процессорных:
phoronix-test-suite list-available-tests | grep Processor
И так далее — весь список я приводить не буду, т.к. тестов очень много. Отсюда вытекает первая проблема PTS — муки выбора. Определиться с тем, какие из тестов использовать, не так то просто. Исходя из общих соображений, мне будет нужно следующее: однопоточный и многопоточный тесты производительности, а так же несколько тестов производительности в задачах, приближенных к моим повседневным наиболее часто используемым. В качестве теста однопоточной производительности, я выбрал Himeno Benchmark. В качестве теста многопоточной производительности — Stockfish. «Повседневные» тесты — архиватор (7-Zip Compression), видеокодек (FFmpeg), обработка изображений (GraphicsMagick).
Почему выбраны именно эти тесты? Однопоточная производительность мне интересная только из-за не самого быстрого контроллера памяти Фенома. Он может ограничить эффект от разгона процессора по частоте при полноценной загрузке всех ядер. При нагрузке же на одно ядро, я смогу четко увидеть влияние частоты ядра на его производительность. Многопоточный тест покажет мне полную картину, с учетом частоты не только ядер, но и контроллера памяти — довольно интересная информация на мой взгляд. Какой тест использовать для однопотока, в принципе, без разницы, т.к. я сравниваю один и тот же процессор между собой и нюансы архитектуры учитывать нет нужды. Потому, взял первый попавшийся тест, а его заточенность на использование блока FPU тут роли не играет. Тоже можно сказать и про выбор многопоточного теста — подойдет любой, умеющий хорошо распараллеливать задачи. Ну, а критерии для «повседневных» тестов, думаю, очевидны — нужна имитация моего обычного сценария использования компа.
Вторая проблема PTS — отсутствие развернутого описания тестов. Без ковыряния в текстовых конфигах на Гитхабе, понять, что делает каждый из тестов и с какими опциями он запускается невозможно. Может быть, это я туплю, но где найти эту инфу, так и не понял. Ниже приведены краткие описания из Гит-репозитория ( https://github.com/phoronix-test-suite/test-profiles/tree/master/pts ).
Himeno Benchmark
Тест производительности системы при линейном решении уравнения Пауссона, описывающего поле давления в жидкости, методом Якоби. Результат в MFLOPS (миллион операций с плавающей точкой в секунду).
Stockfish
Тест открытого шахматного движка, написанного на С++11, который легко масштабируется на большое количество ядер (до 128). Результат в Nodes Per Second (кол-во позиций в секунду).
7-Zip Compression
Тест архиватора 7-Zip, использующий p7zip с его встроенным тестом производительности. Результат в MIPS (миллион инструкций в секунду).
FFmpeg
Этот тест использует библиотеки FFmpeg для измерения производительности системы при кодировании аудио и видео. Результат в секундах.
GraphicsMagick
Тест графический библиотеки GraphicsMagick, реализованный средствами OpenMP. Выполняет различные тесты на эталонном JPEG-изображении 6000х4000 пикселей. Результат в Iterations Per Minute (кол-во итераций в минуту). В качестве тестов используются следующие операции: colorspace HWB, operator all Noise-Gaussian 30%, enhance, resize 50%, rotate 90, sharpen 0x2.0, swirl 90.
Выбранный тест можно запустить (если он еще не установлен, будет выведен запрос на установку), например, такой командой:
phoronix-test-suite run pts/ffmpeg
По окончанию теста на экран будет выдан отчет:
По нему видно, что тест запускается три раза, а затем вычисляется среднее значение. Если результаты отличаются слишком сильно, тест будет запускаться еще и еще до тех пор, пока не получится три более-менее близких значения. Результаты также сохраняются в
/.phoronix-test-suite/test-results/ При запуске теста, PTS спрашивает, стоит ли их там сохранять. Можно задать имя теста и имя текущего прогона этого теста. При следующем запуске, результаты можно будет сохранить с тем же именем теста, но под другим именем прогона, тогда информацию об обоих прогонах PTS оформит в диаграмму такого вида:
Результаты тестов также можно сразу же загружать на сайт OpenBenchmarking.org
В PTS есть еще и графический интерфейс в виде браузерного приложения. Запускается вот такой командой:
phoronix-test-suite gui
Выглядит вполне неплохо (скрин ниже), но в использовании он отнюдь не интуитивно понятный, да еще и слегка тормознутый (браузер же). Консольный режим гораздо удобнее, на мой взгляд.
В целом, для задач тестирования процессора PTS хватает за глаза — это очень могучий инструмент, пользоваться которым, правда, не просто. Я юзал самые базовые возможности, не касаясь даже десятиметровой палкой редактирования скриптов, которое, насколько я понимаю, и раскрывает мощь PTS в полной мере. На результаты работы профессионалов же можно посмотреть на соответствующем сайте . Еще я забыл упомянуть о возможности PTS измерять производительность в играх, запускаемых через Steam. Такая тоже есть, но, как пользоваться ею, совсем не очевидно, а мне эта возможность была не особо интересна в контексте этой темы и разбираться я не стал. Вместо этого, для имитации игрового теста я использовал Unigine Valley.
Unigine Valley
Это кроссплатформенный графический тест, разработанный, внезапно, томской компанией Unigine (на ЛОРе можно понаблюдать за довольно интересным общением их сотрудника с юзерами). Профильная деятельность компании — одноименный 3D-движок, а тесты — продукт побочный, однако неплохой. На текущий момент актуальны три их варианта: Heaven (2009), Valley (2013) и Superposition (2017). Все тесты на Linux используют OpenGL и задействуют только одно ядро процессора, что на тестировании видеокарт никак не сказывается, а вот в случае с CPU это могло бы быть проблемой, если бы не одно но — большинство нативных и Wine-игр, не использующих Vulkan, утилизируют ресурсы процессора так же неэффективно. Т.е. эти тесты, в итоге, хорошо имитируют линукс-гейминг (лично для меня, как ценителя относительно старых игр).
Выбор мною Valley обусловлен низкими системными требованиями (по сравнению с Superposition, который много весит, долго запускается и требует не антикварную видеокарту) и большим количеством 3D-объектов в кадре (по сравнению с Heaven, который скорее про освещение и различные пост-эффекты, чем про геометрию). Впрочем, разница там гомеопатическая и нагрузку на процессор все три теста дают примерно одинаковую, можно брать любой.
Для установки нужно скачать run-файл отсюда и запустить командой ./Unigine_Valley-1.0.run. Программа установится в папку
/Unigine_Valley-1.0, откуда ее можно запустить командой ./valley или кликом мышью по этому файлу. После запуска появляется окно настроек:
Для теста CPU я выключаю сглаживание и выставляю низкое разрешение. Качество оставляю высоким, чтобы не уменьшать количество 3D-объектов и полигонов на них, хотя, не факт, что опция на эти параметры влияет. Но упора в видеокарту все равно нет — пусть будет высоким. Однако, это не все доступные настройки. Запустив тест кнопкой «RUN», в появившемся меню настроек можно будет отключить еще некоторые эффекты, увеличивающие нагрузку на видеокарту: Ambient Occlusion (имитация глобального освещения), Объемные тени и Размытие. Теперь можно приступать к тесту (кнопка «Бенчмарк»), после которого выдается окно с результатами:
Выводится средний, минимальный и максимальный FPS и некие попугаи-баллы — вполне информативно. Казалось бы, смысла в тесте ровно ноль, ведь используется только одно ядро процессора и то до конца не загружено. Однако, результаты очень неплохо коррелируют с частотой процессора и, как ни странно, позволяют быстро оценить прирост производительности в играх при его разгоне. Так что, Valley, как тесту процессора, быть. На десерт остался еще один кроссплатформенный тест — Geekbench 5.
Geekbench 5
Описание (перевод) с сайта разработчиков:
«Geekbench 5 измеряет производительность вашего процессора в однопотоке и многопотоке в различных задачах, начиная от получения почты и заканчивая обработкой изображений и проигрыванием музыки или всем этим сразу. Geekbench 5 также измеряет производительность в новых прикладных задачах, включая дополненную реальность и машинное обучение, так что вы будете знать, как близка ваша система к острию прогресса.»
Скачать можно отсюда. Для установки нужно только распаковать архив. Внутри два файла — для 32-х или 64-х битной системы. Запускается такой командой:
./geekbench5
Тест консольный, как и предыдущие, но по окончании, он загрузит результаты на сервер и покажет их в браузере . Можно привязать их к своему аккаунту на сайте , и сравнить с последующими прогонами. Общие рейтинги выводится в таком (см. скриншот) виде, а ниже на странице результатов есть рейтинги по каждому отдельному тесту, которых имеется больше двух десятков в однопоточном и многопоточном режимах:
Наверно, для быстрой оценки производительности и сравнения ее на разных платформах это неплохой вариант: скачал, запустил и через несколько минут получил готовый результат. Но привязка к сети и закрытость — довольно существенные минусы лично для меня. На этом я процессорную часть заканчиваю и перехожу к утилитам тестирования памяти.
Память
Memtest86+
Для быстрого тестирования стабильности подойдет старый добрый Memtest86+. Он использует свой собственный загрузочный образ (т.е. по умолчанию является кроссплатформенным), который можно скачать с сайта разработчика. Мне, правда, кажется более удобным использовать его в составе System Rescue CD (набор опенсорсных утилит для диагностики и восстановления работоспособности компа). Этот вариант подходит для любой платформы, на которой есть CD-привод или USB-порт для загрузки с внешнего устройства. Для своей же системы все еще проще — Memtest86+ включен в дистрибутив Ubuntu и может быть запущен при старте перед загрузкой ОС (меню загрузчика появляется при нажатии Shift). Выглядит Memtest86+ так:
Программа выводит данные о процессоре, скорость работы его кэшей, скорость работы самой памяти, ее частоту и тайминги. Но вся эта информация несколько попугайская, потому что программа практически не обновляется с 2013 года и не слишком уверенно взаимодействует с относительно современным железом. Есть более современный аналог — Memtest86, форком четвертой версии которого и является Memtest86+. Этот проект продолжает развиваться и современной аппаратной начинке соответствует, однако, он позволяет работать только с материнскими платами с поддержкой UEFI, коего моя старушка лишена. Впрочем, это не важно — производительность я буду измерять другими средствами, а Memtest86+ использую для проверки стабильности работы оперативной памяти после увеличения частоты и игр с таймингами. Тестирование утилитой может длится бесконечно (пока не будет нажата Esc) и, в случае появления ошибок в работе памяти, экран окрасится красным и будут выведены сообщения об адресах памяти, при работе с которыми были выявлены проблемы. После нескольких циклов работы Memtest86+, в качестве окончательной проверки, я использую пару часов прогона Prime95 в режиме Blend, где максимально задействована память. Этого набора достаточно для тестирования стабильности работы, но хочется еще и более-менее валидной информации о производительности ОЗУ. Для этого мне пригодилась программа Lmbench.
Lmbench
В принципе, в упомянутом выше PTS есть тесты, предназначенные именно для работы с памятью, но я среди них не увидел таких, которые бы выдавали в качестве результатов два главных показателя производительности подсистемы памяти: пропускную способность и задержки для базовых операций с данными. Для их измерения я, внезапно для себя, открыл олдскульный опенсорсный бенчмарк Lmbench. Это набор простых кроссплатформенных тестов (пара десятков) для UNIX-систем. В рунете информации о нем крайне мало, и это странно — штука-то хорошая.
Устанавливается из репозиториев командой sudo apt install lmbench , после чего нужно создать папку для тестовых файлов командой mkdir /var/tmp/lmbench . Теперь можно запустить тест:
sudo lmbench-run
При каждом запуске будет задан ряд вопросов для настройки тестов:
MULTIPLE COPIES [default 1]: 6
Задаем количество одновременно запущенных тестов при использовании нескольких процессоров или ядер. Увы, функция в статусе экспериментальной и, иногда, она может сильно замедлить тестирование. В моем случае проблем не возникло, процесс наоборот заметно ускорился при задействовании всех шести ядер.
Job placement selection [default 1]:
Определяем способ распределения задач по процессорным ядрам. Если нет особых требований, лучше оставить это системному планировщику (вариант по умолчанию).
MB [default 5588]:
Количество доступной оперативной памяти. Не более 80% от общего количества памяти системы. Для полноценного теста оставляем значение по умолчанию, но можно задать меньшее для уменьшения времени тестирования. По получению ответа на этот вопрос, lmbench три раза протестирует заданное количество памяти. Это займет довольно продолжительное время и к дальнейшим вопросам можно будет перейти только по окончанию проверки.
SUBSET (ALL|HARWARE|OS|DEVELOPMENT) [default all]: HARDWARE
Выбор используемого набора тестов: все, оборудование, операционная система, разработка. Последний пункт позволяет выбрать для запуска конкретные тесты. Очевидно, для оверклокинга хватит «железного» набора.
FASTMEM [default no]: yes
Включение режима быстрой проверки памяти. В нем используется упрощенное измерение задержек ОЗУ (шаг данных при тестировании начиная с 128 байт). При размере кэша процессора больше 128 байт, тестирование с меньшим шагом бессмысленно, так что включение должно экономить время, однако на самом деле экономия там небольшая, т.к. измерение задержек — это только часть тестов, а время, затраченное на остальные, никак не меняется. Но пару минут можно выиграть — включаем.
SLOWFS [default no]:
Включение режима проверки медленных файловых систем. При тестировании жестких дисков с древними файловыми системами процесс может затянуться и там эта опция нужна. В при тестировании ОЗУ не используется, оставляем выключенной.
DISKS [default none]:
Указание тестируемых жестких дисков (/dev/sda и т.д.). По умолчанию тестирование выключено. Нас интересует только ОЗУ — пропускаем.
REMOTE [default none]:
Настройка тестирования сети. По умолчанию выключено. Так же пропускаем.
Processor mhz [default 3800 MHz, 0.2632 nanosec clock]:
Задание частоты процессора. Определяется тестом автоматически, однако, не всегда верно. Если значение по умолчанию не соответствует реальности, указываем частоту вручную.
FSDIR [default /var/tmp/lmbench]:
Задание папки для временных файлах, необходимых при тестировании. Свободного места на диске с этой папкой должно быть не менее указанного выше количества доступной оперативной памяти и указанная папка должна быть создана юзером вручную, иначе тест выдаст соответствующую ошибку.
Status output file [default /dev/tty]:
Место назначения для вывода сообщений в процессе выполнения тестов. По умолчанию — консоль.
Mail results [default yes]: no
Оправка результатов в онлайновую базу данных на сайте . Выключаем за ненадобностью.
Получив ответы на эти вопросы, lmbench начинает тестирование, выводя на экран информацию по текущему тесту:
По окончании тестов результаты можно найти в папке /var/lib/lmbench/results в виде текстовых файлов. После каждого запуска lmbench формируется отдельный файл. В нем можно найти результаты следующих тестов:
- Время выполнения различных операций с числами (сложение, деление и т.д.).
- Пропускная способность памяти при выполнении функции bcopy (копирование данных) в различных вариациях.
- Пропускная способность памяти при выполнении функции bzero (запись нулей в память) в различных вариациях.
- Пропускная способность памяти при выполнении последовательного и выборочного чтения данных.
- Пропускная способность памяти при выполнении последовательной и выборочной записи данных.
- Пропускная способность памяти при выполнении выборочных чтения и записи данных.
- Пропускная способность памяти при параллельной загрузке данных.
- Задержки и пропускная способность памяти при выполнении различных тестов из набора STREAM.
- Задержки памяти при последовательной загрузке данных с различным шагом.
- Задержки памяти при выборочной загрузке данных с шагом 16 байт.
Информации много, но для меня интересно только то, что относится к чтению, записи и копированию данных и задержкам при загрузке данных. Критерием для выбора именно такого набора послужило то, что популярная Windows-программа проверки железа AIDA64 по умолчанию проверяет память подобными же тестами, то есть результаты можно будет сравнить при желании. В качестве примера работы Lmbench, возьмем тест пропускной способности памяти при последовательном чтении (Memory read bandwidth) для частоты 1600 МГц в шестипотоке (данные в необработанном виде):
Производительность сервера по тесту Geekbench
Geekbench — это бесплатный кроссплатформенный тест производительности (бенчмарк). С его помощью можно измерить производительность любого компьютера, в том числе производительность виртуального сервера. Тест Geekbench измеряет мощность процессора при выполнении различных действий: от работы с приложениями до вычислений при машинном обучении.
Облачные серверы нового поколения
Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!
Производительность облачных серверов REG.RU
При заказе облачных серверов вы можете посмотреть результаты оценки производительности серверов каждого тарифа по независимому тесту Geekbench.
Замеры производительности сделаны на операционной системе Ubuntu 18.04 на физическом сервере без нагрузки. Это позволило получить стабильные значения, по которым можно откалибровать тарифы и сравнить один тариф с другим. На заполненном сервере значения теста будут ниже в абсолютном выражении.
Как замерить производительность самостоятельно
С помощью Geekbench вы можете выполнить тестирование производительности сервера REG.RU самостоятельно. Также вы можете измерить производительность серверов у других провайдеров. Обратите внимание, что нужно сравнивать результаты тестов, полученные с помощью одной и той же версии утилиты, так как каждая версия Geekbench измеряет производительность относительно своего базового CPU.
Чтобы сделать замеры:
На официальном сайте Geekbench найдите ссылку на нужную версию. Для этого скопируйте пункт «Click here».
Если вам нужна произвольная версия, то ссылку можно составить по шаблону: