Як вирішити числову неасоціативність для паралельного скорочення?

Паралельне зменшення передбачає, що відповідна операція є асоціативною. Це припущення порушено для додавання чисел з плаваючою комою. Ви можете запитати, чому я переймаюся цим. Ну, це робить результати менш відтворюваними. І стає гірше, коли імітований відпал використовується для оптимізації (або підгонки параметрів) над підпрограмами, що дають такі невідтворювані результати.

Які поширені способи вирішити цю проблему? Що можна сказати про наступні стратегії?

• Не дбайте про невідтворюваність.
• Не використовуйте паралельне зменшення з числами з плаваючою комою та додаванням.
• Створюйте робочі пакети відповідного розміру відтворюваним способом і виконайте остаточне зменшення вручну.
• Використовуйте більш високу точність для додавання (але не всі компілятори пропонують більш високу точність з плаваючою точкою).

Скорочення, здійснене за допомогою MPI_Allreduce(), відтворюється до тих пір, коли ви використовуєте однакову кількість процесорів за умови, що реалізація дотримується наступної примітки, що з’являється у розділі 5.9.1 стандарту MPI-2.2.

Порада виконавцям . Настійно рекомендується MPI_REDUCEреалізовувати так, щоб той самий результат був отриманий кожного разу, коли функція застосовується в одних і тих же аргументах, що з'являються в одному порядку. Зауважте, що це може запобігти оптимізаціям, що скористаються фізичним розташуванням процесорів. ( Кінець поради виконавцям .)

Якщо вам потрібно гарантувати відтворюваність будь-якою ціною, ви можете дотримуватися вказівок у наступному пункті:

Поради користувачам . Деякі програми можуть не в змозі ігнорувати неасоціативний характер операцій з плаваючою комою або можуть використовувати визначені користувачем операції (див. Розділ 5.9.5), які потребують спеціального порядку зменшення і не можуть розглядатися як асоціативні. Такі додатки повинні чітко виконувати порядок оцінки. Наприклад, у випадку операцій, які вимагають строгого наказу зліва направо (або справа наліво), це можна зробити, зібравши всі операнди в одному процесі (наприклад, з MPI_GATHER), застосувавши операцію скорочення у бажаному порядку (наприклад, з MPI_REDUCE_LOCAL), і, якщо потрібно, транслюйте або розповсюджуйте результат на інші процеси (наприклад, з MPI_BCAST). ( Кінець поради користувачам .)

У більш широкій схемі речей ефективні алгоритми для більшості додатків використовують перевагу місцевості. Оскільки алгоритм дійсно відрізняється при запуску на різній кількості процесів, то точно відтворити результати при запуску на різній кількості процесів просто не практично. Можливим винятком є ​​багаторешітка з затухаючими якобі або поліноміальними (наприклад, Чебишев) згладжувачами, де цей простий метод дуже добре працює.

При однаковій кількості процесів продуктивність часто корисна для обробки повідомлень у тому порядку, в якому вони були отримані (наприклад, використання MPI_Waitany()), що вводить недетермінізм. У таких випадках ви можете реалізувати два варіанти, швидкий, який отримує в будь-якому порядку, і "налагодження", який отримує в статичному порядку. Це вимагає, щоб усі основні бібліотеки також були написані, щоб запропонувати таку поведінку.

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

Здебільшого я даю відповідь Джеда. Однак є інший вихід: З огляду на розмір звичайних чисел з плаваючою точкою, ви можете зберігати кожне число у фіксованому точковому номері 4000 або близько. Отже, якщо ви зробите зменшення на вбудовані таким чином числа з плаваючою комою, ви отримаєте точний розрахунок, незалежно від асоціативності. (Вибачте, я не маю посилання на те, хто придумав цю ідею.)

Ви можете реалізувати чисельно стабільний алгоритм скорочення в MPI такий же, як і в серійному. Звичайно, може бути хіт на виставу. Якщо ви можете дозволити реплікацію вектора, просто використовуйте MPI_Gather і виконайте чисельно стабільне зменшення послідовності в корені. У деяких випадках ви можете побачити, що хіт на продуктивність не є великою справою.

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

Компроміс для вищезазначеного полягає у використанні компенсованого підсумовування. Докладні відомості див. У посиланнях «Підсумок Кахана». « Точність та стійкість числових алгоритмів » Хігхема є чудовим ресурсом на цю тему.

Для вирішення проблеми в контексті потоків у спільній системі пам'яті я написав цю сторінку, яка пояснює, що ми робимо у взаємодії. II: http://dealii.org/developer/doxygen/deal.II/group__threads.html #MTWorkStream

Я хотів би зазначити, що замість використання арифметики вищої точності для додавання існує можливість використання компенсованого підсумовування (див. [1]). Це може підвищити точність підсумовування без необхідності вдаватися до великих типів даних.

[1] Хігхем, Нью-Джерсі, Точність підсумовування плаваючої точки. Журнал SIAM з наукових обчислень 14, 783–799 (1993).