Теги: методика тестування

Зміст

  • Тестовий стенд
  • Відеомонтаж
  • Подтест 1: стабілізація відео 4К
  • Подтест 2: фінальний рендеринг через Compressor
  • Подтест 3: стабілізація відео Full HD
  • Подтест 4: робота з відео 8К
  • Подтест 5: створення проксі-файлу
  • Відтворення відео 8К
  • Програмування
  • 3D-моделювання

Рік тому ми розробили першу версію комплексної методики тестування продуктивності комп’ютерів під управлінням macOS. З тих пір ми використовували її при написанні цілого ряду статей і змогли на практиці переконатися в корисності більшості тестів. Проте, час не стоїть на місці, програми оновлюються, продуктивність зростає, тому саме час оновити методику і заодно перевірити з її допомогою актуальні конфігурації комп’ютерів Apple.

Насамперед зазначимо, що загальний «каркас» методики залишиться незмінним: це ряд розроблених нами сценаріїв роботи в реальних додатках (в першу чергу — Final Cut Pro X), а також кілька бенчмарків, які довели свою ефективність і репрезентативність. Так що необхідна збережеться спадкоємність. Але в деталях буде досить багато відмінностей, пов’язаних і зі змінами, і з накопиченим досвідом застосування першої версії методики.

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

В якості тестових комп’ютерів ми використовували три моделі Apple: новий iMac Pro в стандартній конфігурації, 12-дюймовий MacBook останнього покоління (Mid 2017) і 15-дюймовий MacBook Pro (Mid 2015). У таблиці нижче наведені основні характеристики цих моделей, що відносяться до продуктивності.

iMac Pro (Late 2017)
MacBook Pro 15″ (Mid 2015)
MacBook 12″ (Mid 2017)
Процесор (CPU)

Кількість ядер CPU, частота

GPU

Оперативна пам’ять

Сховище

Intel Xeon W-2140B (Skylake) Intel Core i7-4870HQ (Haswell) Intel Core m3-7Y32 (Kaby Lake)
8 ядер/потоків 16, 3,2 ГГц (Turbo Boost до 4,2 ГГц) 4 ядра/8 потоків, 2,5 ГГц (Turbo Boost до 3,7 ГГц) 2 ядра/4 потоку, 1,2 ГГц (Turbo Boost до 3,0 ГГц)
AMD Pro Vega 56 AMD Radeon R9 M370X Intel HD Graphics 615
32 ГБ LPDDR4 2666 МГц 16 ГБ 1600 МГц DDR3L 8 ГБ DDR3 1866 МГц
SSD 1 ТБ 512 ГБ SSD SSD 256 ГБ

Чому саме ці моделі (крім суто практичного міркування — вони були в наявності під час роботи над методикою)? Тому що це новітній флагман, не самий новий середнячок і самий слабкий варіант з актуальною лінійки, тобто три дуже показові конфігурації (кожна — по-своєму).

На iMac Pro і MacBook використовувався однаковий софт: операційна система macOS High Sierra 10.13, Final Cut Pro 10.4, а також актуальні версії тестових додатків. На MacBook Pro була встановлена попередня версія ОС — Sierra, а також Final Cut Pro 10.2.3, інші програми були в тих же версіях, що і на двох інших комп’ютерах.

Відеомонтаж

Почнемо з Final Cut Pro X. Відеомонтаж — одна з головних і найбільш показових професійних завдань. А пакет Final Cut Pro X — потужне програмне рішення. Нещодавно FCP був оновлений, і починаючи з версії 10.4 у ньому з’явилася можливість роботи з 360-градусними відео, а також з 8К-відео.

Нові режими нам дуже допоможуть при тестуванні самих продуктивних конфігурацій — наприклад, iMac Pro. Правда, відмовлятися від тестування відео дозволом Full HD і 4К ми, зрозуміло, не будемо, просто скоротимо кількість подтестов.

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

Отже, перша операція — стабілізація відео 4K. Як рік тому, в якості першого тестового відео ми будемо використовувати 5-хвилинний відеоролик 4K 30 fps, знятий на iPhone 7 Plus.

Тут вся інформація про нього, отримана з допомогою утиліти Mediainfo.

Відкриваємо FCP, створюємо New Event, натискаємо Import Media і вибираємо відеофайл у вікні.

Зверніть увагу, що повинно бути зазначено Copy to library, але не повинно бути зазначено Create proxy media Create optimized media у налаштуваннях праворуч.

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

Бачимо, що у вікні Background Tasks почався процес Transcoding and Analysis. Відразу після її завершення розпочнеться процес Rendering. І тільки по закінченні Rendering ми зупиняємо секундомір і записуємо вийшло час.

