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


17

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

график искусственного параллельного масштабирования

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

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

введите описание изображения здесь

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

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

Ответы:


16

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

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

Епзнак равноT1/(пTп)T1TпппЕпп

Епзнак равноTрее/(пTп)Tрее

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


2
Икс

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

14

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

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

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

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

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


ИксY

1
Это гораздо труднее , сильным масштабе одной проблемы с коэффициентом 4096 , чем в масштабе двух разных размеров проблемных с коэффициентом 64 каждого. В приведенном мной примере легко сделать так, чтобы два независимых случая показывали эффективность более 95%, но при этом один объединенный случай имел эффективность менее 30%. В науке и промышленности нет заранее определенной причины, по которой желаемое время оборота должно попадать в узкий диапазон размеров, где алгоритм «удобен».
Джед Браун

Я полностью согласен с тем, что масштабирование от одного до тысячи является главной задачей! Причина, по которой я считаю разные величины разными проблемами, заключается в том, что для конечного пользователя это будет означать разные вещи. Например, в MD большинство биологов не имеют BlueGene в подвале, но имеют несколько многоядерных рабочих станций или даже грант на некоторое время для кластера среднего размера (небольшое количество узлов), и люди смотрят на большие Проблемы CFD, однако, не будут особо волновать случай с одним узлом, потому что проблема не помещается в памяти. Дело не в удобстве алгоритма, а в настройках пользователя.
Педро

2

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

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

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


Есть ли шанс, что вы сможете вставить изображение прямо в свой ответ?
Арон Ахмадиа

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

С этой точки зрения вы можете обернуть изображение так, чтобы оно ссылалось на сайт автора, а также увеличить объем текста в ссылке. Если вы хотите обсудить это подробнее, я могу открыть тему мета / чата.
Арон Ахмадиа

@BillBarth Ваша ссылка просто перенаправляет на их домашнюю страницу. Не могли бы вы исправить это или встроить нужное изображение?
Джед Браун

1
@JedBrown Ссылка отредактирована. Добавлена ​​полная ссылка. DOI добавил.
Билл Барт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.