Яка найчастіше використовується мова програмування у високопродуктивних обчисленнях? І чому? [зачинено]

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

Особливості сучасних мов програмування, такі як збирання сміття або поліморфізм під час роботи, не підходять для HPC, оскільки швидкість має значення, тому не знайте, куди потрапляють C # або Java або C ++.

Будь-які думки?

Я бачив багато Java, яка використовується для HPC в тих областях, де (1) мало застарілого коду, і (2) важливий час розробки та якість коду. Типовими сферами застосування є фінанси, обмін даними або біоінформатика.

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

З огляду на фіксовану кількість часу на розробку програми, отриманий код Java стабільно швидше, ніж код C. HPC на Java безумовно має сенс, коли код розробляється чи змінюється часто. Ще одна важлива особливість - мобільність коду над різним обладнанням.

Ви знайдете посилання на http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Що стосується припущення Fortran, що дві адреси унікальні, ми працюємо над інструментом статичного аналізу, який дасть змогу подібні оптимізації для коду на мовах високого рівня, але без біту "Bad Things May Be Happen". Зверніться до мене, якщо цікавитесь.

У моєму багаторічному досвіді, до 5 років тому, це завжди були Fortran і C. Котрий з них в основному залежав від того, чи люди прийшли більше від інженерії, чи більше від школи думки CS (я не знаю, як це зробити краще , гаразд? :-)

У тому, що ми робили, Фортран майже виключно використовувався.

З того, що я читав сьогодні, з новими оновленнями стандарту F2003 / 08 та впровадженням Co-Arrays, здається, він знову набирає обертів.

Також одна, якщо не дещо упереджена стаття - Ідеальна мова програмування HPC

Я думаю, що для справжньої педалі до металу єдиний реальний вибір - Fortran. Аргументація полягає в тому, що найважливішим для експлуатації низькорівневого ІЛП (паралелізму рівня інструкцій) є розбір пам’яті адреси пам'яті. Правила defacto у Fortran дозволяють компілятору визначити, що дві адреси є унікальними (а отже, порядок завантажень і зберігання, або навіть магазини та магазини можуть бути замінені, не ризикуючи генерувати неправильний код). C залишає занадто багато можливостей для перекриття покажчиків для компілятора, щоб отримати якомога більше паралелізму низького рівня з коду.

Також вирівнювання масиву, лінії кеш-пам'яті wrt та межі SSE / AVX важливі для створення та виконання ефективних циклів. Якщо масиви передаються через загальні блоки, компілятор / завантажувач може запевнити, що всі масиви починаються на одних і тих же межах вирівнювання адреси, а також можна використовувати більш ефективні навантаження та сховища SSE / AVX. Більш нове обладнання може працювати з нестандартними доступами до пам'яті, але, оскільки доступ до пам'яті не вирівняний належним чином, часткове використання ліній кеша призводить до зниження продуктивності. Навіть якщо програміст C належним чином вирівняє всі свої масиви, чи існує механізм передачі цього компілятору?

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

Просто якась анекдотична записка. Я не робив жодних високоефективних обчислень.

Для обчислень (кількість хрускіт), Fortran і C. Так, це з застарілих причин:

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

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

Друга тенденція - писати на якомусь спеціалізованому діалекті С для конкретних GPU або Cell BE.

Для нечислових робіт, таких як програми, що обробляють дані з бази даних (але не сама база даних), набагато дешевше працювати на кластерах «товарних» машин без дорогого індивідуального мережевого обладнання. Зазвичай це називається "Обчислення з високою пропускною здатністю". І Python тут є мовою №1 (використовуючи знамениту зменшення карт). До початку Python проекти пакетної обробки можуть бути написані будь-якою мовою і зазвичай надсилаються Condor .

Я працював над деяким ДУЖЕ інтенсивним розрахунковим кодом у (ах!) C #.