Як ми бачимо, у порівнянні з минулим роком інтерфейс Final Cut Pro помітно змінився, тепер під вікном з відео вже немає відображення відсотків виконання операції, так що доводиться використовувати Background Tasks. Але — що поробиш… Важливо під час вимірювання не чіпати миша і не здійснювати жодних дій у FCP, інакше процес буде припинятися, а отже, результати вже не будуть коректними.

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

Для цього натискаємо в Final Cut Pro X вкладку File / Send to Compressor.

Відкривається Compressor (зрозуміло, він повинен бути попередньо встановлений на комп’ютері), в ньому ми натискаємо на центральну кнопку Add Outputs і в меню вибираємо Publish to YouTube / Up to 4K. Чому саме його? Тому що отриманий файл — прийнятних розмірів, що добре для тестування (не завжди об’єм SSD буває максимальним), а крім того, це цілком зрозумілий «життєвий» сценарій.

Після цього залишилося натиснути кнопку Start Batch в нижньому правому куті вікна програми — і процес розпочнеться. Жодних змін у порівнянні з минулою версією методики тут немає.

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

У третьому тесті ми повторюємо дії і налаштування першого, тільки з відеороликом дозволу Full HD. Його параметри — нижче.

Оскільки, наприклад, минуле покоління MacBook 12″ зависало на стабілізації відео 4К, збереження Full HD в методиці поки ще необхідно.

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

А ось це вже зовсім новий, хоча і дуже простий тест. Тепер ми додаємо в FCP відео 8К H. 265. В якості тестового ролика ми вирішили використовувати ось це відео (за посиланням пропонується його купити, тому ми не можемо викладати його тут безкоштовно). Його параметри в Mediainfo — на скріншоті.

І тут важливий нюанс: кодек H. 265 підтримується тільки починаючи з macOS High Sierra. Відповідно, у випадку з комп’ютерами під управлінням більш старих ОС цей і наступні тести з файлом 8К будуть недоступні.

Звернемо увагу на налаштування імпорту. При додаванні відео на Timeline з’являється вікно з пропозицією вказати параметри — дозвіл і частоту кадрів. І там за замовчуванням стоїть дозвіл 4К. Нам же треба вибрати Custom, і тоді автоматично будуть підставлені потрібні параметри і за дозволом, і за кодеку, і по частоті кадрів.

Відкривши відео на Timeline, ми переводимо його в ч/б, використовуючи встановлений ефект Black & White. Ця операція дуже швидко виконується з відео Full HD і навіть 4К, але у випадку з двохвилинним відео 8К створює пристойну навантаження на комп’ютер. Знову ж таки, з допомогою Background Tasks і секундоміра заміряємо тривалість операції.

Подтест 5: створення проксі-файлу

Друга операція з тим же відео — створення проксі-файлу. Це дуже життєвий сценарій, оскільки з такими важкими відео краще працювати, звичайно, через проксі-файл (фактично, дубль вашого файлу, але в більш низькому дозволі; всі подальші монтажні операції робитимуться з ним, що заощадить ресурси і час, а вже при завершенні роботи зміни будуть застосовані до вихідного файлу). Щоб зробити проксі-файл, треба клікнути правою кнопкою миші на відео у Events Browser, потім натиснути Transcode Media, у вікні відзначити Proxy Media і натиснути ОК. Не забудьте відразу в цей момент включити секундомір і стежити за процесом через Background Tasks.

Крім перерахованого вище ми планували ще спробувати експорт відео 8К через Compressor, але переконалися в марності цієї операції: з використанням кодека Apple ProRes (а це поки що єдиний спосіб зберегти дозвіл 8К) процес виходить занадто довгим, щоб можна було його реально використовувати. А інше, загалом-то, не має особливого сенсу, тому що навіщо працювати з відео 8К, якщо потім ми його будемо переробляти у щось гірше?

Отже, у нас вийшло 5 подтестов замість 4 в попередній версії методики. При цьому ми додали два нові (8К), але прибрали режим «Картинка в картинці» як не надто показовий і, загалом-то, вже не особливо нагружаюче комп’ютери.

iMac Pro (Late 2017)
MacBook Pro 15″ (Mid 2015)
MacBook 12″ (Mid 2017)
Тест 1 — стабілізація 4К (хв:сек)

Тест 2 — стабілізація Full HD (хв:сек)

Тест 3 — фінальний рендеринг через Compressor (хв:сек)

Тест 4 — додавання ефекту Black & White відео 8К (хв:сек)

Тест 5 — створення проксі-файлів з відео 8К

10:50 43:15 незастосовне
09:01 14:55 незастосовне
04:48 06:17 незастосовне
03:58 незастосовне
02:30 незастосовне

Останні два подтеста (робота з 8К-відео) варто використовувати тільки на дійсно продуктивних комп’ютерах, тобто це явно не варіант для MacBook 12″ старих моделей.

Відтворення відео 8К

