Лог-лог параллельное масштабирование / графики эффективности

Большая часть моей собственной работы вращается вокруг того, чтобы алгоритмы масштабировались лучше, и один из предпочтительных способов показать параллельное масштабирование и / или параллельную эффективность - это построить производительность алгоритма / кода по количеству ядер, например

где ось представляет количество ядер, а ось некоторую метрику, например, работу, выполненную за единицу времени. Различные кривые показывают параллельную эффективность 20%, 40%, 60%, 80% и 100% при 64 ядрах соответственно.$x$$y$

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

Это тот же график, что и выше, но с масштабированием log-log. Обратите внимание, что теперь нет большой разницы между результатами для 60%, 80% или 100% параллельной эффективности. Я написал более подробно об этом здесь .

Итак, вот мой вопрос: какое обоснование есть для отображения результатов в масштабировании журнала? Я регулярно использую линейное масштабирование, чтобы показать свои собственные результаты, и меня постоянно избивают судьи, которые говорят, что мои собственные результаты параллельного масштабирования / эффективности выглядят не так хорошо, как (log-log) результаты других, но на всю жизнь я не могу понять, почему я должен переключать стили сюжета.

В настоящее время мы пишем статью, которая содержит ряд сопоставимых графиков, и у нас более или менее возникла та же проблема. Статья посвящена сравнению масштабирования различных алгоритмов по количеству ядер, которое колеблется от 1 до 100 тыс. В BlueGene. Причиной использования loglog-plot в этой ситуации является количество задействованных порядков. Невозможно изобразить 6 порядков в линейном масштабе.

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

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

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

Георг Хагер написал об этом в « Обманывающие массы» - Трюк 3: Шкала бревен - ваш друг .

Хотя верно то, что графики логарифмирования с сильным масштабированием не очень разборчивы на верхнем уровне, они позволяют показывать масштабирование еще на несколько порядков величины. Чтобы понять, почему это полезно, рассмотрим трехмерную задачу с регулярным уточнением. В линейном масштабе вы можете разумно показать производительность примерно на два порядка, например, 1024 ядра, 8192 ядра и 65536 ядер. Из сюжета читатель не может сказать, запускали ли вы что-нибудь меньшее, и реально, сюжет в основном просто сравнивает два самых больших пробега.

Теперь предположим, что мы можем разместить 1 миллион ячеек сетки на ядро ​​в памяти, это означает, что после сильного масштабирования в два раза с коэффициентом 8 у нас все еще может быть 16 тыс. Ячеек на ядро. Это все еще значительный размер субдомена, и мы можем ожидать, что многие алгоритмы будут работать там эффективно. Мы рассмотрели визуальный спектр диаграммы (от 1024 до 65536 ядер), но даже не вошли в режим, когда сильное масштабирование становится затруднительным.

Предположим вместо этого, что мы начали с 16 ядер, также с 1 миллионами ячеек сетки на ядро. Теперь, если мы масштабируемся до 65536 ядер, у нас будет только 244 ячейки на ядро, что будет гораздо более разборчивым. Логарифмическая ось - единственный способ четко представить спектр от 16 ядер до 65536 ядер. Конечно, вы все еще можете использовать линейную ось и иметь заголовок, говорящий «точки данных для 16, 128 и 1024 ядер перекрываются на рисунке», но теперь вы используете слова вместо самой фигуры, чтобы показать.

Шкала log-log также позволяет вашему масштабированию «восстанавливаться» после машинных атрибутов, таких как перемещение за пределы одного узла или стойки. Вам решать, желательно это или нет.

Я согласен со всем, что Джед должен был сказать в своем ответе, но я хотел добавить следующее. Я стал поклонником того, как Мартин Берзиньш и его коллеги демонстрируют масштабность для своей структуры Uintah. Они строят слабое и сильное масштабирование кода по осям log-log (используя время выполнения на шаг метода). Я думаю, что это показывает, насколько хорошо масштабируется код (хотя отклонение от идеального масштабирования немного сложно определить). См. Стр. 7 и 8 рисунков 7 и 8 этой * бумаги, например. Они также дают таблицу с номерами, соответствующими каждой цифре масштабирования.

Преимущество этого состоит в том, что после того, как вы предоставили цифры, обозреватель может сказать немногое (или, по крайней мере, не так много, что вы не можете опровергнуть).

* J. Луитжен, М. Берзиньш. «Повышение производительности Uintah: крупномасштабная вычислительная платформа с адаптивной сеткой», в материалах 24-го Международного симпозиума IEEE по параллельной и распределенной обработке (IPDPS10), Атланта, Джорджия, стр. 1–10. 2010. DOI: 10.1109 / IPDPS.2010.5470437