Я будую реалізацію FDTD для оптичного моделювання GPGPU . На невеликому (128 процесорному) кластері, для багатьох наших моделей потрібні тижні. Однак реалізація GPU, як правило, працює приблизно в 50 разів швидше - і це на картці NVidia споживача. Зараз у нас є сервер з двома двопроцесорними картами GTX295 (кілька сотень ядер), і ми скоро отримуємо кілька Teslas.

Як це стосується вашої мови? Так само, як C ++ FDTD-код, який ми використовували раніше, був пов'язаний з процесором, це пов'язані з графічним процесором, тому ( дуже мала) різниця кінських сил від керованого проти нативного коду ніколи не вступає в дію. Додаток C # виконує функцію провідника - завантажує ядра OpenCL, передає дані до та з графічних процесорів, забезпечує користувальницький інтерфейс, звітування тощо - всі завдання, які завдають біль дупі в C ++.

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

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

Фортран є найпоширенішим, в першу чергу завдяки спадщині (люди все ще користуються старим кодом) та знайомістю (більшість людей, які роблять HPC, не знайомі з іншими мовами).

Особливості сучасних мов програмування, такі як збирання сміття або поліморфізм під час роботи, не підходять для HPC, оскільки швидкість має значення, тому не знайте, куди потрапляють C # або Java або C ++.

Це взагалі не вірно. Класичний HPC в основному робив лінійну алгебру з машинною точністю чисел. Однак сучасний HPC все частіше використовує суперкомп'ютери для ширшого розмаїття, як символічні обчислення з довільними математичними виразами замість машинних точних чисел. Це розміщує зовсім інші характеристики на інструментах, які ви використовуєте, і не рідкість використання мов програмування, крім Fortran, оскільки символічні обчислення можуть бути надзвичайно складними без GC та інших видів оптимізації компілятора, таких як оптимізаційний компілятор шаблону оптимізації OCaml.

Наприклад, прочитайте цю статтю Fischbacher et al. що говорить, що "автори мають вагомі підстави вважати, що це, можливо, найбільший символічний розрахунок, проведений досі".

Фортран, з якихось хороших і не дуже хороших причин. Для важкого математичного хрускоту є вагомою причиною, що є великі бібліотеки (BLAS, LAPACK) перевірених підпрограм, всі написані у Fortran (хоча їх можна назвати з C і C ++).

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

Ще одна не дуже хороша причина - це розрив у культурі між CS та не-CS програмістами. Наукових програмістів, як правило, викладають шкідливі звички у Фортран, а також дивляться на програмістів CS та шкідливих звичок, яких вони навчали, і які дивляться на колишніх.

В основному, всі програми, які виконують фактичну роботу зі скороченням чисел, як і раніше FORTRAN (старі blas, lapack, arnoldi тощо все ще використовуються) ... Однак, коли мова йде про структуру вищого рівня ... люди все частіше використовують C ++.

Складність моделювання пов'язана з величезним кодом, і отримати будь-яку вигоду від написання - це зробити його багаторазовим. Також використовувані поняття також стали дуже складними. Це майже божевілля представляти цю інформацію за допомогою FORTRAN. Ось де C ++ заходить, оскільки він по суті підтримує об'єктно-орієнтований дизайн. Однак поліморфізм під час виконання є рідкісним. Люди натомість майже завжди використовують статичний поліморфізм (який реалізується в C ++ за допомогою метапрограмування шаблонів)

Крім того, зараз компілятори справді хороші, тому багато оптимізації залишається компіляторам.

Існує два види проблем, які необхідно вирішити в додатках HPC: одна - це число, що розкривається, а інше - управління обчисленнями. До першого зазвичай звертаються з кодом, написаним на Fortran, C або C ++ через швидкість і через те, що вже існує багато наукових алгоритмів, написаних цими мовами. Управління обчисленнями зручніше реалізується на мовах вищого рівня. Python - це "клейова" мова вибору для обробки логіки програми та розширень для викликів, реалізованих у зібраних мовах. Java часто використовується проектами, в яких важливе значення має управління мережевими та розподіленими обчисленнями.