У які парадигми програмування я повинен вкладати кошти, якщо хочу, щоб мій код в майбутньому запускався на верстатах з високою шкалою?

З огляду опису топ-500 досить ясно, що галузь має тенденцію до експоненціального збільшення оброблювальних ядер . Найбільші суперкомп'ютери, які використовують MPI для зв'язку між вузлами, хоча, мабуть, не мають чіткої тенденції до паралелізму на вузлах, з найпростішим (але не обов'язково найефективнішим) підходом до відображення одного процесу MPI в кожне ядро, автоматичного паралелізація з компілятора, OpenMP, pthreads, CUDA, Cilk і OpenCL.

Я один із групи вчених, які підтримують та розробляють код, який має потенціал для використання на деяких найбільших суперкомп'ютерах у світі. Якщо припустити обмежений час розробника, як я маю себе в майбутньому, щоб я міг скористатися продуктивністю найпотужнішої машини в світі? Які припущення слід зробити щодо архітектури взаємозв'язку процесів? Які парадигми будуть страждати, коли ми входимо в епоху багатокоротких? Чи будуть доступні мови "Розміщений глобальний адресний простір" "у виробництві" на машинах з високим розміром?

Історична перспектива

Справді неможливо сказати, якими будуть нові парадигми в майбутньому, наприклад, гарну історичну перспективу. Я пропоную прочитати « Підйом і падіння КНП Кена Кеннеді» . Кеннеді розповідає про дві нові моделі, MPI проти розумного компілятора, та детально описує, як MPI мав потрібну кількість ранніх прийнятих та гнучкість домінувати. HPF врешті-решт вирішив свої проблеми, але було вже пізно.

Багато в чому кілька парадигм, такі як PGAS і OpenMP, дотримуються цієї ж тенденції ВПЧ. Ранні коди були недостатньо гнучкими, щоб добре використовувати, і залишили багато продуктивності на столі. Але обіцянка не потрібно писати кожну йоту паралельного алгоритму - приваблива мета. Тож завжди переслідують нові моделі.

Чіткі тенденції в обладнанні

Зараз успіх MPI часто посилається на тісний зв'язок із тим, як він моделює апаратне забезпечення, на якому він працює. Приблизно кожен вузол має кілька процесів, і передача повідомлень у локальну точку-в-точку або через скоординовані колективні операції легко здійснюється в просторі кластера. Через це я не довіряю тому, хто надає парадигму, яка не слідкує за новими апаратними тенденціями, я фактично був переконаний у цій думці твором Вівака Саракара .

Відповідно до цього, тут є три тенденції, які чітко просуваються в нових архітектурах. І дозвольте мені бути зрозумілим, зараз є у HPC продається дванадцять різних архітектур. Це було менш ніж 5 років тому лише з x86, тому найближчі дні побачать безліч можливостей для використання апаратних засобів різними та цікавими способами

• Фішки спеціального призначення: Подумайте про великі векторні одиниці, як прискорювачі (перегляд Білла Далі з Nvidia)
• Чіпи малої потужності: кластери на основі ARM (для розміщення бюджетів на енергоспоживання)
• Плитка чіпсів: продумайте плитку чіпів з різними специфікаціями (робота Avant Argwal )

Поточні моделі

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

Дозвольте мені ознайомити з моделями та те, як їх потрібно буде змінювати, виходячи з передбачуваних нових видів обладнання.

Поширений

Гравці на розподіленому рівні значною мірою потрапляють у мови MPI та PGAS. MPI - це явний переможець зараз, але мови PGAS, такі як UPC та Chapel, просуваються в космос. Одним із хороших показників є HPC Benchmark Challenge. Мови PGAS дають дуже елегантну реалізацію орієнтирів.

Найцікавіший момент тут полягає в тому, що поки ця модель працює лише на рівні вузла, вона буде важливою моделлю всередині вузла для архітектурних плиток. Однією з ознак є мікросхема Intel SCC, яка принципово діяла як розподілена система. Команда SCC створила власну реалізацію MPI, і багато команд досягли успіху в перенесенні бібліотек спільноти до цієї архітектури.

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

Внутрішньовузлова спільна пам'ять

Тут ми бачимо, що MPI часто є «досить хорошим», але PThreads (і бібліотеки, що випливають з PThreads, таких як Intel Parallel Building Blocks) і OpenMP, все ще часто використовуються. Поширена думка полягає в тому, що буде час, коли буде достатньо потоків спільної пам’яті, що модель розеток MPI зруйнується для RPC або вам потрібен легший процес ваги, що працює на ядрі. Вже ви можете бачити ознаки систем IBM Bluegene, які мають проблеми із спільною MPI спільної пам'яті.

Як зазначає Метт, найбільшим підвищенням продуктивності для обчислювальних інтенсивних кодів є векторизація серійного коду. Хоча багато людей вважають, що це правда у прискорювачах, це також критично важливо і для машин на вузлі. Я вважаю, що у Вестмера є 4 широких FPU, тому можна отримати лише чверть флопів без векторизації.

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

І OpenMP, і PThreads на достатньому рівні курсу можуть скористатись векторизацією, необхідною для отримання високого відсотка піку, але для цього потрібно розбити алгоритми таким чином, щоб векторизація була природною.

Копроцесор

Нарешті з'явилася поява спільного процесора (GPU, MIC, акселератори стільникових пристроїв). Стає зрозуміло, що жоден шлях до екскавалу не буде повним без них. У SC11 кожен учасник конкурсу Bell використовував їх дуже ефективно, щоб дістатись до низьких петафлопів. Поки CUDA та OpenCL домінували на поточному ринку, я сподіваюся на компілятори OpenACC та PGAS увійти в космос.

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

Як це впливає на розробника програми

Тепер, щоб перейти до вашого питання. Якщо ви хочете захистити себе від насуваючих складних машин, то слід зробити кілька речей:

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

Якщо ви хочете бути виконавцем сьогодні, MPI + CUDA / OpenCL досить хороший, але UPC потрапляє туди, тому не погана ідея займати кілька днів і вивчити це. OpenMP розпочинає роботу, але призводить до проблем, коли код потрібно буде відновити. PThreads вимагає повністю переписати код у його стиль. Що робить MPI + CUDA / OpenCL найкращою моделлю на даний момент.

Що тут не обговорюється

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

Це призводить до іншої тенденції, яка може відбутися (якщо залучити право фінансувати агентства). Машини ставатимуть все більш спеціалізованими для необхідного виду обчислень. Ми вже бачимо, що "об'ємні дані" машини фінансуються NSF, але ці машини знаходяться на іншому шляху, ніж в Exascale Grand Challenge 2019.

Це стало довше, ніж очікувалося, запитуйте посилання, де вони вам потрібні в коментарях

Почнемо з обговорення стратегії коду intranode (обчислення якої не зачіпає взаємозв'язок), оскільки я думаю, що MPI є хорошим вибором коду міжвузлів. Я думаю, що безглуздо говорити про вузли, що мають менше 100 ядер, так що хоча б поточний GPU або MIC.

Справа в тому, що самі pthreads не можуть отримати максимальну продуктивність на будь-якому сучасному чіпі, тому що ви повинні скористатися векторною одиницею (правда з першого Cray). У Intel та AMD можна використовувати внутрішню техніку, але вони не є портативними, і, на мою думку, незграбними. CUDA та OpenCL мають вбудовану в бібліотеку векторизацію та полегшують отримання максимальної продуктивності. Все нове обладнання, про яке мені відомо, має цю векторну вимогу, тому будь-яке рішення повинно враховувати це. Для мене CUDA / OpenCL - це поточний шлях.

Далі всі ці машини будуть NUMA, що важче програмувати, але я думаю, що стратегія ядра працює. Ви поділяєте роботу та дані на невеликі одиниці. Вони, ймовірно, будуть заплановані автоматично, як це відбувається зараз у CUDA та OpenCL, але ви можете вказати залежності. Для проблем, які відповідають парадигмі потокової передачі, цей фрагмент також можна зробити автоматично. Intel TBB робить це, але я вважаю за краще підхід бібліотеки вищого рівня , що пояснюється Thrust and Cusp , який може націлювати CUDA або (незабаром) TBB.

Я спробую коротшу відповідь, ніж деякі мої шановні колеги з цієї теми ;-)

Моє повідомлення всім моїм студентам завжди полягає в тому, що час розробника є більш цінним, ніж час процесора. Це означає, що якщо у вас є час перетворити 100% коду з ефективністю 80% для роботи на великих машинах - використовуючи підхід високого рівня -, то вам краще, ніж коли ви використовуєте трудомісткий низькорівневий рівень підхід, який дає 100% ефективність на 20% вашого коду. Як наслідок, я великий фанат бібліотек високого рівня. Моєю улюбленою в цій області є нитки будівельних блоків (TBB), оскільки це дозволяє мені переглядати алгоритми в самих зовнішніх петлях і на високому рівні. Він також може робити все, що ви хочете зробити з pthreads, без жорсткості роботи з функціями ОС тощо. Я не прихильник підходів, які розглядають найпотаємніші петлі, тому що це неправильний рівень використання паралельних ресурсів інтраноди - - тому немає OpenMP,

Я не можу з владою говорити про OpenCL, CUDA тощо.

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

Ось мої спроби відповісти на два запитання, на які ще не відповіли чи відповіли відносно обмежено:

Які припущення слід зробити щодо архітектури взаємозв'язку процесів?

Я розгляну три властивості мереж:

1. затримка,
2. пропускну здатність та
3. одночасність.

Затримка обернено пропорційна частоті. Ми знаємо, що масштабування частоти застоюється. Отже, можна зробити висновок, що в майбутньому затримка навряд чи значно зменшиться. Затримка MPI відправки-рекв. На Blue Gene / Q становить приблизно 2 ми, що відповідає 3200 циклів. Більше половини цієї затримки - це програмне забезпечення, але хороша його частина вимагається стандартом MPI; обширна настройка може зменшити затримку до близького до нас, особливо якщо можна стверджувати, що макіяж MPI не використовуватиметься.

У будь-якому випадку затримка обладнання для введення пакетів в системах Blue Gene і Cray становить близько 1 нас. Якщо що-небудь, підвищення одночасності на рівні вузлів утруднює утримання цього числа настільки низьким, але я впевнений, що дизайнери апаратних засобів знайдуть способи утримати затримку під 5 нам до огляду в майбутньому.

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

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

Третя властивість мереж, яку часто не помічають у формальних моделях, - це кількість повідомлень, які можна надсилати одноразово. Наявність мережі із затримкою 1 нс та / або пропускною здатністю 1 ТБ / с, яка може надсилати лише одне повідомлення одночасно, було б абсолютно марним для більшості звичаїв. Важливо вміти одночасно надсилати велику кількість повідомлень з безлічі потоків, а мережа не може згортатися. І системи Cray, і Blue Gene тепер досягають понад 1 Мбіт (мільйон повідомлень в секунду). Я не можу пригадати точні цифри, але обидва здатні досягти значної частки пропускної здатності піку за допомогою невеликих повідомлень. Ідеальна мережа могла б досягти максимальної пропускної здатності за допомогою будь-якого повідомлення про розмір, але це неможливо на практиці через заголовка пакетів та пов'язані з ним бухгалтерські витрати. Однак,

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

Чи будуть доступні мови "Розміщений глобальний адресний простір" "у виробництві" на машинах з високим розміром?

Системи Cray XE, XK і XC мають компілятор UPC та CAF якості виробництва. Системи Blue Gene можна постачати за допомогою XLUPC та XLCAF, але ніхто не просить цього, щоб він не був доставлений. PERCS має компілятори XLUPC та XLCAF високого рівня виробництва, але не має масштабних установок, доступних науковому співтовариству.

Coarrays є частиною Fortran 2008, хоча впровадження в Intel та GNU Fortran ще не є якісними. Реалізація Intel вважається ефективною, але також є досить повільною (про це йдеться в PGAS12).

Що стосується моделі програмування PGAS (оскільки моделі програмування - не мови програмування - предмет початкового питання), то бібліотека Global Arrays є розумним наближенням до якості виробництва у багатьох випадках. Як час виконання, він не такий надійний, як MPI, але MPI є досить унікальним з точки зору якості реалізації. Реалізація ARMCI-MPI ARMCI робить Global Arrays набагато стабільнішими, хоча в деяких випадках навіть повільнішими.

Досить просто реалізувати конструкції в стилі PGAS якісно з використанням якості MPI-3 RMA. Якщо хтось опублікує нове запитання з цього приводу, я би радий відповісти на нього.

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

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

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

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

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

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

Друга проблема полягає в тому, що всі асоціюють паралелізм спільної пам'яті з OpenMP . Хоча OpenMP - це приємний швидкий і брудний спосіб вирішення невеликих, простих проблем на невеликій кількості процесорів, це абсолютно жахлива модель програмування для реального паралелізму спільної пам'яті. Хоча ми всі, в той чи інший момент, навчилися ряду простих та ефективних парадигм паралельного програмування, наприклад, пули ниток або Планувальники , це непросто реалізувати за допомогою OpenMP, і, чесно кажучи, це не тип паралелізму, який OpenMP спонукає програмістів використовувати.

Підводячи підсумок, бар'єр для переходу від чисто розподіленої пам'яті до чисто / частково парадигми спільної пам'яті досить високий. Якщо ви хочете ефективно використовувати теми, вам доведеться забути OpenMP та керувати потоками та самостійно (привіт pthreads , до побачення Fortran).

Але навіщо взагалі переходити до гібридного підходу? Добре, хоча MPI масштабується до тисяч ядер, в основі лежить модель синхронізованості та статичної схеми зв'язку. Це добре для деяких проблем, наприклад, імітація мільярдів частинок, але недооптимальна для більш складних або тонкозернистих проблем. Парадигми спільної пам’яті значно спрощують динамічне врівноваження навантаження та / або асинхронну комунікацію, але це вимагає великих зусиль з програмування.