C ++ проти Fortran для HPC

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

Як часто, вибір залежить від (1) проблеми, яку ви намагаєтеся вирішити, (2) навичок, які ви маєте, та (3) людей, з якими працюєте (якщо це не сольний проект). Я покину (3) осторонь, бо це залежить від індивідуальної ситуації кожного.

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

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

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

Я думаю, що і C ++, і Fortran досить хороші і працюють добре.

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

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

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

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

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

Зауважте в наступному, що я буду говорити про C, а не C ++. Чому? Ну, інакше яблука та апельсини порівнюють повноцінний динамічно набраний об'єктно-орієнтований мову з чимось настільки статичним, як Фортран. Так, деякі сучасні впровадження останніх стандартів Fortran можуть зробити не тільки це, але дуже мало людей насправді ними користуються, і тому, коли ми говоримо про Fortran, ми думаємо просту, статичну та імперативну мову. Ось тут і С, тому я заміню C на C ++ на наступне.

По-перше, будь-яке обговорення Fortran / C, що має кращі компілятори, суперечить. Виділені компілятори C / Fortran - це минуле. І gcc / gfortran, і icc / ifc є просто різними передніми сторонами до одного і того ж бек-енду, тобто ваша програма буде перетворена на абстрактний опис фронтальним процесором, а потім оптимізована і зібрана бек-ендом. Якщо ви пишете, семантично, один і той же код у Fortran або C, компілятор в обох випадках створить ту саму збірку, яка буде працювати так само швидко.

Це тепер призводить до мого другого моменту: чому ми все ще бачимо відмінності? Проблема полягає в тому, що більшість порівнянь проводиться програмістами Fortran, які намагаються щось в C або навпаки. Ви коли-небудь помічали, як більшість авторів чи поетів вважають за краще писати рідними мовами? Чи хотіли б ви писати поезію мовою, якою ви не відчуваєте себе повністю впевнено чи вдома? Звичайно, ні ... Я сам вважаю С "моєю" рідною "мовою програмування. Однак я також три роки працював у групі, яка використовувала лише Фортран, в якій я досяг певного рівня володіння. Я б, однак, ніколи нічого не писав самостійно у Fortran, оскільки мені зручніше з C, і, як наслідок, отриманий код буде кращим , як би ви це не визначили.

Тож головна відмінність полягає в програмісті, а не в мові. Тож відмінностей немає? Ну, не зовсім. Ось кілька прикладів:

• SIMD: чи це SSE, SSE3 або AltiVec, якщо ви хочете використовувати їх у Fortran, то краще сподівайтеся і моліться, щоб компілятор вгадав саме те , що ви хочете, і робить це так. Удачі. У З зазвичай у вас є внутрішні функції для кожної архітектури, або, останнім часом, загальні типи векторних SIMD в gcc . Більшість компіляторів Fortran використовуватимуть лише інструкції SIMD для розгортання циклів, але якщо у вас є ядро, яке працює на коротких векторах даних неочевидним чином, компілятор, ймовірно, не побачить його.

• Різні апаратні архітектури: Вся архітектура CUDA побудована навколо ядер в C. Так, зараз у Portland Group є компілятор fortran, здатний на підтримку CUDA , але це комерційно, а головне, це не від NVIDIA. Те ж саме стосується OpenCL, для якого найкраще, що я міг знайти, - це недавній проект, який підтримує лише декілька основних дзвінків.

• Паралельне програмування: Так, і MPI, і OpenMP відмінно працюють як з C, так і з Fortran. Однак, якщо ви хочете реально контролювати свої потоки, тобто якщо у вас є повністю динамічні обчислення спільної пам’яті, ви не будете холодно з Fortran. У C у вас є стандартні плівки, які, хоч і не теплі і нечіткі, все одно пройдуть вас через шторм. Загалом, більшість обчислень, які покладаються на доступ до операційної системи, наприклад, потоки, процеси, файлова система тощо ..., краще обслуговувати C. О, і не намагайтеся робити власну мережу з Fortran.

• Простота використання: Fortran ближче до Matlab, ніж C. Після того, як ви ознайомитеся з усіма різними ключовими словами та як оголосити змінні, решта коду виглядає як Matlab, що робить його більш доступним для користувачів з обмеженим досвідом програмування.

• Інтероперабельність: Коли ви створюєте структуру на C, макет фактичних даних є прямим та детермінованим. У Fortran, якщо ви використовуєте масиви вказівників або структуровані дані, фактичний макет даних сильно залежить від компілятора, не прямолінійно і, як правило, повністю недокументований. Ви можете зателефонувати на C з Fortran і навпаки, але не починайте думати, що передавати щось більше, ніж статичний масив з одного на інший і назад, може бути так просто.

Це все дещо вигадливі речі низького рівня, але про це високопродуктивні обчислення, про які ми говоримо, правда? Якщо вас не цікавить, як найкраще використовувати основні апаратні парадигми, тобто реалізувати та / або розробляти алгоритми, найкращі для спільної / розподіленої пам’яті, потоків, векторизації SIMD, графічних процесорів за допомогою SIMT тощо. просто займаюся математикою на комп’ютері.

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

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

З моїх 15 років роздуму над науковим програмним забезпеченням: Якщо ваш код працює на 25% швидше, тому що ви пишете його у Fortran, але для його запису потрібно 4 рази (без STL, труднощів із застосуванням складних структур даних тощо), тоді Fortran виграє лише, якщо ви витратите значну частину дня, обертаючи великі пальці і чекаючи завершення своїх обчислень. Зважаючи на те, що майже для всіх нас найціннішим є власний час, висновок такий: використовуйте мову, яка дозволяє вам швидше розробляти, налагоджувати та перевіряти свій код, не зважаючи на те, що це може бути повільніше, ніж можливо, якщо це можливо ви написали це у Фортран.

