Як можна модернізувати велику кодову базу даних, що базується на Fortran?

Друг з наукових шкіл попросив мене поради (я розробник бізнес-додатків C #).

У нього є спадщина кодова база, яку він написав у Fortran у галузі медичних зображень. Це робить величезну кількість скорочення чисел за допомогою векторів. Він використовує кластер (30ish ядер) і тепер пішов до єдиної робочої станції з 500ish GPUS.

Однак куди йти далі з кодовою базою так:

• Інші люди можуть підтримувати його протягом наступного 10-річного циклу
• Швидше налаштуйте програмне забезпечення
• Може працювати в різних інфраструктурах без перекомпіляцій

Після деяких досліджень (це дуже цікава область) деякі варіанти:

• Використовуйте Python та CUDA від Nvidia
• Перепишіть функціональною мовою. Наприклад, F # або Haskell
• Перейдіть на хмару та використовуйте щось на зразок Hadoop та Java
• Вивчіть С

Який у вас досвід з цим? На що мій друг дивиться, щоб модернізувати свою кодову базу?

ОНОВЛЕННЯ: Дякую @Mark і всім, хто відповів. Причини, з якими мій друг задає це питання, - це те, що в життєвий цикл проектів ідеальний час для перегляду. Пришвидшення асистентів досліджень у Фортран вимагає часу (мені подобається C #, а особливо інструментарій і не уявляю собі повернення до старих мов !!)

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

Дивіться Medical Imaging і хлопець, який написав обгортку Fortran для CUDA, чи можу я легально опублікувати свої обгортки Fortran 90 в бібліотеці CUFFT Nvidias (з SDK CUDA)? .

Вимоги, які ви поставили, фактично поставили Fortran на перше місце у списку для таких проблем:

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

Це також мова, яку неймовірно легко підібрати. Я не згоден, що потрібен час для швидкого залучення асистентів. У моєму першому підручнику було більше, ніж, о, я не знаю, 30 (?) Сторінок розрідженого друкованого тексту. Це мова, якою після вивчення 10 ключових слів можна писати програми середнього розміру. Я б наважився сказати, що ці 30 сторінок, написані текстом Word за замовчуванням, становлять більш, ніж вичерпний "посібник з Fortran" для більшості користувачів.

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

Крім того, для паралельних програм у вас є доступні OpenMP, MPI і тепер майбутні (і довгоочікувані) спільні масиви, які недавно реалізував компілятор Intel . Щоб не витрачати слова, Fortran має дуже тонку гаму "бібліотек" для паралельних програм.

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

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

ps Що стосується "майбутнього технічного обслуговування", це лише анегдот, який я іноді люблю згадувати. Під час написання дисертації я повторно використовував деякий код свого наставниці, написаний 35 років тому з часу написання. Вона складена лише з однією помилкою; заява відсутня в кінці, через помилку копіювання вставити :)

@DaveMateer (відповідь на коментар) - Я збираюся зробити коментар у наступному, який може бути трохи неввічливим, але, будь ласка, не сприймайте це неправильно, бо це в справедливих намірах.

Мені здається, ти вирішуєш цю "проблему" неправильно. Що я маю на увазі в декількох коротких моментах (бо тут дуже пізно, і моя здатність складати читабельні (не кажучи вже про зрозумілі) речення залишає мене після 22:00)

а) Ви згадали, що намагаєтеся мінімізувати додатковий час кодування, але ви розглядаєте можливість переписати мову, спеціалізовану для чисельних обчислень, на одну з кольорового вибору мов , якщо ви будете пробачити моє вираження

• деякі з яких, крім іншого, не підтримують багатовимірні масиви
• більшість із них непридатні для важкої чисельної роботи (про паралельну обробку можливостей Haskell і Hadoop, я визнаю, я нічого про це не знаю ... але ніколи не чув їх, навіть згаданих у цих колах)
• це, можливо, було випробувано, але я ніколи не чув про переписання з Fortran, мови для дискретних проблем, на функціональну мову
• нещодавно на comp.lang.fortran (спробуйте пошукати групи Google) було обговорено аспекти наукових обчислень "у хмарі"
  (не хотілося б вас де-мотивувати, але якщо чесно, ніхто насправді не був впевнений, що цей термін навіть представляє, менше поодинці мали приклад успішного застосування. Більшість людей погодились, що потенціал існує, але поки що вони щасливі, як зараз це працює.) Дуже багато проблем не підходять для такої паралелізації.

б) які були б витрати на таке переписування? людей / год.

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

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

Фу, якщо я придумаю щось інше, додамо це завтра. Треба поспати ...

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

Тож я б сказав, що вам слід чітко відокремити числову частину, залишити її у Фортран, зробити чітке прив’язування і написати інше все, що вам завгодно.

Python дійсно набирає великої тяги в науковому обчислювальному співтоваристві (для дещо застарілого погляду див. Том 9 № 3 CiSE ). Я думаю, що гібрид Python / Fortran - це відмінний шлях. Щоб скористатися всіма цими графічними процесорами, ви можете використовувати PyCUDA або PyOpenCL .

