Сколько накладных расходов вызывает искрение?

Этот график в разделе "Параллельное и параллельное программирование": http://chimera.labs.oreilly.com/books/1230000000929/ch03.html#fig_kmeans-granularity, по-видимому, указывает на то, что серьезных накладных расходов слишком много. Но если вы внимательно посмотрите на ось y, вы заметите, что она была увеличена до интересного раздела. Фактически, соотношение между показателями наилучшего и наихудшего случая составляет около 80%, что не так уж плохо.

В целом, выяснение того, как и сколько для куска сложно, подвержено ошибкам, чрезвычайно специфично для приложений и, вероятно, изменится в следующем году, когда вы купите новый компьютер с большей вычислительной мощностью. Я бы предпочел всегда использовать rpar с наиболее мелкозернистыми предметами и жить с 25% накладными расходами.

Может ли накладные расходы на искрение, как правило, хуже, чем показано на этом графике? (особенно если я всегда сбрасываю бинарные деревья, а не списки, поэтому вторая маркерная точка "объем последовательной работы" не применяется)


Обновленный вопрос в ответ на ответ Дона Стюарта:

Имеется ли в искровом пуле только одна очередь, к которой все процессоры стремятся получить доступ? или их много?

Например, если у меня есть компьютер с бесконечными процессорами и двоичное дерево, и я хочу взять сумму по всем листам, как в:

data Node = Leaf Int | Branch Node Node

sumL (Leaf x) = x
sumL (Branch n1 n2) = let (x,y) = (sumL n1, sumL n2) in (x `par` y) `seq` (x + y) 

Будет ли эта программа работать в O (#leaves) времени? или O (глубина)? Есть ли лучший способ написать это?

Пожалуйста, дайте мне знать, если я слишком много абстрагирую, чтобы получить удовлетворительный ответ. Моя ментальная модель работы haskell parallelism по-прежнему очень нечеткая.

Ответ 1

Одна искра очень дешевая.

  • Спарковый пул. Каждое обращение par a b добавляет thunk a к (текущий HECs) Spark Pool; этот тон называется "искра". [1]

Если какой-либо HEC становится бездействующим, он может затем проверить пул и начать оценивать thunk сверху.

Так что искрение грубо добавляет указатель на очередь.

Чтобы сделать распределение искры более дешевым и более асинхронным, мы перепрограммировать каждый HECs Spark Pool как ограниченную очередь обработки работы (Arora et al., 1998; Chase and Lev 2005). Очередь работы - это блокировка данных с некоторыми привлекательными свойствами: владелец очередь может нажимать и выскакивать с одного конца без синхронизации, между тем другие потоки могут "украсть" с другого конца очереди несут только одну атомную инструкцию.

Также в [1]

Проблема в том, что вы можете легко создать миллиарды искр. В этот момент вы просто превращаете свою программу в построитель очереди - все время затрачивается на обновление искрового пула с указателями на код.

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