Мій підхід полягав у тому, щоб використовувати C ++ для всього, крім обчислювальних ядер, які, як правило, найкраще записуються в збірку; це дозволяє купувати всі продуктивність традиційного підходу HPC, але дозволяє спростити інтерфейс, наприклад, перевантаживши обчислювальні ядра, такі як SGEMM / DGEMM / CGEMM / ZGEMM, в єдину процедуру, скажімо Gemm. Очевидно, що рівень абстракції можна підвищити набагато вище, уникаючи необмежених покажчиків та переходу на непрозорі класи, але це хороший перший крок.

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

Зважаючи на все сказане, я вважаю, що скасування наукових пакетів, написаних на мовах низького рівня (та Fortran), - це небажання виставляти зручні інтерфейси для складних структур даних: більшість людей задоволені інтерфейсом Fortran BLAS, оскільки цього потрібно лише покажчики та основні розміри для опису матриць, але мало хто заперечує, що звичайний 40-цілий Fortran інтерфейс розрізненого прямого вирішення - це все, що є зручним (пор. UHM, SuperLU, PETSc та Trilinos).

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

Зауважте, що цей пост призвів до цього порівняння продуктивності C і Fortran на ядрі$y := \alpha x + y$ .

Оскільки я тут новий, я переглянув старі питання і знайшов це. Сподіваємось, відповідати на старих не табу!

Оскільки ніхто інший цього не згадував, я подумав, що я. Fortran 2003 майже повністю підтримується більшістю основних компіляторів (intel, ibm, cray, NAG, PCG), навіть gcc з (найближчим часом) найновішим випуском 4.7. Fortran 2003 (і 2008) - об'єктно-орієнтована мова, хоча і дещо більш багатослівна, ніж C ++. Однією з речей, які я вважаю приємними щодо Фортран, є той факт, що стандартний комітет розглядає наукові обчислення як основну аудиторію (я дякую Даміану Русону за те, що він вказав мені це днями).

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

Одним застереженням, який я додам, є те, що коштувати бути на межі кровотоку того, що реалізовано в компіляторах. Якщо ви зараз розпочали великий проект у Fortran 2003, вам наткнуться на помилки та постійно потребуватимуть оновлення компілятора (особливо якщо ви використовуєте gcc), хоча це стало значно кращим за останні кілька місяців!

Проблема C ++ полягає в тому, що у вас є численні шанси погіршити продуктивність, наприклад, сліпо використовувати STL, винятки, класи (віртуальні накладні витрати та проблеми з вирівнюванням), перевантаження оператора (зайві нові / видалення) або шаблони (нескінченна компіляція та криптичні помилки здаються доброякісними, але ви можете витрачати години таким чином).

Однак більше ви отримуєте кращий доступ до загальних бібліотек і, можливо, бачите ваш код (хоча це сильно залежить від поля, і у вас все ще є чистий C). І ви все ще можете компенсувати відсутність гнучкості у Fortran, загорнувши його код на такій мові сценарію, як R, Lush, Matlab / Scilab або навіть Python, Ruby або Lua.

Три факти:

• N-мірний масив у стилі F77 на C: Немає проблем із використанням CnD (безсоромний штекер, правда,)

• Модульна система F90 погано розроблена і ворожа для створення середовищ. (Ім'я модуля не повинно відповідати назви файлу, наприклад)

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

Одне особисте враження:

• Fortran не працює добре для управління даними. Спробуйте повернути вказівник на непрозору структуру даних у F77 або F90. ( transfer(), ось ми прийшли)

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

Як уже згадували інші, не враховуйте динамічні інтерпретовані мови (Python et al). Вони можуть не пропонувати швидкість плавлення обличчя Fortan вперед, але вони дозволяють зосередитися більше на вирішенні вашої обчислювальної задачі, ніж на всіх деталях впровадження. Часто ви можете реалізувати рішення в Python, і якщо продуктивність неприйнятна, зробіть кілька профілів, визначте проблемні області та або оптимізуйте цей код за допомогою Cython, або повторно реалізуйте всю програму компільованою мовою. Після того, як у вас буде розроблена логіка вирішення проблем, решта - це лише реалізація, і, добре розуміючи основи обчислень, слід легко представити в будь-яких різноманітних мовах програмування.

Зараз я працюю в одному з національних лабораторій. Більшість людей навколо мене - інженери-механіки. Спілкуючись з деякими з груп HPC, вони роблять здебільшого Linux та переважно C ++. Група, в якій я зараз перебуває, в основному працює на настільних додатках, і ми використовуємо Windows у порядку зменшення: C #, FORTRAN, Python, VBA та VB (6, не .NET). Деякі симулятори, які ми використовуємо, були написані в інших національних лабораторіях у FORTRAN.

Вибачте, що викопав стару нитку, але, здається, навіть у 2015 році Fortran багато використовується.

Я щойно натрапив на цей (альтернативне посилання ) список, який в основному являє собою список з 13 кодів, затверджених засобом OCLF DOE для запуску на 300-petaFLOPS Summit-машині, яка буде доступна для дослідників у 2018 році. Я намагався знайти основну мову, що використовується для коду (на основі швидкого пошуку в Google) і ось що я знайшов:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Отже, з 13 кодів, принаймні 10 (на основі мого швидкого пошуку), здається, написані у Фортран. Непогано для мови 50 років.

ПРИМІТКА. Я добре знаю, що порівняння мов марно, але враховуючи кількість людей (особливо користувачів C ++), які непогано поживаються на Fortran, я вважав, що це варто згадати.

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

Краще питання - які приклади чудово розробленого програмного забезпечення там варто вивчити, щоб дізнатись, як розробити шаруваті програми.