Паралельні бібліотеки спільної пам'яті на основі наукових обчислень на основі завдань

В останні роки з'явилося кілька бібліотек / програмних проектів, які пропонують ту чи іншу форму загального призначення паралелізму спільної пам'яті, керованого даними.

Основна ідея полягає в тому, що замість написання явно потокового коду програмісти реалізують свої алгоритми як взаємозалежні завдання, які потім динамічно плануються середнім програмним забезпеченням загального призначення на машині спільної пам'яті.

Прикладами таких бібліотек є:

• КВАРТ : Спочатку розроблений для паралельної лінійної алгебри MAGMA паралельної лінійної алгебри, здається, використовувався і для паралельного методу швидкого багатополюсності .

• Cilk : Спочатку проект на базі MIT, який зараз підтримується Intel, реалізований як розширення мови / компілятора на C, який використовується в комп'ютерному шаховому програмному забезпеченні Cilkchess та експериментально в FFTW .

• Суперскаляр SMP : розроблений в Барселонському центрі суперкомп'ютерів, багато в чому схожий на Cilk, заснований на #pragmaрозширеннях.

• StarPU : Подібні "бібліотеки" на основі бібліотеки, які можна скласти і запланувати в декількох різних архітектурах, включаючи GPU.

• Завдання OpenMP: Починаючи з версії 3.0, OpenMP представив "завдання", які можна запланувати асинхронно (див. Розділ 2.7 специфікації).

• Інтелектуальні будівельні блоки Intel : Використовують класи C ++ для створення та запуску асинхронних завдань, див. Розділ 11 Підручника.

• OpenCL : підтримує паралелізм на основі задач на декількох ядрах.

Хоча є багато літератури, яка описує внутрішню роботу цих бібліотек / розширень мови та їх застосування до конкретних проблем, я натрапив на дуже мало прикладів їх використання на практиці в наукових обчислювальних програмах.

Тож ось питання: Хтось знає про наукові обчислювальні коди, що використовують будь-яке з цих бібліотек / розширень мови або подібне, для паралелізму спільної пам'яті?

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

На мою думку, ці системи були відносно невдалими, насамперед, з наступних причин.

• Наївна перспектива, що паралельне обчислення стосується паралелізації обчислень (наприклад, флопів) більше, ніж відкриття локальної пам'яті та видалення точок синхронізації. Хоча деякі проблеми, такі як алгоритми щільної матриці, як і раніше обмежені FP, виникають лише після ретельного розгляду підсистеми пам'яті, а більшість обчислювальних ядер (особливо в світі PDE) є більш чутливими до пам'яті. Робочі черги, як правило, торгують місцем пам'яті для кращого наївного балансу флопів та більшої кількості операцій з атомною пам'яттю (за рахунок синхронізації через чергу).
• Опора на надмірне розкладання для динамічного балансу навантаження за рахунок сильної масштабованості. Задачі, як правило, залежать від даних, що перекриваються (значення привидів). Із зменшенням розміру інтер'єру співвідношення привид / інтер’єр збільшується. Навіть коли це не передбачає зайвої роботи, це передбачає посилення руху пам’яті. Значні скорочення вимог до пропускної здатності пам’яті можуть мати такі підходи, як спільний попередній вибір, за допомогою якого кілька потоків поділяють кеш L1 або L2 шляхом попереднього вибору програмного забезпечення для свого сусіда (який неявно підтримує групу потоків приблизно когерентною). Це якраз протилежне надмірному розкладанню.
• Непередбачувана продуктивність, здебільшого через вищезазначені проблеми з пам'яттю.
• Відсутність зручних для бібліотеки компонентів. Це майже можна назвати таким, що не має аналога аналогічного, MPI_Commщо дозволяє різним бібліотекам виконувати розширені операції без зіткнення, а також передавати контекст між бібліотеками та відновлювати необхідні атрибути. Абстракція, що надається "комунікатором", важлива для складання бібліотеки незалежно від того, використовується спільна чи розподілена пам'ять.