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

Предлагаем вашему вниманию перевод классической статье Дэвида Бейли.

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

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. Если все остальные попытки оказались неудачными, покажите какие-либо красивые картинки и анимированное видео, и не говорите ни слова о производительности.
Иногда случается, что слушатели начинают задавать разные надоедливые вопросы. Эти люди не имеют никакого уважения к авторитетам в данной области. Если вас постигла такая незадача, что вас не считают авторитетом, всегда есть выход: просто суммируйте вашу техническую презентацию и запустите кассету. Публике нравится цветная суета, она часто помогает отвлечь внимание от существенных технических проблем.