Я математик, який аналізує і записує числові розв'язки для часткових диференціальних рівнянь. Я нещодавно опинився в подібній ситуації до вашого друга; Код Fortran 77, про який йде мова, є добре відомим програмним забезпеченням Clawpack . Ми переписали код верхнього рівня (всі частини, які не потребують швидкої роботи) в Python, і використовували f2py для автоматичного загортання деталей низького рівня.

Дійсно потужним результатом цього є те, що нам тоді вдалося майже тривіально з'єднати гібридний код Python / Fortran ( охрещений PyClaw ) з паралельною бібліотекою PETSc, створивши вперше масштабовану паралельну версію Clawpack, яка добре працює на 65K ядрах. Весь паралельний код, який нам довелося написати, міститься у менш ніж 300 рядках Python . Зараз ми вирішуємо проблеми, які неможливо було вирішити лише за допомогою застарілого коду. Що також важливо, новим користувачам зараз набагато простіше підібрати код, оскільки Python - це така доброзичлива мова, і майже все можна змінити під час виконання, а не під час компіляції.

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

Вибачте за саморекламу, але здавалося, що мій особистий досвід тут буде доречний. Якщо ви хочете почути ще багато ідей, можете опублікувати це також на новому http://scicomp.stackexchange.com .

На даний момент я переживаю ситуацію, дуже схожу на ситуацію вашого друга. Я також відчайдушно бажаю "модернізувати" мій спадщинний код KLOC Fortran-77, що становить 40 штук. І незважаючи на те, що Фортран і досі вважається королем у ряді заявок на хрускіт, я хотів би сказати, що все не втрачено. (Далі йде рент-іш, тож потерпіть мене).

Тільки тому, що Fortran є найкращою мовою для цифрового коду, це не означає, що ми повинні постійно носити з собою цей величезний багаж безладного, складного коду (Так, код Fortran повинен бути безладним, особливо Fortran-77, який є мова, яка буквально не стосується програмного забезпечення, коли вона перетинає певні KLOC). Ті, хто виступає за Фортран за скорочення чисел, забувають загальне зауваження, що, коли ви робите аналіз продуктивності таких кодів, це лише 5% або 10% коду, який інтенсивно працює, а для решти 90% + Fortran - марний накладні витрати, просто там, щоб зробити ваше життя "програмним інженером" життям пеклом.

Коли ви переходите до Fortran-90 з Fortran-77, ви, по суті, готові до певної міри компромісні характеристики з мовними особливостями. Фортран - це потужний кронштейн чисельності насамперед завдяки Фортран-77. Можна сказати, що Fortran-90 настільки швидкий, але з типом проблем оптимізації, з якими стикалися письменники-компілятори, додаючи функції Fortran-90/2003 та зберігаючи продуктивність Fortran-77, не сильно відрізняється від питань, з якими довелося вирішувати сценаристів C з (і в результаті C також вважається швидким, не кажучи вже про те, що C дозволяє також вбудовувати рядки). То чому б не почати додавати код C побітно (замість Fortran-90) у код Fortran-77. У мого коду вже є шматки в С та шматки у Fortran-77, і він чудово працює при деяких питаннях, таких як проходження рядків, нульова індексація / одноіндексація тощо. Але перевага, яку я отримую від C,

Я б пішов на крок далі. Навіть C (і, безумовно, Fortran-90/95/2003) є занадто низьким рівнем, якщо ви хочете приємного "гуманного" інтерфейсу до коду, що розсипає номер. Я думаю про перехід на Python-Fortran-77 або гібрид Python-C. Код, у якому 90% коду становить Python (включаючи Numpy, Scipy, plotability і всю цю солодкість), і лише інтенсивна продуктивність 5% -10% залишається як Fortran-77 або C код.

На даний момент я оновлюю стару базу коду FORTRAN95 для використання в сучасних галузевих середовищах, оскільки попередня версія буде працювати лише на машинах Windows2000. Сама кодова база FORTRAN виконує велику кількість стискання кількості, пов'язане з імітацією зрошення.

Отож, що я роблю, це замість того, щоб переписати FORTRAN на більш сучасній мові, я просто використовую комерційний компілятор під назвою Silverfrost FTN95 для компіляції бази коду FORTRAN до бібліотеки .Net 4.0, яку я використовую як резервний додаток WPF . Таким чином, я не ризикую включити відомі помилки в код імітаційного моделювання, і я модернізую його, перемістивши кодову базу в рамку .Net 4.0, щоб вона працювала на більш сучасних умовах.

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

Сподіваюся, мій досвід допомагає, Спасибі, Алекс.

Я був провідним розробником проекту 2001-2003 років, який переніс програму Windows 100KLOC від FORTRAN до C #. Це було декілька додатків для стискання, який мав власні графічні прив’язки GUI до бібліотек Win32. Порт на C # і WinForms зробив управління кодом набагато простішим і дав усім багатше середовище розробки у Visual Studio. Рано було чимало опору (особливо з точки зору форматних заяв), але врешті-решт, це було, безумовно, варто.

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

Іншою причиною цього є, звичайно, довгострокова доступність людей із досвідом FORTRAN, які можуть підтримувати ваш код порівняно з розробниками C #. Крім того, це допомагає моральній команді працювати сучасною, добре підтримуваною мовою.

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