Comments 62
🔧 Продолжение для тех, кому интересно углубиться в современный Fortran.
Я преподаю информатику и создал курс на Stepik, где подробно разбираю Fortran 2018–2023 с практическими примерами: параллельные вычисления (do concurrent, reduce), работа с массивами, оптимизация и взаимодействие с Python.
👉 Курс на Stepik: “Современный Fortran: от нуля до научных вычислений”
Сейчас также готовлю курс по Lua — как через игровые механики объяснять программирование.
В следующих публикациях на Хабре расскажу о педагогических приёмах, которые позволяют использовать разные языки для обучения алгоритмическому мышлению.
Спасибо всем, кто читает и делится мнением — ваши вопросы помогают делать курс и статьи лучше.
Это мой первый язык с которым я познакомился в университете. Делал по нему презентацию) Помню как старался все оформить красиво)
Тааак! А можно ли его сегодня где-то взять? Покрутить. (Придётся наводить справки...)
gfortran в определённых пределах отлично соответствует стандарту 2008 года. Шуршат машинки на работе, считают.
он же с gcc поставляется
gfortran, Intel fortran (ifort), у AMD есть свой актуальный компайлер.
Мне кажется, проще вот эту ссылку дать, чем по одному всё перечислять.
И, конечно же, у Cray (который теперь часть HPE) есть компайлер.
Это тут где-то был назойливый фанат Фортрана, который предлагал меряться скоростью выполнения любых задач с сишниками? Вот реально ко всем приставал.
Как-то так вышло, что в 10-11 классе нас, в физико-программистском классе, интенсивно гоняли по Pascal и Delphi. А в университете с 2006 года сразу началось погружение в FORTRAN-90 для более фундаментальных специальностей (радиофизическое и информационное направление учили C/C++), сперва курс базового программирования, потом - численных методов. И так и остался он как главный рабочий инструмент теперь. Сейчас студентов нашего физмата в базе учат на Python. Догоняю как могу, но иногда удаётся переманить кого-нибудь на темную сторону древних языков. Обычно остаются довольными.
Почему "тёмную"? Ничего нет "тёмного" в этом. "Древние" языки для того и создавались, чтобы исправно работать как лошадки. "Старый конь борозды не испортит." (с)
Лично мне не пришлось писать на Фортране, но был наслышан. Сейчас даже немного приятно: открываешь. например, книгу Марпла по спектральному анализу, а там в примерах код на Фортране! :-)
И немало разных книг таких.
У Самарского А.А. «Вычислительная теплопередача» в целом также, но с нюансом — в примерах кода задействован Фортран-77, со всеми метками и goto, ограничением на длину строк и форматирование кода. «Компьютерное моделирование в физике» Гулда и Тобочника и вовсе на Бейсике написано в основном (хотя все программы из текста продублированы на Паскале и Фортране-77 в приложениях).
Но и более современные есть. Несколько лет назад открыл для себя Булавина «Компьютерное моделирование физических систем» 2011 года издания. Она явно написана под Fortran Power Station 4.0, но в gfortran или Intel всё работает без изменений. Служит хорошим примером. Ещё и параллельные вычисления OpenMP из коробки включить можно, вообще красота.
PGI Fortran с поддержкой OpenACC для вычислений на видеокартах, возможно, поосваивал бы, да пока вот нет таких задач.
Я начинал с FORTRAN IV
EC ЭВМ
Однако все таки в современном мире надо писать такие расчеты на Julia
Тоже с него начинал где-то в 82г. Машинка была СМ-4, OS RSX-11. И, кстати, в это время не было проблем с книгами по Фортрану, во всяком случае в институтской библиотеке было несколько книг.
Зачем писать на Julia?
Если не нужно совместимость со старым кодом то лучше уж писать на современном языке
Извините, я пишу на современном Фортране, потому что мне нужна производительность, лёгкая стыковка с OpenMP и банальное удобство работы с массивами, функциями, модулями, etc. Интерпретируемые языки интересны, наверное, но мне хватает Python за глаза. Просто не понимаю, зачем мне Julia.
Julia НЕ интерпретируемый язык. Она может притворяться им (duck typing) но это достигается иными средствами (каждый вариант типов компируется при первой встрече). Julia заточена на параллелизм и производительность.
Ну вот, я не обращал внимания на эти детали, спасибо. Я как-то пытался завести код на Julia, это было давно, мне не понравилось и я тогда утвердился в мысли, что это, скорее, учебный/академический язык. Лично я просто не нахожу у Julia существенного выигрыша в производительности/сборке или в удобстве синтаксиса, поэтому и не вижу причин для перехода, но рад, что Вам этот язык помогает добиваться большего.
на мой взгляд хаскеловское
summedList = zipWith (+) list1 list2
для суммирования 2 массивов выглядит еще более нативным для математика.
а C = matmul(A, B) - вобще выглядит просто как вызов функции, что есть даже в ассемблере.
вобщем как-то неубедительно.
Только list заменить на параллелизуемый абстрактный итератор.
Согласен, Haskell действительно ближе к математической нотации — особенно в выражениях высшего порядка вроде zipWith.
Но у Fortran немного другая философия: не “чистая” функция, а вычислительная модель, максимально близкая к линейной алгебре и аппаратной реализации.
C = matmul(A, B) читается инженерами не как функция, а как “операция над массивами”, и компилятор сразу видит возможность векторизации без лишних абстракций.
В итоге это баланс между математикой и производительностью — именно то, что делает Fortran удобным в научных вычислениях.
Тоже в школе учил Паскаль, а в институте - Фортран, но как стал работат, мне,как инженеру, для расчетов основными инструментами стали математические пакеты: Matlab, Mathcad, Smath. Думаю, именно Матлаб в значительной степени вытеснил Фортран из инженерной практики. По векторной и матричной алгебре он точно не уступает Фортрану, и даже превосходит его, при этом достаточно прост в изучении.
Матлаб проприетарен и закрыт. В векторизации даже рядом не стоит.
Фортран жив по тем же причинам, что и Кобол: никто не хочет и/или не может переписывать существующий код, десятилетиями оттестированный и оптимизированный для вычислений. Да и зачем, если есть полная совместимость с C ABI? Написали врапперов для всех языков программирования и погнали. NumPy внутри дёргает Фортран. В стандартную библиотеку C++26 внесли библиотеку linalg, которая по сути биндинги для BLAS (как правило, фортрановского). Некий предел оптимизации алгоритмов уже достигнут, практической пользы от переписывания просто нет.
В научной среде Фортран сохраняется именно потому, что профы это те условные "деды", которые этот код и оптимизировали в 80х. Например, мой препод по вычислительной химии рекомендовал учить Фортран как самый важный язык для области. Так он и передается, по сути аспиранты находятся в заложниках ситуации, как, например, биоинформатики вынуждены учить R вместо Python.
"естественная запись математических формул"
Настолько ли она естественна, как например в Haskell, где буквально можно из учебника матана вставлять определения
"Python или C++ для сложения массивов требуется цикл или специальная библиотека"
Или почитать что такое ФП...
Нет, в статье написана ерунда. Дело не в "качественной записи формул", а в нативной поддержке массивов, комассивов и прочем, что позволяет идиоматически писать очень быстрый, распараллеленный отказоустойчивый код без обращения к библиотекам и с качественным управлением точностью. Это отличный язык, в вопросах массивных высокопроизводительных вычислений его не заменить, да и смысла нет в этом.
Что значит нативная поддержка массивов без обращения к библиотекам? Типа не надо писать include или что? Так то массивы обычно всегда в std... Давайте возьмём
let c: Vec<f64> = a.iter()
.zip(b.iter())
.map(|(x, y)| x + y)
.collect();Никаких внешних библиотек не нужно, это считается нативной поддержкой? По поводу безопасности, Фортран
1) молча может прочитать память за границами массива, UB
2) так же молча перекрыть диапазоны массива: REAL, DIMENSION(6) :: ARR = [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
ARR(2:5) = ARR(1:4) + ARR(3:6)
Снова UB
3) устроить гонку данных
REAL :: TOTAL = 0.0
DO I = 1, 1000
C(I) = A(I) + B(I)
TOTAL = TOTAL + C(I)
END DO
Что снова UB
В Rust все три ситуации впринципе невозможны, о каком отказоустойчивом коде мы говорим, если я навскидку дал три варианта развития событий, где можно получить UB на простом сложении массивов...
1) молча может прочитать память за границами массива, UB
А может и ошибку выдать, это зависит от компилятора и его настроек.
Пример
2) так же молча перекрыть диапазоны массива
Никакого UB тут нет, поведение для вашего примера строго определено, а результат вполне соответствует ожидаемому, потому что оператор секции при необходимости копию создаёт. Я сейчас проверил, нормально работает даже с двумя разными указателями на один массив. А вот с помощью common-блоков или оператора equivalence уже реально получится устроить ад в оперативной памяти.
3) устроить гонку данных
В вашем примере опять же гонки данных не будет, построить граф зависимостей операций компилятор вполне способен. Вот если там вместо do написать do concurrent или forall то уже начнутся проблемы. Или если у вас A, B и C не массивы, а комассивы (но тогда скобочки квадрантные нужны). Но с конкурентным доступом к данным можно и в Rust извернуться и гонку данных устроить, в Rustonomicon даже пара примеров на такой случай есть.
PS Я не утверждаю, что Fortran какой-то сильно безопасный, в сравнение с Rust там можно отстрелить себе ноги множеством способов. Но вот если сравнить его с C++, то разница будет налицо.
Оба последних варианта нужно рассматривать в OpenMP, раз вы говорите, я процитирую "распараллеленный отказоустойчивый код" у вас очевидно в один поток всё фигачило, я взял примеры конкретно известные из самой библиотеки OpenMP, посмотрите темы aliasing и data races в OpenMP, возможно я не точный код дал, а только примерный, из-за незнания нюансов самого Фортрана, но эти проблемы не я придумал, сами авторы не отрицают этих проблем, и предлагают барьеры, включите параллельность то и увидите UB
Rust код напротив распараллелится без UB
" в Rust извернуться и гонку данных устроить, в Rustonomicon даже пара примеров на такой случай есть"
В теории можно извернуться и дрелью каску на стройке просверлить и говорить что она небезопасна, только вот это нужно прямо специально стараться, случайно или по невнимательности это не выйдет, нужно прям знать что ты делаешь, компилятор rustc имеет очень хорошие сообщения об ошибках и подозрениях, он вас на этом пути много раз за руку одернет, что "чем-то вы не тем занимаетесь, посидите подумайте лучше, вот вам ссылки для размышления"
Популярность фортрана обязана множеству библиотек на питоне ориентированных на быстродействие. Думаю, многие "использовали" фортран сами того не зная, на питоне, руби и тд. Но если важно быстродействие непонятно, зачем использовать фортран, а не, например, С + библетека vector. Я имею в виду что фортран умер идейно, его смысл существования висит в воздухе. И дело не в возрасте, есть старые замечательные ЯП (например lisp), просто его идея скорости, математичности и контроля памяти бьётся более популярным и сговорчивым (да и че уж греха таить, и более синтаксически приятным) С. Ничего "против" фортрана сказать нельзя, но и также однозначно выделить "за" в сравнении с остальными ЯП на сегодняшний день нельзя
Извините, но не соглашусь в корне. Ничего более уродливого, чем нужда всё время заново придумывать массивы в очередной программе на Си, да ещё с передачей параметров по значению, я не видел. Си – крайне неудобный, хоть и полезный язык.
Справедливое замечание — многие действительно “используют” Fortran, даже не зная об этом. Но мне как преподавателю интересно, что несмотря на возраст, язык жив именно благодаря тем, кто его не бросил. Современный Fortran 2018/2023 уже другой зверь: поддержка ООП, coarrays, полная совместимость с C. Думаю, его сила сегодня — не в “ностальгии”, а в том, что он даёт студентам хороший фундамент мышления в терминах производительности и типов данных.
Буквально недавно писал код для определения видимости спутника над горизонтом – сразу писал на Фортране с использованием фортран-версии SPICE для унификации – очень доволен результатом, было крайне удобно.
Современный Фортран – нормальный, живой, бодрый и развивающийся, совершенно актуальный компилируемый язык, активно обсуждаемый и используемый за рубежом. О нем пишут много книг, проводят международные конференции, обсуждают и издают стандарты – то, что автор статьи "с удивлением обнаружил" его наличие в TIOBE говорит больше об авторе, недели о языке. Мы здесь стремительно провинциализмруемся, потому и статьи такие пишем, а мир идёт своей дорогой и использует эффективные современные инструменты не потому что "дорого переписывать" и "он в заложниках старой профессуры" – не переносите свои травмы на чужих людей, пожалуйста).
Статья о преимуществах языка программирования, в которой всего 2 (две!!) строчки кода.. вот воще неубедительно.
вышел новый стандарт Fortran 2023, добавивший условные выражения (например, a > 0 ? a : 0)
В Си тернарный оператор существует лет 50 наверное. Оперативненько.
Стандарт 2018 года ввёл объектно-ориентированное программирование
Да, турбо паскаль недавно вышел, да ;)
В Airbus инженеры по-прежнему применяют ... Python
И вы таки удивляетесь, что самолеты падают
у меня диплом был на фортране, паскаль для визуализации результатов был прикручен.
Решение системы уравнений Максвелла в СВЧ устройстве (умножитель частоты).
Для 90х других вариантов, собственно и не было (возможно и сейчас). Богатый набор проверенных библиотек, поддержка десятичных дробей, комплексных чисел.
Если не ошибаюсь, кластерные вычисления используя MPI на Фортране тоже в товарном количестве наработаны (библиотеки)
Данное обсуждение ЯП ведут две группы пользователей: программисты и вычислители, у которых сильно отличающиеся требования к ЯП. Относясь ко второй группе я, естественно, предпочитаю алгол, алгол-алфа и фортран. Мне также хотелось бы, чтобы детали, связанные и границами массивов, использованием многопоточности и т. п. брали на себя компиляторы.
Как же Вы правы! Смысл языка программирования в том и заключается, чтобы брать на себя эту ответственность.
А каким компилятором ЯП Фортран Вы пользутесь?
Очень точное наблюдение! Действительно, в инженерных задачах мышление “через компилятор” совсем иное — хочется, чтобы инструмент сам снимал часть рутины. Кстати, Fortran 2023 в этом направлении сделал шаг — do concurrent с reduce как раз снимает часть этой нагрузки. Я показываю это в своём курсе, и студентам всегда удивительно, что язык с 50-летней историей выглядит так современно.
Немного юмора про Фортран:
Помимо научно-исследовательской деятельности, нас приобщали и к педагогической деятельности. Как-то раз я читал лекции по ФОРТРАНу для слушателей-офицеров. И вот в перерыве между лекциями в курилке ко мне подходит капитан и спрашивает разрешения обратиться (я тогда был старшим лейтенантом). Я поинтересовался, что его интересует. Его ответ меня озадачил. Он сказал, что у них части, где он служил, тоже была ЭВМ, он видел пульт, видел магнитофон, ещё какие-то блоки, но он не припомнит, чтобы где-то там стоял ФОРТРАН. Тут я понял, что в лекциях надо что-то поменять и как-то более доходчиво объяснять, что ФОРТРАН (Алгол и т.д.) это не физическая вещь, а программа, которая записана на каком-то носителе. Проводить аналогию, например, с песней, которую прослушивают на магнитофоне.
Всё это происходило в конце 70-х - начале 80-х прошлого века.
Программы на Фортране раньше опережали остальные языки по производительности из-за трёх концепций. Использование значений в не ссылок, отсутствие алиасинга во многих вещах и встроенные типы. Для технологий оптимизаторов тех времён это было явное преимущество. Сейчас ситуация более менее выравнялась. Например Rust умеет четко определять алиасинг и имеет семантику перемещения. Да и современные алгоритмы оптимизации кода сводят на нет, например, наличие встроенного типа матрицы в языке.
Фортран ещё очень силён в распределенных вычислениях.
Согласен, сегодня компиляторы действительно многое сгладили — особенно с появлением Rust и продвинутого C++. Но интересно, что Fortran всё равно остаётся в числе лидеров там, где критичны именно векторизация и большие массивы данных. Его строгая модель памяти и встроенные операции с матрицами до сих пор делают жизнь оптимизаторам проще 🙂
🔧 Продолжение для тех, кому интересно углубиться в современный Fortran.
Я преподаю информатику и создал курс на Stepik, где подробно разбираю Fortran 2018–2023 с практическими примерами: параллельные вычисления (do concurrent, reduce), работа с массивами, оптимизация и взаимодействие с Python.
👉 Курс на Stepik: “Современный Fortran: от нуля до научных вычислений”
Сейчас также готовлю курс по Lua — как через игровые механики объяснять программирование.
В следующих публикациях на Хабре расскажу о педагогических приёмах, которые позволяют использовать разные языки для обучения алгоритмическому мышлению.
Спасибо всем, кто читает и делится мнением — ваши вопросы помогают делать курс и статьи лучше.
Fortran хоть и был моим первым ЯП, но с Си навсегда останется моя душа. И немного с ассемблером. И чуток с Perl-ом.
C - основа основ. Нужен более высокоуровневый - масса трансляторов в С (Vala, Nim lang и тп). Да, поначалу труднее. Но возможность контролировать и промежуточные результаты (не в специфических, часто меняющихся псевдокодах) - это плюс.
Использую Фортран в связке с f2py. Для параллелизма лучше использовать omp или вообще cuda fortran. В современный синтаксис вкатываться сильно влом. А написать пару модулей для векторных операций, которых нет в numpy, не стоит ничего. Если писать на си, код разрастается в объеме значительно, при одинаковой производительности. Но это физика. Если надо работать со строками или сокетами естественно язык мягко говоря неподходящий
Когда-то была очень актуальной связка Фортрана, естественно, с Ассемблером и ПЛ/1 (PL/1) и ПЛ-1 оптимизирующий:
Прикалывала типизация переменных по первой букве, раз назвал i, j, k - значит, это int и всё тут
Почему Fortran в 2025 году всё ещё остаётся «ракетой»