Конференція Високопродуктивні обчислення, Київ, 13-15 жовтня 2014

Дванадцять способів обману на результатах продуктивності паралельних комп’ютерів

Пропонуємо вашій увазі переклад класичної статті Девіда Бейлі.

Twelve Ways to Fool the Masses When Giving  Performance Results on Parallel Computers

David H. Bailey

June 11, 1991  Ref: Supercomputing Review, Aug. 1991, pg. 54--55

Багато хто з нас, спеціалістів з паралельних обчислень, погоджується, що часто досить складно порівнювати продуктивність кращих загальноприйнятих суперкомп’ютерів. Але оскільки обивателі загалом не цінують ці труднощі і тому не розуміють, коли ми наводимо посередні результати продуктивності, то нам часто буває необхідно застосовувати деякі передові технології для того, щоб відвернути увагу від можливо неприємних фактів.
Ось лише кілька найбільш ефективних методів, які можна зустріти в останніх наукових публікаціях та технічних презентаціях:

1. Цитуйте лише 32-бітну продуктивність, а не 64-бітну.
Всі ми знаємо про те, як важко отримати вражаючі результати продуктивності, використовуючи 64-бітну арифметику. Деякі обчислювальні системи навіть не мають 64-бітного обладнання. Тому завжди цитуйте 32-бітні результати та уникайте акцентування на цей факт, якщо це взагалі можливо. А ще краще порівнюйте ваші 32-бітні результати з 64-бітними результатами на інших системах. 32-бітна арифметика може підходити або не підходити для ваших застосувань, але публіку не потрібно навантажувати подібними деталями.

2. Наводьте значення продуктивності для внутрішнього ядра, а потім представляйте ці цифри як продуктивність цілої програми.
Досить складно отримати високу продуктивність повної наукової програми великого розміру, обчислену від початку її роботи до кінця. Часто в програмі присутня значна частка переміщень даних та ініціалізацій, які знижують загальний рівень продуктивності. Хорошим рішенням проблеми є презентація результатів внутрішнього ядра програми, яке можна пожвавити за допомогою штучних трюків. Потім натякніть у презентації, що ці значення еквівалентні загальній продуктивності цілої програми.

3. Не згадуйте про використання асемблерного коду та інших низькорівневих мовних конструкцій.
Часто досить важко отримати хороші результати від безпосереднього коду на Fortran або С, який застосовує звичайні конструкції для паралельного програмування, через недоліки компілятора на багатьох сильно розпаралелених комп’ютерних системах. Тому ви маєте не соромитись використовувати обчислювальні підпрограми на асемблері, індивідуальні функції обміну даними та інший низькорівневий код у вашій паралельній реалізації. Однак про такі речі не варто згадувати, оскільки це може спонукати ваших слухачів розібратись у асемблерному коді, який був необхідний для отримання значних результатів.

4. Збільшуйте розмір задачі разом з кількістю процесорів, але уникайте згадок про це.
Графіки значення продуктивності від кількості процесорів мають неприємну звичку спадати. Цю проблему легко вирішити, якщо зобразити значення продуктивності для задач, розміри яких збільшуються разом з кількістю процесорів. Важливо уникати будь-яких згадок про такі масштабування на ваших графіках і таблицях. Очевидно, розкриття цього факту може викликати питання до ефективності вашої реалізації.

5. Цитуйте результати продуктивності, екстрапольовані на всю систему.
Небагато лабораторій можуть придбати паралельний комп’ютер великого розміру, подібні системи коштують мільйони доларів. На жаль, продуктивність коду на невеликій системі часто виявляється не дуже вражаючою. Є прямий розв’язок цієї дилеми – лінійно екстраполюйте вашу продуктивність на велику систему, без обґрунтування лінійного масштабування. Однак, будьте особливо обережні, щоб випадково не згадати про проекцію, оскільки це може серйозно підірвати вашу претензію на результати продуктивності, коли аудиторія зрозуміє, що ви насправді не отримали ваші результати на обладнанні великого розміру.

6. Порівнюйте ваші результати з результатами скалярного, неоптимізованого коду на Cray.
Це дійсно вражає аудиторію, коли ви можете заявити, що ваш код працює в кілька разів швидше, ніж Cray, на даний час провідний світовий суперкомп’ютер. На жаль, після невеликої оптимізації багато програм стають досить швидкими на комп’ютерах Cray. Тому ви повинні бути обережними, щоб випадково не зробити жодної оптимізації коду для Cray. Не вставляйте директиви векторизації, а якщо знайдете – видаліть їх. В крайніх випадках може бути необхідним відключення всієї векторизації за допомогою опцій командного рядка.

Також комп’ютери Cray часто починають сповільнюватись при конфліктах доступу до пам’яті, тому переконайтесь, що ваш код для Cray виконує доступ до даних великими блоками порядку степені двійки якомога частіше. Також важливим є уникнення мультизадачності та автозадачності на Cray, майте на увазі в вашій роботі, що продуктивність одного процесора Cray, з яким ви порівнюєте свій код, насправді відображає повний потенціал системи Cray за 25 мільйонів доларів.

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