Ще одна цікава і вельми показова операція — відтворення відео 8К. Так-так, просто відтворення. Навіть для самих продуктивних комп’ютерів це завдання не з легких, тому цілком показова для порівняння.

Тут ми чинимо просто: беремо відео 8К, яке використовували для тестів в Final Cut Pro, відкриваємо його в QuickTime Player і дивимося (з тим же успіхом його можна відтворити і в самому FCP). Навіть на iMac Pro були помітні легкі «підморожування» по ходу відтворення, а на початку, з появою перших кадрів власне зйомок (після заставки), гальма були цілком відчутними. Те ж відео на MacBook 12″ (Mid 2017) дивитися було взагалі неможливо.

До речі, корисно під час відтворення стежити за температурою CPU і GPU (на скріншоті вище ви бачите інформаційний блок праворуч). Але про це ми докладніше розповімо далі.

Програмування

Наступний блок тестів — імітація роботи, пов’язаної з програмуванням: це компіляція і пошук по вихідного коду. Тут все залишається без змін у порівнянні з попередньою версією методики. Але ми будемо раді вашим радам, як вдосконалити цю лінію, особливо якщо ви iOS-програміст, що працює в Xcode.

Отже, швидкість компіляції ми будемо перевіряти на Python 2. Для цього завантажуємо Python 2.7.13 звідси (17,1 МБ). Далі переходимо в папку, куди був скачаний пакет. Якщо це «Завантаження», то команда буде виглядати так: $ cd ~/Downloads

Наступним кроком розпаковуємо архів: $ tar xvzf Python-2.7.13.tar

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

Налаштовуємо параметри компіляції на поточній системі: $ ./configure

Це може зайняти якийсь час. Після налаштування починаємо компіляцію і заміряємо її час: $ time make -j 3 (в даному випадку «3» — це кількість ядер процесора + 1; якщо у нас чотириядерна система, то ставимо 5, і т. д.).

В результаті ми отримуємо три значення: real — це витрачений астрономічний час, user — витрачений процесорний час зовні системних викликів ядра, sys — час всередині ядра. Для порівняння ми будемо використовувати перше значення — real.

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

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

У результаті ми маємо таблицю з двома результатами по кожній моделі. Для зручності будемо округляти результат до цілих секунд.

iMac Pro (Late 2017)
MacBook Pro 15″ (Mid 2015)
MacBook 12″ (Mid 2017)
Компіляція Python 2, хв:сек

Текстовий пошук по вихідного коду, хв:сек

0:36 0:42 1:00
0:12 0:15 0:42

Тут вже розкид в результатах не настільки показовий, як в попередніх тестах, але треба розуміти, що компіляція і пошук не задіють GPU, так і ефективність використання CPU тут під питанням.

3D-моделювання

У нову версію методики ми вирішили додати операції з 3D-моделювання — це ще одна важлива область застосування високопродуктивних комп’ютерів. І тут ми будемо використовувати Maxon Cinema 4D Studio R19.

Завантажуємо, встановлюємо і відкриваємо програму (можна користуватися демо-версією). Далі завантажуємо файли .c4d тут. З цього набору найбільш показова сцена Bedroom interior (пряме посилання на завантаження!). Відкриваємо (File / Open) у скачаному архіві файл no_cm.c4d і бачимо таку картину.

Далі тиснемо у верхньому меню програми Render / Render To Picture Viewer. І спостерігаємо процес рендеринга 3D-сцени.

По закінченні візуалізації ми побачимо у вікні History праворуч — у колонці Render Time. Ось воно нам і потрібно.

Крім того, компанія Maxon створила бенчмарк Cinebench, який працює на тому ж движку і, фактично, імітує ті ж операції, що ми виконували в Cinema 4D.

Його цілком має сенс включити в методику, тим більше що бенчмарк мультиплатформовий, тому результати в ньому цілком можна порівняти з результатами на ПК під управлінням Windows.

Нижче — результати візуалізації в 4D Cinema R19 і Cinebench 15.

iMac Pro (Late 2017)
MacBook Pro 15″ (Mid 2015)
MacBook 12″ (Mid 2017)
Maxon Cinema 4D Studio, render time, хв:сек

Cinebench R15, OpenGL, fps

2:32 9:14 43:50
125,6 63,0 12,1

Дуже показовий величезний розрив у швидкості рендеринга між усіма трьома пристроями. При цьому, що важливо, це не синтетичний бенчмарк, а реальне завдання у популярному додатку для 3D-моделювання.

Отже, наш набір професійних програм дозволить оцінити продуктивність основних комплектуючих «в реальному житті» — як разом, так і з упором окремо на GPU і CPU. Але крім цього необхідно скористатися синтетичними та ігровими бенчмарками, щоб скласти максимально повну картину. Про це ми розповімо в другій частині статті.