Паралельна наукова комп'ютерна мова для розробки програмного забезпечення?

Я хочу розробити паралельно наукове програмне забезпечення для обчислень. Я хочу подумати, з якої мови почати. Програма передбачає читання / запис даних у файли txt і паралельні великі обчислення, з багатьма LU-факторизаціями та використанням розріджених лінійних розв'язувачів. Кандидатські рішення, про які я думав, - це Fortran 2003/2008 з OpenMP або спільним масивом, C ++ з openmp cilk + або TBB, python. Будь-які інші, задокументовані, пропозиції вітаються! Я дуже добре знаю C, Fortran та Java (у такому порядку). Я зробив деякі сценарії в python, але основні речі.

Я знаю, що Фортран дуже швидкий, але важко підтримувати і паралелізувати. Кажуть, що C ++ є повільним, якщо ви не використовуєте зовнішні бібліотеки тощо. Мені подобається Python, але чи реально написати повне масштабне програмне забезпечення промислового рівня?

Програмне забезпечення повинне вміти обробляти великі обсяги даних та бути ефективним у наукових обчисленнях. Виступ є сутнісним.

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

Петрос

Дозвольте спробувати розбити ваші вимоги:

• Технічне обслуговування
• Читання / запис текстових даних
• Міцні інтерфейси / можливості для LU-факторизації
• Рідкі лінійні розв'язувачі
• Продуктивність та масштабованість великих даних

З цього списку я розглядаю наступні мови:

C, C ++, Fortran, Python, MATLAB, Java

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

Читання / запис текстових даних

Це легко отримати правильно на будь-якій мові програмування. Переконайтеся, що ви належним чином буферизуєте та з’єднуєте доступ до вводу-виводу, і ви отримаєте хороші показники роботи з будь-якої з мов, які ви повинні врахувати. Уникайте об'єктів потоку в C ++, якщо ви не знаєте, як їх ефективно використовувати.

Міцні інтерфейси / можливості для LU-факторизації

Якщо ви виконуєте щільні фактори LU, вам потрібно використовувати паралельну функціональність LAPACK або ScaLAPACK / Elemental. LAPACK і ScaLAPACK написані у Fortran, Elemental написано на C ++. Усі три бібліотеки є працездатними та добре підтримуваними та задокументованими. Ви можете інтерфейсувати в них будь-яку з мов, які слід врахувати.

Рідкі лінійні розв'язувачі

Прем'єр вільно доступні рідкісні лінійні розв'язувачі майже всі доступні через PETSc , написаний на C, який добре задокументований та підтримується. Ви можете інтерфейсувати в PETSc з будь-якої з мов, які слід врахувати.

Продуктивність та масштабованість великих даних

Єдиними парадигмами паралельного програмування, які ви згадуєте, є спільна пам'ять, що означає, що ви не розглядаєте обчислювальний підхід на основі MPI (передачі повідомлень), розподіленої пам'яті. На мій досвід, набагато простіше написати код, який масштабує значно більше десятка ядер, використовуючи рішення з розподіленою пам'яттю. Майже всі університетські «кластери» є заснованими на MPI в наші дні, великі машини спільної пам’яті дорогі і відповідно рідкісні. Ви повинні врахувати MPI для свого підходу, але моя порада застосовуватиметься незалежно від обраної вами парадигми програмування.

Що стосується продуктивності на вузлі, якщо ви самі пишете числові процедури, найпростіше отримати хороші серійні показники у Fortran. Якщо у вас є трохи досвіду роботи з C, C ++ або Python, ви можете отримати дуже порівнянні показники роботи (C і C ++ мертві, навіть якщо Fortran, Python і MATLAB приходять приблизно за 25% накладні витрати без особливих зусиль). MATLAB робить це за допомогою компілятора JIT і дуже гарної експресивності лінійної алгебри. Ймовірно, вам потрібно буде використовувати Cython, numpy, numexpr або вбудувати числові ядра, щоб отримати заявлену продуктивність від Python. Я не можу коментувати продуктивність Java, тому що я не дуже добре знаю мову, але підозрюю, що це недалеко від Python, якщо її написав експерт.

Примітка про інтерфейси

Сподіваюся, я переконав вас, що ви зможете робити все, що завгодно, на будь-якій з мов програмування, які ви розглядаєте. Якщо ви використовуєте Java, інтерфейси C будуть трохи складними. Python має чудову підтримку інтерфейсів C та Fortran через ctypes, Cython та f2py. LAPACK вже обгорнутий і доступний через scipy. MATLAB має весь функціонал, який вам потрібен у своїх рідних бібліотеках, але його не можна легко масштабувати або особливо легко працювати на кластерах. Java може підтримувати інтерфейси C і Fortran з JNI , але зазвичай не зустрічається на кластерах і паралельному програмному забезпеченні для наукових обчислень.

Технічне обслуговування

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

Рекомендація

Особисто мені пощастило з Python, і я рекомендую його для багатьох обчислювальних проектів. Думаю, ви повинні чітко врахувати це для свого проекту. Python та MATLAB, мабуть, найбільш виразні з мов, доступних для наукових обчислень. Ви можете легко інтерфейсувати Python з будь-якою іншою мовою програмування. Ви можете використовувати f2py, щоб обернути поточну реалізацію Fortran і переписати по частинах ті частини, які ви бажаєте в Python, перевіривши, що ви підтримуєте функціональність. У цей час я рекомендував би поєднувати офіційну реалізацію Python 2.7 з scipy . Ви можете дуже легко розпочати цей стек із вільно доступного дистрибутива Enthought Python .