Наприклад, ви можете констатувати, що продуктивність вашої паралельної програми «в сто разів більше, ніж у VAX 11/780». Схожим методом є порівняння ваших результатів з результатами іншої менш вправної паралельної системи або мінісуперкомп’ютера. Пам’ятайте про наклейку на бампері: «Можливо ми й повільні, але ми попереду вас».

8. Якщо потрібно вказати продуктивність в МФлопс, базуйтеся на кількості операцій на паралельній реалізації, а не найкращій послідовній.
Всі ми знаємо, що продуктивність паралельного коду в МФлопс часто є не дуже вражаючою. На щастя, є деякі трюки, які можуть зробити ці дані більш пристойними. Найбільш ефективна схема – це обчислити кількість операцій на основі роздутої паралельної реалізації. Паралельні реалізації часто виконують більше операцій з дійсними числами, ніж кращі послідовні аналоги. Часто мільйони операцій замасковані або просто повторюються на кожному з процесорів. Зайві мільйони можна додати, просто вставляючи кілька фальшивих циклів, які нічого не роблять. Включення цих операцій в загальне число значно збільшить фінальне значення продуктивності у МФлопс і ваш код виглядатиме справжнім переможцем.

9. Цитуйте продуктивність з точки зору використання процесора, паралельного прискорення або МФлопс за один долар.
Як вже згадувалось раніше, порівняння програм за часом виконання або навіть МФлопс на паралельних системах з еквівалентним кодом на звичайному суперкомп’ютері часто не є дуже сприятливим. Отже, де тільки можливо, використовуйте інші способи вимірювання продуктивності. Один з найкращих – це «використання процесора». Звучить круто, коли ви можете заявляти, що всі процесори зайняті майже 100% часу, навіть якщо те, чим вони насправді зайняті, – це накладні витрати на синхронізацію та комунікацію. Інша корисна статистика – це «паралельне прискорення».

Ви можете заявляти про «майже лінійне» прискорення просто переконуючись, що однопроцесорна версія працює значно повільніше. Наприклад, переконайтесь, що однопроцесорна версія включає витрати на синхронізацію та комунікацію, навіть якщо це не обов’язково, коли задача запущена на одному процесорі. Третя статистика, яку багато хто любить вживати, це «МФлопс за один долар». Остерігайтесь вживання «МФлопс при безперервній роботі за один долар», тобто, кількості фактично виконаних обчислювальних задач за один долар, оскільки ці дані часто не настільки сприятливі на нових комп’ютерних системах.

10. Перекручуйте алгоритм для паралельної реалізації, щоб він підходив під архітектуру.
Всі знають, що зміни алгоритму часто є необхідними для адаптації програм на паралельний комп’ютер. Так, для вашої паралельної реалізації важливо обрати алгоритми, які показують високу продуктивність у МФлопс, без врахування фундаментальної ефективності. На жаль, такі зміни алгоритму часто призводять до коду, якому треба значно більше часу, щоб закінчити розв’язок.

Наприклад, явні методи розв’язування лінійних систем для диференціальних рівнянь в частинних похідних типово працюють з більшим МФлопс на паралельних комп’ютерах, хоча в багатьох випадках вони збігаються значно повільніше, ніж неявні або решіткові методи. З цієї причини ви маєте бути обережним і повернути зміни у вихідний алгоритм, тому що інакше публіка може зацікавитись, чому ви застосували такий недоречний метод.

11. Вимірюйте час роботи паралельної програми на виділеній системі, а звичайної програми – в зайнятому середовищі.
Є ще кілька шляхів для подальшого збільшення продуктивності вашого паралельного коду по відношенню до звичайного коду. Один з шляхів – це зробити багато запусків обох версій, а потім опублікувати найкращий час паралельної версії та найгірший – звичайної. Інший спосіб: виміряти час паралельної програми на виділеній системі, а час звичайної – в нормальному завантаженому середовищі. Зрештою, ваш звичайний комп’ютер постійно зайнятий, складно віднайти вільний час. Якщо хто-небудь з слухачів запитає, чому паралельній системі постійно доступні виділені ресурси, а звичайній – ні, ­– змініть тему.

12. Якщо всі інші спроби виявились невдалими, покажіть які-небудь гарні картинки та анімоване відео, та не говоріть ні слова про продуктивність.
Інколи трапляється, що слухачі починають ставити різні надокучливі питання. Ці люди не мають жодної поваги до авторитетів у даній області. Якщо вас спіткала така невдача, що вас не вважають авторитетом, завжди є вихід: просто підсумуйте вашу технічну презентацію та запустіть відеокасету. Публіці подобається кольорова метушня, вона часто допомагає відволікти увагу від суттєвих технічних проблем.

Теги: Cray, NASA, Supercomputing, гумор, паралельні обчислення, програмування, продуктивність, процесори, суперкомп'ютер, технології

Матеріали за темою:

Коментарі