Ви також можете зробити більшість цього в C, C ++ або Fortran. C і C ++ є дуже привабливими мовами для професійних розробників з великим досвідом роботи, але часто відвідують нових розробників і, мабуть, у цьому сенсі не є чудовою ідеєю для більш академічного коду. Fortran та MATLAB користуються популярністю в академічних обчисленнях, але слабкі в передових структурах даних та експресивності, які пропонує Python (подумайте, наприклад, про об'єкт диктанту Python).

Пов’язані запитання:

• Рекомендації щодо корисної, швидкої бібліотеки матриць Java?

Окрім дуже вичерпної відповіді Арона, я погляну на різні теми на scicomp.stackexchange, які розглядали питання, яку мову програмування взяти - як щодо швидкості програм, так і питання про те, як легко чи важко це писати та підтримувати програмне забезпечення цими мовами.

Це, окрім написаного там, дозвольте зробити кілька зауважень:

(i) Ви включите до свого списку ко-масив Fortran. Наскільки мені відомо, кількість компіляторів, які насправді підтримують її, дуже мала - а моя, власне, нульова. Найпоширеніший компілятор Fortran - це GNU gfortran, і, хоча поточні джерела розробки аналізують підмножину ко-масивів, я вважаю, що він насправді не підтримує жодного з них (тобто він приймає синтаксис, але не реалізує жодної з семантики) . Звичайно, це загальне спостереження щодо новіших стандартів Fortran: що відставання, за допомогою якого компілятори фактично підтримують нові стандарти, вимірюється протягом декількох років - компілятори лише повністю впровадили Fortran 2003 за останні пару років, і лише частково підтримують Fortran 2008. Це не повинно перешкодити вам використовувати будь-який із них, якщо у вас є компілятор, який підтримує те, що ви використовуєте,

(ii) Те ж саме, безумовно, стосується C ++ / Cilk +: Так, Intel розробляє це на гілці GCC, але це не доступне в жодному з випусків GCC і, швидше за все, не буде деякий час. Ви можете очікувати, що це займе ще 2-3 роки, поки ви не знайдете Cilk + з версіями GCC, встановленими на типових машинах для Linux.

(iii) C ++ / TBB - це інша історія: TBB існує деякий час, має дуже стабільний інтерфейс і сумісний з більшістю будь-якого компілятора C ++, який існував протягом останніх декількох років (як на Linux, так і на Windows) . Ми використовуємо його в deal.II вже кілька років з хорошими результатами. Про це також є дуже хороша книга.

(iv) Я маю власну думку щодо OpenMP, а саме, що це рішення в пошуках проблеми. Він добре працює для паралелізації внутрішніх циклів, що може зацікавити, якщо у вас є дуже регулярні структури даних. Але це рідко, що ви хочете зробити, якщо вам потрібно щось паралелізувати - адже те, що ви насправді хочете зробити, це паралелізувати зовнішні петлі. І для цього такі рішення, як TBB, є набагато кращими рішеннями, оскільки вони використовують механізми мови програмування, а не намагаються описати те, що відбувається поза мовою (через #pragmas) і таким чином, що у вас немає доступу до ручок потоку. , показники стану результатів тощо тощо з вашої програми.

(v) Якщо ви експериментуєте, ви також можете ознайомитись з новими мовами програмування, призначеними для паралельного програмування, і, зокрема, для таких завдань, як описані вами. По суті, я би поглянув на два: X10 та Chapel . Я бачив гарні підручники на Каплиці, і це здається добре розробленим, хоча обидва, звичайно, сьогодні також є острівними рішеннями.

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

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

Cilk , безумовно, є кроком у правильному напрямку, тобто змушує вас переосмислити свою проблему / рішення в паралельній установці. Що мені в цьому не подобається, це те, що це ще одна мова . Крім того, оскільки він може лише грунтуватися на зв'язках між паралельними завданнями, планувальник може бути досить консервативним і не може бути масштабним для певних проблем.

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

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

• У Cray є компілятор, який підтримує принаймні основні функції coarray. Я використовував його для написання коду, який мав бути "навчальним", але я б сказав, що ви можете написати реальний код у coarray fortran. Синтаксис та поняття здебільшого набагато простіші, ніж MPI, але, як завжди, є лотоси лоти, а пастки відрізняються від MPI.
• Intel fortran має підтримку coarray, побудовану на базі бібліотеки MPI. Нібито це обмежує їх теоретичну пікову ефективність, але я не бачив жодної метрики.
• Gfortran підтримує coarrays, але лише для одного зображення (або одиночного рангу, в MPI говорять). Отже, реальна паралелізація не доступна, поки не вийде gfortran 4.8 або 4.9.

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

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

Логістична регресія (масштаб):

//load data to distributed memory
val points = spark.textFile(...).map(parsePoint).cache()
var w = Vector.random(D) // current separating plane
for (i <- 1 to ITERATIONS) {
  val gradient = points.map(p =>
    (1 / (1 + exp(-p.y*(w dot p.x))) - 1) * p.y * p.x
  ).reduce(_ + _)
  w -= gradient
}
println("Final separating plane: " + w)

Існує розширення, яке називається MLib (Бібліотека машинного навчання), яке використовує бібліотеку Fortran для деяких обчислень низького рівня (для Python, я думаю, використовується numpy). Отже, ідея проста, сконцентруйтеся на своєму алгоритмі та залиште оптимізацію на нижчих рівнях (порядок обробки, розподіл даних тощо).