Почему физики всё ещё используют Fortran

http://www.moreisdifferent.com/2015/07/16/why-physicsts-still-use-fortran/
  • Перевод
Не знаю, как будет выглядеть язык программирования в 2000-м году, но я знаю, что называться он будет FORTRAN.
— Чарльз Энтони Ричард Хоар, ок. 1982

В индустрии Fortran сегодня используется редко – в одном из списков популярных языков он оказался на 28-м месте. Но Fortran всё ещё главный язык для крупномасштабных симуляций физических систем – то есть для таких вещей, как астрофизическое моделирование звёзд и галактик (напр. Flash), крупномасштабной молекулярной динамики, коды подсчёта электронных структур (SIESTA), климатические модели, и т.п. В области высокопроизводительных вычислений, подмножеством которых являются крупномасштабные числовые симуляции, сегодня используются лишь два языка – C/C++ и «современный Fortran» (Fortran 90/95/03/08). Популярные библиотеки Open MPI для распараллеливания кода были разработаны для двух этих языков. В общем, если вам нужен быстрый код, работающий на нескольких процессорах, у вас есть только два варианта. В современном Fortran есть такая особенность, как "coarray", позволяющая прямо в языке работать с параллельным программированием. Coarray появились в расширении Fortran 95, а затем были включены в Fortran 2008.

Активное использование Fortran физиками часто приводит в замешательство специалистов по информатике и других не связанных с этой областью людей, которым кажется, что Fortran – исторический анахронизм.

Я хотел бы объяснить, почему Fortran всё ещё остаётся полезным. Я не призываю изучающих физику студентов учить Fortran – поскольку большинство из них будут заниматься исследованиями, им лучше заняться изучением C/C++ (или остановиться на Matlab/Octave/Python). Я хотел бы пояснить, почему Fortran всё ещё используется, и доказать, что это не только из-за того, что физики «отстают от моды» (хотя иногда это так и есть – в прошлом году я видел студента-физика, работавшего с кодом Fortran 77, при этом ни он, ни его руководитель ничего не слышали про Fortran 90). Специалисты по информатике должны рассматривать преобладание Fortran в числовых вычислениях как вызов.

Перед тем, как углубиться в тему, я хочу обсудить историю, поскольку, когда люди слышат слово «Fortran», они сразу представляют себе перфокарты и код с пронумерованными строками. Первая спецификация Fortran была написана в 1954 году. Ранний Fortran (тогда его название писалось заглавными буквами, FORTRAN), был, по современным меркам, адским языком, но это был невероятный шаг вперёд от предыдущего программирования на ассемблере. На FORTRAN часто программировали при помощи перфокарт, как об этом без удовольствия вспоминает профессор Мириам Форман из университета Стони Брук. У Fortran было много версий, самые известные из которых – стандарты 66, 77, 90, 95, 03 и 08.

Часто говорят, что Fortran до сих пор используют из-за его скорости. Но самый ли он быстрый? На сайте benchmarksgame.alioth.debian.org есть сравнение C и Fortran в нескольких тестах среди многих языков. В большинстве случаев Fortran и C/C++ оказываются самыми быстрыми. Любимый программистами Python часто отстаёт в скорости в 100 раз, но это в порядке вещей для интерпретируемого кода. Python не подходит для сложных числовых вычислений, но хорошо подходит для другого. Что интересно, C/C++ выигрывает у Fortran во всех тестах, кроме двух, хотя в целом по результатам они мало отличаются. Тесты, где Fortran выигрывает, наиболее «физические» – это симуляция системы из n тел и расчёт спектра. Результаты зависят от количества ядер процессора, например, Fortran немного отстаёт от C/C++ на четырёхъядерном. Тесты, в которых Fortran сильно отстаёт от C/C++, большую часть времени занимаются чтением и записью данных, и в этом отношении медлительность Fortran известна.

Так что, C/C++ настолько же быстрый, насколько Fortran, а иногда и немного быстрее. Нас интересует, «почему профессора физики продолжают советовать своим студентам использовать Fortran вместо C/C++?»

У Fortran есть унаследованный код


Благодаря долгой истории Fortran, неудивительно, что на нём написаны горы кода по физике. Физики стараются минимизировать время на программирование, поэтому, если они найдут более ранний код, они будут его использовать. Даже если старый код неудобочитаемый, плохо документированный и не самый эффективный, чаще использовать старый проверенный, чем писать новый. Задача физиков – не писать код, они пытаются понять природу реальности. У профессоров унаследованный код всегда под рукой (часто этот код они сами и писали десятилетия назад), и они передают его своим студентам. Это сохраняет их время и удаляет неопределённости из процесса устранения ошибок.

Студентам-физикам изучать Fortran легче, чем C/C++


Я думаю, что изучать Fortran легче, чем C/C++. Fortran 90 и C очень похожи, но на Fortran писать проще. C – язык сравнительно примитивный, поэтому физики, избирающие себе C/C++, занимаются объектно-ориентированным программированием. ООП может быть полезным, особенно в крупных программных проектах, но изучать его гораздо дольше. Нужно изучать такие абстракции, как классы и наследование. Парадигма ООП очень отличается от процедурной, используемой в Fortran. Fortran основан на простейшей процедурной парадигме, более приближенной к тому, что происходит у компьютера «под капотом». Когда вы оптимизируете/векторизуете код для увеличения скорости, с процедурной парадигмой легче работать. Физики обычно понимают, как работают компьютеры, и мыслят в терминах физических процессов, например, передачи данных с диска в RAM, а из RAM в кэш процессора. Они отличаются от математиков, предпочитающих размышлять в терминах абстрактных функций и логики. Также это мышление отличается от объектно-ориентированного. Оптимизация ООП-кода более сложна с моей точки зрения, чем процедурного. Объекты – очень громоздкие структуры по сравнению со структурами данных, предпочитаемыми физиками: массивами.

Лёгкость первая: работа Fortran с массивами


Массивы, или, как их зовут физики, матрицы, находятся в сердце всех физических вычислений. В Fortran 90+ можно найти много возможностей для работы с ними, схожих с APL и Matlab/Octave. Массивы можно копировать, умножать на скаляр, перемножать между собой очень интуитивным образом:

A = B
A = 3.24*B
C = A*B
B = exp(A)
norm = sqrt(sum(A**2))

Здесь, A, B, C – массивы некоторой размерности (допустим, 10x10x10). C = A*B даёт нам поэлементное перемножение матриц, если A и B одного размера. Для матричного умножения используется C = matmul(A,B). Почти все внутренние функции Fortran (Sin(), Exp(), Abs(), Floor(), и т.д.) принимают массивы в качестве аргументов, что приводит к простому и чистому коду. Похожего кода в C/C++ просто нет. В базовой реализации C/C++ простое копирование массива требует прогона for циклов по всем элементам или вызова библиотечной функции. Если скормить массив не той библиотечной функции в С, произойдёт ошибка. Необходимость использования библиотек вместо внутренних функций означает, что итоговый код не будет чистым и переносимым, или лёгким в изучении.

В Fortran доступ к элементам массива работает через простой синтаксис A[x,y,z], когда в C/C++ нужно писать A[x][y][z]. Элементы массивов начинаются с 1, что соответствует представлениям физиков о матрицах, а в массивах C/C++ нумерация начинается с нуля. Вот ещё несколько функций для работы с массивами в Fortran.

A = (/ i , i = 1,100 /)
B = A(1:100:10)
C(10:) = B

Сначала создаётся вектор A через подразумеваемый цикл do, также известный, как конструктор массивов. Затем создаётся вектор B, состоящий из каждого 10-го элемента А, при помощи шага в 10. И, наконец, массив B копируется в массив С, начиная с 10-го элемента. Fortran поддерживает объявления массивов с нулевыми или отрицательными индексами:

double precision, dimension(-1:10) :: myArray

Отрицательный индекс сначала выглядит глупо, но я слышал об их полезности – например, представьте, что это дополнительная область для размещения каких-либо пояснений. Fortran также поддерживает векторные индексы. Например, можно передать элементы 1,5 и 7 из массива A размерностью N x 1 в массив B размерностью 3 x 1:

subscripts = (/ 1, 5, 7 /)
B = A(subscripts)

Fortran поддерживает маски массивов во всех внутренних функциях. К примеру, если нам нужно посчитать логарифм всех элементов матрицы, больших нуля, мы используем:

log_of_A = log(A, mask= A .gt. 0)

Или мы можем в одну строку обнулить все отрицательные элементы массива:

where(my_array .lt. 0.0) my_array = 0.0

В Fortran легко динамически размещать и освобождать массивы. К примеру, для размещения двумерного массива:

real, dimension(:,:), allocatable :: name_of_array
allocate(name_of_array(xdim, ydim))

В C/C++ для этого требуется следующая запись:

int **array;
array = malloc(nrows * sizeof(double *));
 
for(i = 0; i < nrows; i++){
     array[i] = malloc(ncolumns * sizeof(double));
}

Для освобождения массива в Fortran

deallocate(name_of_array)

В C/C++ для этого

for(i = 0; i < nrows; i++){
    free(array[i]);
}
free(array);

Лёгкость вторая: не нужно беспокоиться об указателях и выделении памяти


В языках вроде C/C++ все переменные передаются по значению, за исключением массивов, передающихся по ссылке. Но во многих случаях передача массива по значению имеет больше смысла. Например, пусть данные состоят из позиций 100 молекул в разные периоды времени. Нам необходимо анализировать движение одной молекулы. Мы берём срез массива (подмассив) соответствующий координатам атомов в этой молекуле и передаём его в функцию. В ней мы будем заниматься сложным анализом переданного подмассива. Если бы мы передавали его по ссылке, переданные данные не располагались бы в памяти подряд. Из-за особенностей доступа к памяти работа с таким массивом была бы медленной. Если же мы передадим его по значению, мы создадим в памяти новый массив, расположенный подряд. К радости физиков, компилятор берёт на себя всю грязную работу по оптимизации памяти.

В Fortran переменные обычно передаются по ссылке, а не по значению. Под капотом компилятор Fortran автоматически оптимизирует их передачу для повышения эффективности. С точки зрения профессора в области оптимизации использования памяти компилятору стоит доверять больше, чем студенту! В результате физики редко используют указатели, хотя в Fortran-90+ они есть.

Ещё несколько примеров отличий Fortran и C


В Fortran есть несколько возможностей для управления компилятором при поиске ошибок и оптимизации. Ошибки в коде можно отловить на этапе компиляции, а не при выполнении. К примеру, любую переменную можно объявить как параметр, то есть константу.

double precision, parameter :: hbar = 6.63e-34

Если параметр в коде меняется, компилятор возвращает ошибку. В С это называется const

double const hbar = 6.63e-34

Проблема в том, что const real отличается от простого real. Если функция, принимающая real, получит const real, она вернёт ошибку. Легко представить, как это может привести к проблемам функциональной совместимости в коде.

В Fortran также есть спецификация intent, сообщающая компилятору, является ли передаваемый в функцию аргумент входным, выходным, или одновременно входным и выходным параметром. Это помогает компилятору оптимизировать код и увеличивает его читаемость и надёжность.

В Fortran есть и другие особенности, используемые с разной частотой. К примеру, в Fortran 95 есть возможность объявлять функции с модификатором pure [чистый]. У такой функции нет побочных эффектов – она меняет только свои аргументы, и не меняет глобальные переменные. Особым случаем такой функции служит функция elemental, которая принимает и возвращает скаляры. Она используется для обработки элементов массива. Информация о том, что функция pure или elemental, позволяет компилятору проводить дополнительную оптимизацию, особенно при распараллеливании кода.

Чего ждать в будущем?


В научных подсчётах Fortran остаётся основным языком, и в ближайшее время исчезать не собирается. На опросе среди использующих этот язык посетителей конференции «2014 Supercomputing Convention» 100% из них сказали, что собираются использовать его в ближайшие 5 лет. Из опроса также следует, что 90% использовали смесь из Fortran и C. Предвидя увеличение смешивания этих языков, создатели спецификации Fortran 2015 включают в неё больше возможностей для функциональной совместимости кода. Код Fortran всё чаще вызывается из кода на Python. Специалисты по информатике, критикующие использование Fortran, не понимают, что этот язык остаётся уникально приспособленным для того, в честь чего он был назван — FOrmula TRANslation, перевода формул, то есть, преобразования физических формул в код. Многие из них не догадываются, что язык развивается и постоянно включает всё новые возможности.

Называть современный Fortran 90+ старым, это всё равно, что называть старым C++, из-за того, что C разработали в 1973. С другой стороны, даже в самом новом стандарте Fortran 2008 существует обратная совместимость с Fortran 77 и большей частью Fortran 66. Поэтому разработка языка сопряжена с определёнными трудностями. Недавно исследователи из MIT решили преодолеть эти трудности, разработав с нуля язык для HPC по имени Julia, впервые вышедший в 2012 году. Займет ли Julia место Fortran, ещё предстоит увидеть. В любом случае, подозреваю, что это будет происходить очень долго.
Поделиться публикацией

Комментарии 125

    0
    Интересно, а бывает Visual Fortran? :)
      0
      Погуглите, на первой странице результатов поиска я много интересного нашел.
        0
        Действительно…
        0
        https://habrahabr.ru/post/202680/
        +5
        Насколько я понимаю, важнейшее достоинство фортрана — на нём уже очень давно написано большинство необходимых в физике/квантовой химии etc. алгоритмов.
          0
          Это в том числе. Но Фортран сам по себе очень приятный язык, сделанный для людей, без этих монструзных конструкций, так свойственным современным мейнстримовым языкам. Там уже куча всего из под коробки и оно отлично работает, не надо ломать голову над никому не нужным синтаксическим сахаром.
          Ну и интересный момент — ни раз бывало, что фортрановский скомпилированный код получался на 5-10% быстрее кода на Си, при этом компилятор то один и тот же (интеловский)… ну т.е. для того что бы получить такой же быстрый код на Си надо серьезно поизвращаться.

          Вот и получается, что по соотношению затраты/производительность, Фортран оказывается самым оптимальным. За бугром (особенно в США) он куда более распространен чем в РФ (в РФ я бы сказал про него почти никто не знает)
            0
            В РФ компьютеры появились немного позже того, как Фортран утратил популярность.
            А вообще человек, если он не занимается программированием профессионально — не склонен учить новый язык.
            Так что язык уйдёт не раньше чем изучившее его поколение.
          –2
          Здесь, A, B, C – массивы некоторой размерности (допустим, 10x10x10). C = A*B даёт нам поэлементное перемножение матриц, если A и B одного размера. Для матричного умножения используется C = matmul(A,B). Почти все внутренние функции Fortran (Sin(), Exp(), Abs(), Floor(), и т.д.) принимают массивы в качестве аргументов, что приводит к простому и чистому коду. Похожего кода в C/C++ просто нет.
          А почему автор оригинала умалчивает о возможности введения классов и переопределении операторов в C++, с помощью которых можно записать векторные и матричные вычисления таким же простым и чистым кодом?
            +8
            Он упирает на то, что в Fortran это уже и так работает, и что физики стараются поменьше программировать и побольше заниматься физикой.
              +13

              Потому, что в C++ всё это можно сделать тысячей способов, разница в производительности которых может достигать нескольких порядков.
              Компиляторы фортрана же предлагают достаточно производительное, унифицированное и простое в использовании решение из коробки.


              Например вы можете дать коллеге код на фортране и он сразу же заработает. Можете найти на старой ленте программу написанную неизвестно кем в 1970-х и она скомпилируется с кучей ворнингов, но выдаст точный результат.


              C/C++ — более универсальный вариант. Вы можете использовать одну из тысяч библиотек, или написать свой велосипед. Но будьте готовы, что у вашего друга интеграция вашего кода может занять некоторое время потому что используемые библиотеки, их версии, или формат хранения могут быть несовместимы.


              Потому, с точки зрения представления алгоритмов, программы на фортране в разы более переносимы чем на любом другом языке. Язык развивался все эти годы именно в этом направлении и это работает.

                –2
                А для C++ разве нельзя найти уже готовую «коробку» с хорошей производительностью и переносимостью? Чтобы без велосипеда…
                  +7

                  Конечно можно. Но у вашего коллеги из другой организации эта коробка будет другой.
                  И согласно законам Мерфи, она будет несовместима с вашей.

                  • НЛО прилетело и опубликовало эту надпись здесь
                      –1
                      Хорошо, что на Javascript никому еще не пришло в голову программировать алгоритмы. Потому что в Javascript для любой проблемы есть минимум 10,000 готовых библиотек, из которых 9,999 считаются устаревшими и немодными, а 1 ­— является слишком новой и продвинутой, и потому ни с чем другим (включая существующие среды исполнения).
                        0
                        У меня студент как-то обработку изображений на NodeJS делал. На вопрос «почему» ответил, что хочет просто получить опыт программирования на JS. Кстати, не так уж и медленно работало.
                          0
                          Если вспомнить, что NodeJS работает на V8, который сначала компилирует код в нативный, это не удивительно. Но до эффективности C/C++ этой платформе, естественно, далеко.
                      +1
                      С++ с хорошей переносимостью — это Java.
                      Относительно производительности С++ и Java — это такой огромный холивар.
                        0
                        мне кажется, Java и C++ вообще некорректно сравнивать по критерию переносимости — не в этом между ними разница. Если всё же попытаться, то выходит, что есть целая куча платформ, на которых C++ код работает, а Java — нет (все, на которых не JVM), но не наоборот. Да и писать переносимый C++ код вообще не сложно, скорее наоборот, написать непереносимый C++ код — нужно ещё постараться.
                          0
                          Работать код С++ может и работает вот только тут важнее то чтоб код абсолютно одинаково работал. И здесь мы упираемся в различия архитектуры.
                            0
                            Java код не будет абсолютно одинаково работать на разных архитектурах, так что тут у Java тоже не превосходит C++. Что бы java-код работал абсолютно одинаково, нужно его писать специальным образом — эта опция доступна и для C++.
                              0
                              Я не буду устраивать холивары, но Java изначально создавалась именно с целью создания переносимых приложений.
                                0
                                Да, это была красивая идея, но она не сработала. Тем не менее Java всё равно стала успешной платформой, в основном заслуженно.
                      –1
                      У фортратна была в науке (физике) своя ниша, но сейчас, на практике, по моим наблюдениям новый код никто (в физике) на fortran не пишет, да и старый даже иногда на C/C++ переписывают.
                        +3
                          +1
                          Ваша ссылка сама по себе не говорит не о чём. За ВСЕ пакеты для квантовой химии сказать не могу, но вот например популярнейший Gaussian написан в 1970м. CPMD и CP2K — 2000 год. Вся физическая школа связанная с разработкой QM софта сформировались в 70е годы, отсюда и фортран. Это не новый софт. Огромное количество опыта и кода накопленного в этой области исторически связанно с фортраном. Вопреки этому, новые проекты все больше пишут на C++/C. Даже новые модули старых проектов, бывает, пишут на C++. Например PSI переписали с Fortran на С++. ORCA, котрая была написана сравнительно недавно, более молодым поколением учёных — написана на C++.
                            0
                            ABLA07 (внутри INCLXX) до сих пор на fortran. Переписывать некому. Предыдущую модель каскада (ABLAXX) да, переписали на C++, она и работает в том же Geant4. Последние изменения в коде ABLA07 — от 2015 года. К ней написан C++ интерфейс, чтобы фортрановские функции вызывать из C++, и всё.
                          0

                          Центральный институт авиационного моторостроения имени П.И. Баранова. Математические модели двигателей (причем не древних, а вполне себе актуальных и перспективных) написаны и пишутся на фортране, многое еще на 77.

                            0
                            Посмотрите, например, в сторону SNEC (http://stellarcollapse.org/snec). Симулятор вспышек сверхновых, появилась она всего 2-4 года назад. MESA, которая моделирует эволюцию звёзд, тоже на фортране, емнип, и тоже довольно-таки «молодая»
                      • НЛО прилетело и опубликовало эту надпись здесь
                          +5
                          Ого!
                          Как много я не знал о Фортране! Это я про матричные операции.
                          Фортран был в институте, но я его забросил в пользу Си.
                          Сейчас всерьез задумался — а не вернуться ли?
                          И даже есть книжки по Куде оказывается.
                          (Загуглил — нашел «CUDA FORTRAN ДЛЯ УЧЕНЫХ И ИНЖЕНЕРОВ»).
                          В общем ничего не мешает попробовать.
                          Спасибо за статью!
                          mirsev
                          возможности введения классов и переопределении операторов в C++,
                          Как ни грустно — шикарные возможности С++ используются крайне мало.
                          Вокруг почти все (научные сотрудники-физики) пишут разные программы обработки данных или расчетов на чистом С, не используя плюс-плюсовские плюшки.
                          Есть конечно библиотеки типа Blitz++, но ими тоже далеко не все пользуются. Почему? Ну потому что чего там… циклы есть, условия есть, массивы есть. Всё. Что еще надо от языка? )))
                          — Еще одна мысль — научные программы не предполагают длительного использования. Т.е. мы хотим что-то рассчитать — быстренько написали, посчитали, написали статью — можно переходить к новой задаче, а этот код или забросить или модифицировать под новую задачу. Т.е. типичная научная программа не предполагает долгого обдумывания структуры, а значит парадигма велосипедно-костыльного программирования оказывается вполне жизнеспособной.
                          — Бывают исключения — находятся герои которые минимальным коллективом создают программные комплексы которые могут соперничать с программами-монстрами типа Fluent, CFX, Comsol, и т.п… Потом этими программами пользуются разные научные группы. Но в этих коллективах как правило люди сильно уклонились от физики в сторону программирования.
                            0
                            Когда-то давно приходилось для физических расчетов оптимизировать сишную программу и разбираться в том какой код генерит компилятор для сопроцессора плавающей точки. Последующая ручная оптимизация помогла ускорить расчет в разы. Интересно было бы узнать дают ли свойства фортрана какие-то преимущества для оптимизации бинарного кода компилятором.
                              +3
                              Например по дефолту фортран считает, что массивы не могут пересекаться и лучше оптимизирует. Для получения такого же эффекта в C надо вручную расставлять restrict перед поинтерами, или #pragma omp simd перед циклами.
                                0
                                В случае GCC
                                #pragma GCC ivdep
                                
                              –8
                              Для матричного умножения используется C = matmul(A,B)

                              Автор, ты хоть смотрел в эти исходники? Подсказка: используют ZGEMM хоть в фортране хоть в Си. И да, программы на C физики тоже пишут.
                              В Fortran доступ к элементам массива работает через простой синтаксис A[x,y,z], когда в C/C++ нужно писать A[x][y][z]. Элементы массивов начинаются с 1, что соответствует представлениям физиков о матрицах, а в массивах C/C++ нумерация начинается с нуля.

                              Ну да, если так записать 3-тензор (как массив массивов ссылок), то его ни одна библиотека с линейной алгеброй (LAPACK,BLAS) ни MPI не примет. Физики, которые их используют, конечно, не в курсе чем *double лучше ***double. (Сарказм)
                              Под капотом компилятор Fortran автоматически оптимизирует их передачу для повышения эффективности.

                              Ага, конечно, только маленькое НО:
                              В Fortran также есть спецификация intent, сообщающая компилятору, является ли передаваемый в функцию аргумент входным, выходным, или одновременно входным и выходным параметром. Это помогает компилятору оптимизировать код и увеличивает его читаемость и надёжность.

                              Да, нужно сообщить компилятору, будешь ли ты изменять массив и нужно ли его обнулять (IN,OUT,INOUT). А в C ты явно пишешь memcpy. Такие дела.

                              В общем, я не слышал ни об одном случае, чтобы современные студенты писали свои проекты на Fortran. Вся статья ИМХО высосана из пальца. Это я как человек, который так и не осилил Fortran говорю.
                                +3
                                В общем, я не слышал ни об одном случае, чтобы современные студенты писали свои проекты на Fortran.


                                например, в ЦАГИ
                                  +4
                                  в мфти, например, фортран вполне себе живет и используется
                                  это я как студент мфти говорю
                                  P.S. сам пишу на фортране
                                    +2
                                    The University of Texas at Austin, Computational Electromagnetics group.

                                    Код для решения уравнений Максвелла (интегральная формулировка)
                                    Сам использую Fortran, конечно больше по историческим причинам. Часть кода нашей группы ведет историю со стародавних времен. Местами плююсь, местами радуюсь синтаксису языка.

                                    До этого использовал C++. Примерно так же, местами плевался, местами радовался.
                                    Но как только приходится много работать с матрицами и тензорами — Fortran просто чудо. Он действительно интуитивен и понятен. В C++ близко подходит только Eigen template library, однако это все равно не настолько удобно. И требуется регулярно обновлять библиотеку, в которой есть проблемы, особенно когда используется OpenMP/MPI.

                                    На современном Fortran можно писать красивый и удобочитаемый код, однако, это не происходит потому что хорошие программисты редко программируют на Fortran, и даже примеров хорошего кода не так много, несмотря на то, что возможности к такому в синтаксисе языке присутствуют.
                                    0
                                    Вот так я впервые узнал, что у фортрана бывает куча и можно аллоцировать память. Мне всю жизнь хватало статически выделенной памяти.
                                      –2
                                      Студентам-физикам изучать Fortran легче, чем C/C++

                                      Я думаю, что изучать Fortran легче, чем C/C++. Fortran 90 и C очень похожи, но на Fortran писать проще. C – язык сравнительно примитивный, поэтому физики, избирающие себе C/C++, занимаются объектно-ориентированным программированием. ООП может быть полезным, особенно в крупных программных проектах, но изучать его гораздо дольше. Нужно изучать такие абстракции, как классы и наследование. Парадигма ООП очень отличается от процедурной, используемой в Fortran. Fortran основан на простейшей процедурной парадигме, более приближенной к тому, что происходит у компьютера «под капотом».

                                      Слухи о сложности ООП сильно преувеличены. Этому можно научить любую, извините, макаку. И успешно учат. А уж физики-то поумнее будут среднестатистического кодера. Напоминаю, что речь о студентах, а не об одногодках этого самого фортрана.

                                      У нас в отделе хорошо себя показывает связка C++ с высокоуровневым языком типа Python. Мы занимаемся как раз физическим моделированием.
                                      Идея такая: на C/C++ пишем вычислительное ядро программы. Всё остальное пишется на Python: I/O, пользовательский интерфейс, скрипты для запуска C++ ядра, всякие предварительные расчеты, пост-обработка данных и т.д.

                                      Здесь, конечно, квалификацию программиста надо повыше иметь, но тоже ничего архисложного нет. Python до необходимого уровня учится за два месяца, ресурсов море. С биндингом тоже разобраться можно, хотя самостоятельно будет уже не так легко.
                                      Зато потом скорость разработки и модификации кода сильно возрастает, а удовольствие от процесса увеличивается вообще многократно.
                                        –1
                                        А почему python, у которого синтаксис совершенно непохож на C, а не тот же perl?
                                          +3
                                          Потому что предыдущий комментатор не совсем прав, неявно заявляя, что средний физик программирует лучше среднего кодера при равном рабочем опыте. Из ученых получаются самые жуткие быдлокодеры. Поэтому лучше Питон, который будет карать даже за попытку сделать шаг не по уставу, чем Перл, с его возможностью сделать код абсолютно нечитаемым даже для автора.
                                            +2
                                            Никто не говорил, что они будут лучше программировать. Как минимум это не их профиль, у них нет цели оптимизировать код, их цель — чтобы он выдал корректный результат с минимумом усилий. А интеллект у средних ученых повыше будет, чем у средних программистов. Сам сейчас в НИИ работаю.
                                              +2
                                              интеллект у средних ученых повыше будет, чем у средних программистов

                                              Это вы говорите, основываясь на результатах исследований или просто вам очень хочется, чтобы так было? Ведь вполне может быть, что поскольку вы работаете в НИИ, а зарплаты в российской науке несопоставимы с зарплатами в коммерческом IT, то вы просто выдумали себе компенсаторную легенду, согласно которой вы бедный, но умный.
                                                +10
                                                Эмм, мне кажется вы сами себе выдумали легенду, что если в IT платят больше, то значит там люди умнее. Скажите еще, что фронтендер с 3-месячных курсов с з/п 50, умнее кандидата наук с зарплатой 30.

                                                Я сисадмин, я работал и в IT-компаниях. Мое мнение основано на моем личном опыте общения и с программистами, и с учёными. И интеллектуальное сравнение чаще не в пользу первых, а вот «синдромом Бога» и чрезмерно завышенной самооценкой страдает каждый второй.

                                                Мнение же окружающих, что программисты умнее исходит из того, что большинство из них пытается козырнуть какая он интеллектуальная элита, как угодно, но доказать, что он умнее окружающих. Среди ученых такого меньше.
                                                  +1
                                                  А я не делал никаких утверждений относительно ума людей других профессий. Это вы сказали, что дескать, интеллект у ученых повыше будет — вам и приводить доказательства.

                                                  Я сисадмин, я работал и в IT-компаниях

                                                  О, можете дальше не продолжать. Это классика. Я собеседовал десятки бывших сисадминов, приходивших в качестве соискателя на должность разработчика.
                                                    0
                                                    О, можете дальше не продолжать. Это классика. Я собеседовал десятки бывших сисадминов, приходивших в качестве соискателя на должность разработчика.


                                                    И о чем это говорит, кроме очевидного кризиса в профессии? Я также не говорил, что админы умнее программистов.
                                                      +1
                                                      О том, что сисадмины регулярно недооценивают сложность работы программистов. Поэтому и идут на собеседование, где выдавливают из себя что-то типа «ну, я писал скрипты в баше и это… чуть-чуть правил CMS/биллинг», претендуя при этом как минимум на мида. Не понимая, что их знания — это даже не уровень джуниора. А в случае общения с представителями других профессий, у них, вероятно, не возникает иллюзии наличия собственных знаний. Отсюда и разные оценки.
                                                      0
                                                      А это плохо, когда сисадмин приходит на должность разработчика?
                                                      0
                                                      Странно но у меня сложилось противоположное впечатление, среди кандидатов и профессоров с которыми я общался была процентность высока «людей повернутых слегка», а ЧСВ у некоторых кандидатов просто зашкаливающее и обратно пропорционально возрасту. У программистов с этим намного проще, хотя видимо зависит от страны/города/предприятия…
                                                +6
                                                Тоже, что и с фортраном, куча уже написанного кода, и батарейки в комплекте!
                                                +2
                                                Да дело не в том, что учёному выучить ООП сложно. Дело в том, что учёному ООП, как правило, не нужно. Учёному, как правило, нужно быстренько написать небольшую программу для своих рассчётов, взять результат и, забив на программу (возможно, даже навсегда), углубиться в то, ради чего этот учёный, в конечном итоге, функционирует — написание статьи и пристраивание её в журналы/конференции. Возможно, он ещё раз-другой вернётся к этой программе, чтобы чего-нибудь модифицировать и высосать результатов ещё на пару статей, после чего, исчерпав тему, забросит её уже точно навсегда (и слава богу, ибо к тому времени ужасность его быдлокодерского поделия возрастёт настолько, что любым дополнительным «улучшением» он уже рискует пробить дыру в пространство отрицательного интеллекта, откуда вылезет Ктулху или ещё кто похуже).

                                                Если же вдруг в его коде таки присутствует потенциальное reusability, то, чтобы превратить его в реальное, надо много думать, анализировать, проектировать, в итоге, скорее всего, написать библиотеку, и, вероятно, даже с ООП. Подобных примеров тоже полно, но, как правило, у нашего сферического учёного нет на это ни времени, ни желания, и платят ему не за это. И если он таки нахватался где-то баззвордов, кое-как выучил ООП и пытается применять — обычно выходит только хуже.
                                                +1
                                                У меня набор вопросов про фортран:

                                                1. Как у него с безразмерными целыми?
                                                2. Как у него зависит размер инта от битности процессора?
                                                3. Как осуществляется управление библиотечными зависимостями и их установка?
                                                4. На чём пишутся юнит-тесты для кода на фортране?
                                                5. Как у него обстоят дела с юникодом?
                                                  +4
                                                  1. Из коробки — никак.
                                                  2. По умолчанию инт четырёхбайтный. Можно задать от INTEGER(1) до INTEGER(16) (иногда только 8).На экзотических архитектура не определено.
                                                  3. Автоматического установщика как в новых средах нет.
                                                  4. На чём угодно, нематиматическую часть нет ни малейшего смысла писать на фортране, а в новых стандартах (а по факту и в старых) фортрановские объектники линкуются с C/C++-ными. Так что вполне можно использовать GTest.
                                                  5. Теоретически в новых стандартах есть всё для работы с юникодом. Практически — не видел ни единого случая, когда бы это использовалось. Область применения фортрана бесконечно далека от обработки текстов.
                                                    0
                                                    Вот три — это катастрофа. В смысле, тяжелейшее легаси. Если бы у них был аналог cargo, pip'a, bundler'а и т.д., то это бы сделало язык куда более переиспользуемым, а научные библиотеки — более доступными.
                                                      +2

                                                      У Си тоже нет ничего подобного (сколько нибудь распространённого), это не мешает ему быть одним из популярнейших языков.
                                                      Да и с трудом представляю себе учёного "фортрано-боя" который с блеском в глазах качает ночами новые модные библиотеки, установить которые вручную он бы не смог (-:

                                                        0
                                                        У Си есть что-то подобное. Называется ldd. И всё остальное, сверху — dpkg/rpm, etc. Когда мне нужны готовые бинарники — ими управляет ldd, когда мне нужны хидеры — есть пакет libfoobar-dev, который ставит хидеры для бинарных пакетов libfoobar, который содержит файлы so'шек для ldd.

                                                        Система управления зависимостями в Си настолько встроена в современные операционные системы, что не все осознают её всеохватность.

                                                        Только в Си можно ожидать «сишную DLL/so» в системе. Никто в своём уме не будет ожидать в целевой системе «разделяемую библиотеку pascal» или «модуль go», а так же присутствующего менеджера для этих библиотек.
                                                          0

                                                          Фортран ABI совместим с C. Вы можете использовать те библитеки, которые захотите. Хоть shared, хоть static.

                                                            0
                                                            О, тогда всё не так плохо. Пакеты могут быть:
                                                            apt-cache search fortran|grep lib|wc -l
                                                            449
                                                            apt-cache search fortran|grep lib|grep dev|wc -l
                                                            161
                                                            ldd для управления файлами. Терпимо.

                                                            Кстати, совместимость с си надо записывать в гигантские преимущества.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    –6
                                                    У фортрана есть гигантский недостаток — код на нём не выполняется на GPU. В большинстве случаев лучше взять любую хорошую обёртку над OpenCL для любого любимого ЯП, хоть питона, и получить почти бесплатное распараллеливание. Так как математические и физические алгоритмы и в большинстве случаев формулируются терминах тензоров, матриц, и прочих линейноалгебраических структур и операций над ними, и эти операции хорошо параллелятся, более того gpu и были созданы специально чтобы выполнять на них линейно-алгебраические операции, то переписать это на класс-обёртку не должно составить труда, и получить более понятный и более параллельный и производительныйкод.
                                                    Так что fortran — это чистой воды ретроградство.
                                                      +5
                                                      Там выше в комментариях написали кодовую фразу: «CUDA FORTRAN».
                                                        0
                                                        http://ccoe.msu.ru/ru/node/59
                                                          +1
                                                          Чтож вы так? Совсем гуглить разучились?
                                                            0
                                                            Кроме CUDA для вычислений на GPU ещё можно использовать:
                                                            https://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
                                                            https://gcc.gnu.org/onlinedocs/gfortran/OpenACC.html
                                                            +4
                                                            Как человек, который писал этот самый астрофизический код на фортране-77, могу сказать, что maintainability такого кода стремится к нулю — ведь ученые вдобавок еще и никогда не были профессиональными программистами, отчего код не только исторический, но и ужасающий своей начинкой. (Да, сейчас я уже благополучно отошел от астрофизики несколько лет как)

                                                            Если человек не в состоянии освоить достаточно простые и понятные вещи в ООП, то непонятно, какой из него ученый.

                                                              +5
                                                              Это несколько э… холиварно.
                                                              Т.е. программирование — это инструмент.
                                                              Скажем композитор оценивается по красоте созданного произведения, а не потому как он сам хорошо играет на рояле.
                                                              Хотя да — бывает и то и то в одном флаконе.
                                                              Экспериментальная лаборатория. Приезжает парень из Германии. Я ему — Мартин — а ты можешь сам сделать термопару? Он: -Нет. Я: — как же так? Ты ж экспериментатор! Мартин: — А зачем? Есть техник.
                                                              У нас же каждый и швец, и жнец, и на дуде игрец. Хотя плюсы есть в каждом подходе.
                                                              — Свой код я предпочитаю настоящим программистом не показывать — берегу их хрупкую психику.

                                                                +1

                                                                Да дело не в том, что кому-то не понравится, дело в том, что код надо обслуживать, развивать и просто в нем не путаться, то есть в нем должно быть


                                                                • здравое разбиение на блоки, объекты
                                                                • невозможность перепутать типы и так далее
                                                                • возможность расширять под новые задачи без ломания задач предыдущих
                                                                • ясная логика построения.
                                                                • удобство совместной работы над кодом

                                                                то есть инструмент должен использоваться вместе с навыками эффектиыной работы, которая собственно и страдает, когда человек вместо использования кода должен неделями в нем просто разбираться(!) и когда рефакторинг опять-таки длится неделями и ломает предыдующую версию кода, отчего код начинает плодиться в копиях "для того", "для этого".

                                                                  +1
                                                                  Физики всем тем, что вы перечислили, не занимаются, у них другая работа и другие цели.

                                                                  Если нужен не разовый инструмент для оценки/расчета, то и пишут такие вещи программисты, у которых консультантами в предметной области являются те самые физики. Конечно, бывают исключения, но они лишь подтверждают правило: физика — физикам, программирование — программистам.
                                                                    +4

                                                                    Я не знаю о ком вы говорите, но я кандидат физматнаук, 15 лет в этой сфере, защищался в ИКИ РАН, бывал в ряде институтов Европы. Был знаком с большинством активных ученых в моей сфере, существующих на свете.


                                                                    И никто, кроме самих ученых, им код не пишет.


                                                                    Если вы кого-то конкретного знаете, кто может позволить себе нанять мальчиков-зайчиков (я знаю расценки консалтинга), то мне очень интересно будет эту кулстори узнать.

                                                                      –3
                                                                      плюсанул бы ваш комментарий, но нету прав :)
                                                                        0
                                                                        Я плюсанул за Вас.

                                                                        Точно, никто нам, ученым, код не пишет.

                                                                        Наследуем от Учителей, обмениваемся с коллегами-учеными.
                                                                        Вот так, чтоб я пришел к кому-либо из программистов и попросил что-то для меня написать — такого не помню.

                                                                        Ну нельзя (физически) переписать, например, все «рецепты» на JS за время выполнения мастерской диссертации.

                                                                        Да и нужно ли?..
                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                            0

                                                                            Мм… Ума не приложу, зачем учёным ANSYS?
                                                                            Я-то думал, что его наоборот — пишет команда учёных, исследователей и программистов для того, что бы облегчить жизнь простым инженерам.

                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                0

                                                                                ЦАГИ научно исследовательский институт. В том числе решает обычные инженерные задачи. Что и написано по ссылке:


                                                                                В работе представлены результаты численного моделирования обтекания одиночной лопасти несущего винта.… Полученные результаты сравниваются с экспериментальными данными и результатами моделирования… Показано удовлетворительное, а в некоторых случаях и хорошее согласование расчетных данных, полученных по разным методикам, с экспериментальными.

                                                                                Ничего общего с фундаментальной наукой, никаких открытий не делается и не предполагается, рассматривается один из инструментов сокращения периода испытаний.


                                                                                Да и написали ANSYS не ватага хипстеров-фронтендщиков решивших показать учёным как правильно расчехлять IDE.


                                                                                И кстати… Не знаю как там Fluent, а ядро ANSYS SFX написано на чистейшем F95.

                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    0

                                                                                    Можно забомбить куда угодно, но если этой суперсреды не будет у того, кто должен подтвердить/расширить/использовать расчёты — чуда не произойдёт.
                                                                                    А что с ней будет чрез 50 лет?

                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                        0

                                                                                        Ну наверное тем, что рассматривает более общие вещи, очень далёкие от непосредственного практического применения.
                                                                                        Я не писал кандидатских и не смогу объяснить за объект, предмет и методологию исследований, но на бытовом уровне всё просто:


                                                                                        • Когда учёный пишет программу для обсчёта взаимодействия π-мезонов с протонами, это фундаментальная наука.
                                                                                        • Когда я заряжаю ANSYS на расчёт (очень похожий на тот, что в статье) — я занимаюсь инженерным делом.
                                                                                        • Если я вдруг решу обобщить миллион расчётов ANSYS и сотню тысяч экспериментов, то это будет уже наука… Только в области статистики, а не аэродинамики.

                                                                                        Наукой занимаются те, кто пишут ANSYS и расчётные модели для него.

                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                            0
                                                                                            я не встречался раньше с таким понятием как «численно-расчетная фундаментальная наука»

                                                                                            Я даже знаю почему. Скорее всего потому, что вы этот термин только что придумали.

                                                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                                          0
                                                                                          Инженерная задача — выполнение расчета.
                                                                                          Фундаментальная наука — создание идеи расчета (уравнения, приближения, типы условий, расчетная схема) и только после этого расчет.
                                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                          0
                                                                          Теоргруппа Стухлика в Опаве имеет «мальчика-зайчика», вся работа которого — писать код. Группа Пайро в Принстоне (часть бывшей группы Отта в Калтехе) — тоже.
                                                                            0

                                                                            CAMK Warzawa, ИКИ РАН (52 отдел), Durham Unuversiru, University of Amsterdam… увы, у них нет таких ресурсов

                                                                          0

                                                                          Значит физики и не должны писать код, в штате обязательна пара профессиональных высококлассных программистов, свободно владеющих численными методами и мат.методами рабочей области. Или можно дойти до того, что профессор обязан уметь пользоваться всеми видами сварки, быть асом электроники, и точить на станках свое экспериментальное оборудование. Можно разве что потребовать умение работать в какой-нибудь мат.среде типа mathematica, для которой проф.программист пишет заказные модули расширения.

                                                                            0
                                                                            В идеальном мире так и было бы. В этом мире наука финансировалась бы исключительно частными компаниями т.к. в гос. поддержке не было бы необходимости. На практике ничего подобного нигде нет.
                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                          0
                                                                          Второй одинаково хорошо вгонит шурупы во все 3 доски, при этом он не сможет вогнать гвоздь.

                                                                          Второй — лошара.
                                                                          Помнится, был у меня такой опыт, с забиванием гвоздей отверткой.
                                                                          Повторить такое по доброй воле, конечно, не возьмусь, но если надо, ...

                                                                            0
                                                                            А я и шуруповёртом как-то забивал. Правда, тонкий гвоздь и во что-то мягкое.
                                                                              0
                                                                              А дрелью гвоздь можно завинтить…
                                                                            0
                                                                            Проблема аналогий в том, что они почти никогда не соответствуют реальности, а лишь иллюстрируют фантазии автора аналогии.
                                                                        0
                                                                        где то я эту булочку уже видел и не так давно…
                                                                          0
                                                                          Похоже это не заслуга Фортрана, а недоработка Си, в котором многих полезных вещей нет принципиально, потому что их переложили на библиотеки, нередко друг с другом не совместимые.
                                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                                              0
                                                                              Как-то странно читать «скорость программы на С».
                                                                              Вот например, MATLAB раньше рекомендовал под Windows в качестве дефолтного С компилятора Microsoft Windows SDK 7.1, а в последних версиях рекомендует MinGW 4.9.2. И я полностью поддерживаю выбор MathWorks, потому что в моих приложениях разница в скорости скомпилированных mex-модулей была в 3 раза (!!!) в пользу MinGW. К слову, gcc под Linux давал очень близкие результаты.
                                                                              А если при этом еще побаловаться ключами -march=native, то можно и еще процентов 20-30 выжать.
                                                                              Так о какой такой сферической в вакууме «скорости программы на С» можно говорить и с чем-то сравнивать?
                                                                                +3

                                                                                Так фортран компилируется тем же самым gcc.
                                                                                Потому что gfortran это всего лишь один из бекендов gcc, а Intel Fortran один из бекендов Intel Compilers.
                                                                                Все опции кодогенерации, доступные для C/C++ доступны и для фортрана.


                                                                                Суть в том, что математическая программа написанная в лоб на фортране с использованием стандартных средств, как правило будет быстрее программы написанной на С/С++ с использованием %вашей_любимой_библиотеки% даже после небольшой оптимизации.
                                                                                После серьёзной оптимизации разница будет скорее в пользу С/С++.

                                                                                  +1
                                                                                  Дешевле докупить железа, чем связываться с «программистом-оптимизатором». И причин несколько — 1) удобочитаемость кода; 2) поиск и исправление ошибок, особенно, если open-source; 3) понимание того, как работает и как должен работать код, а также результатов. Увы, но программист, скорее всего не поймет всю физику процессов моделирования, это я утверждаю со своей колокольни 10-летнего опыта DFT рассчетов.
                                                                                    0
                                                                                    Дешевле докупить железа, чем связываться с «программистом-оптимизатором».

                                                                                    Простите, не соглашусь с вами.
                                                                                    Полный цикл расчётной программы считается месяц (чистого времени, календарного — вдвое больше) на самом мощном суперкомпьютере на который хватило денег у организации.
                                                                                    Только переговоры о доступе к другому компьютеру (если деньги свалятся с неба) займут до полугода, а потом ещё очередь.
                                                                                    За какие деньги и какого железа вы предлагаете "докупить"? (-:


                                                                                    Не путайте веб-сервисы для редактирования картинок и расчёты для изделий стоимостью в десятки мегафранклинов.

                                                                                      0
                                                                                      Возможно мы не совсем верно поняли дргуг друга, поскольку я говорил о научных рассчетах, а вы, как я понимаю, об инженерных. За какие деньги? Гранты, гранты, потом еще гранты, опять гранты, снова гранты, патенты, лицензии. Железо?, да любое быстрое доступное (dell, hp, supermicro) на рынке.
                                                                                        0

                                                                                        Да, я имею в виду скорее инженерные и научно-инженерные задачи (научные кафедры могут не только гранты проедать, а и хозрасчётными работами заниматься).
                                                                                        Ну а любителям грантов оптимизировать вообще не нужно, для них идеальный язык — Ruby (-:

                                                                                0
                                                                                Доброшу еще немного до кучи:

                                                                                1. В OpenMP при редукции (reduction) только в Fortran можно использовать функции min и max, в C/C++ такой возможности не предусмотрено.

                                                                                2. Некоторые на Fortran веб-серверы пишут: https://fortran.io/. Это почти как на ассемблере, только на Fortran. И наверное тоже «полезно и приятно».

                                                                                3. Самому проверять не приходилось, но говорят, кроме мира x86 есть еще мир супер-компьютеров на основе альтернативных архитектур, для которых компиляторы Fortran выдают более производительный код по сравнению с компиляторами C. И никакой ifort вам под Cray код не сгенерирует.

                                                                                4. Чего реально не хватает в Fortran, так это интринсиков. Я уже несколько раз встречал программы на Fortran, в которых критическая часть переписана на C с использованием интринсиков под Xeon Phi или AVX512. А виной этому, видимо, гарантированная (насколько это возможно) переносимость кода между разными платформами.
                                                                                  0
                                                                                  1. Начиная с OpenMP 3.1 можно использовать min/max и в C/C++.
                                                                                  +1
                                                                                  Года 4 назад у нас был курс вычислительной математики (очень интересный и полезный курс, хотя, к сожалению, многое уже забылось). В ходе курса нужно было написать программку, которая моделирует какой-то физический процесс. Чтобы мы не закопались, нам разрешили пользоваться библиотекой с реализацией типовых алгоритмов (например, для численного решения диффуров).
                                                                                  Библиотека была в 3 вариантах: Fortran 66 (оригинальный вариант), C и Pascal. Народ в группе решил не рисковать и взять привычную сишечку, а во мне взыграло любопытство — почему бы не попробовать новый язык, Fortran?
                                                                                  В целом, эксперимент удался. Язык оказался очень простым и удобным для моих задач, хотя и весьма своеобразным. Пока остальные подключали библиотеку к Visual Studio и возились с указателями, у меня уже всё работало. Писал я на современном Fortran 95, что вообще ни капли не мешало использовать старую библиотеку. Матричные операции — отличная штука, хотя не сказать, чтобы я активно ими пользовался. Больше всего проблем было с I/O — нужно было вывести матрицу в файл, и почему-то не получалось отключить перенос строки в операторе вывода.
                                                                                  С одной стороны, если бы был нормальный порт библиотеки на C++, с ООП и всеми делами, то может быть на плюсах было бы и удобнее. Но в случае математических библиотек в большинстве случаев порт — это просто адаптация под синтаксис другого языка. Так что даже если под C++ или другой язык будет подходящая библиотека, далеко не факт, что решить задачу на нем будет быстрее, чем на Fortran.
                                                                                    0
                                                                                    Очень интересная статья. Много узнал о Фортране.
                                                                                    Спасибо за статью автору!
                                                                                      0
                                                                                      Мне кажется, что многие просто не могут осознать, какое это болото Fortran.

                                                                                      Особенно, в режиме «fixed-form source», в котором длина строки должна быть не больше 72 символов, а символы дальше 72 позиции просто игнорируются.

                                                                                      Сейчас такое может присниться только в самом страшном сне.
                                                                                        0

                                                                                        Fixed-form был нужен для вполне конкретных целей — набивки на перфокарты, с чем прекрасно справлялся.
                                                                                        Использовать его для нового кода никто не заставляет.
                                                                                        Преобразовать его во Free-form можно питоновским скриптом на десяток строчек.


                                                                                        Меня бы больше волновали хаотично "сцепленые" циклы, Computed GOTO, и братские могилы данных в COMMON блоках (-:

                                                                                          0
                                                                                          Вот реальная библиотека: https://sourceforge.net/projects/ani2d/
                                                                                          Датирована 2014 годом, сделана с использованием fixed-form.

                                                                                          Интерфейс функций по современным меркам, мягко говоря, неудобный.

                                                                                          Авторы, конечно, молодцы, постарались сделать максимально удобно, но все равно это остается анахронизмом.
                                                                                            0
                                                                                            Датирована 2014 годом, сделана с использованием fixed-form.

                                                                                            Но вас-то они не заставляют так писать? (-:
                                                                                            Стиль КМК связан с тем, что библиотека начала разрабатываться где-то в начале 90-х. Скажите ещё спасибо, что они используют инденты. Да и вообще код довольно читаемый.


                                                                                            Интерфейс функций по современным меркам, мягко говоря, неудобный.

                                                                                            Ну так создателям видимо довольно удобно. Если неудобно вам, то я не понимаю почему в репозитории нету фичереквеста?

                                                                                        +1
                                                                                        Да какая разница на чем пару чисел между собой множить? Они же физики, а не кодеры. Тем более какие-нибудь известные алгоритмы уже есть на Фортране. Зачем переписывать это на другой язык, когда можно сделать ctrl+c, ctrl+v и не париться? Много ты, анон, переписал шифрование по ГОСТу на свой любимый бейсик?
                                                                                          0
                                                                                          В Северной Америке любое производство должно пройти природоохранную экспертизу.
                                                                                          Консалтинговые компании обязаны использовать утвержденный министерством код, который исторически был написан на фортране. Теперь этот код регулярно поправляется, но переводить на другой язык уже никто не будет.

                                                                                          Оболочки теперь пишутся на C++/C#/Delphi/Java
                                                                                            0
                                                                                            В 1986 году в здательстве «Финансы и статистика» вышла книга Орлов В.Н. «Комплексирование программ в ОС ЕС».

                                                                                            Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.

                                                                                            Был бы здорово может и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
                                                                                              0
                                                                                              Потрясно!

                                                                                              А вот если FORTRAN приспособить для расчёта процессов в организме человека?
                                                                                              Сразу, целиком.
                                                                                              Вытянет?
                                                                                              А то всё как то по отдельности:

                                                                                              Пакеты прикладных программ по биомоделированию.

                                                                                              hpc.icc.ru/software/libraries.php

                                                                                              Systems Biology Markup Language (SBML) - формат представления, основанный на XML, для сообщения и хранения вычислительных моделей биологических процессов.

                                                                                              ru.knowledgr.com/02153233/SBML

                                                                                              KVAZAR» — открытый многопроцессорный программный комплекс молекулярного моделирования

                                                                                              nanokvazar.ru/kvazar

                                                                                              «ТРЕТЬЯ РЕВОЛЮЦИЯ В БИОМЕДИЦИНЕ»

                                                                                              vechnayamolodost.ru/articles/drugie-nauk...hizni/tretrevvbio4e/

                                                                                              Способ быстро предсказывать структуру белковых комплексов

                                                                                              www.nanonewsnet.ru/news/2016/uchenye-nas...belkovykh-kompleksov

                                                                                              Моделирование структур белков

                                                                                              kib.nsu.ru/?page_id=1488

                                                                                              сверхбыстрый метод моделирования белковых взаимодействий

                                                                                              university.innopolis.ru/news/cluspro/

                                                                                              Ученые смоделировали внутриклеточную среду на атомарном уровне

                                                                                              www.nanonewsnet.ru/news/2016/uchenye-smo...-na-atomarnom-urovne

                                                                                              Ученые работают над созданием первой трехмерной модели живой клетки

                                                                                              www.nanonewsnet.ru/news/2016/uchenye-rab...modeli-zhivoi-kletki

                                                                                                0
                                                                                                Потомучто физики не программисты. У них другие задачи и другие темпы развития.
                                                                                                  0
                                                                                                  В 1986 году в здательстве «Финансы и статистика» вышла книга Орлов В.Н. «Комплексирование программ в ОС ЕС».

                                                                                                  Книга была посвящена проблеме организации сязей между программами, написанными на различных языках программирования. Рассмотрены общие соглашения о связях и особые соглашения, принятые в различных трансляторах. Основное внимание уделено теоретическим и практическим аспектам связи программ, написанных на разных языках (Ассемблере, Фортране, ПЛ/1) с учетом специфики транслятора ПЛ/1, уровня F и оптимизирующего транслятора ПЛ/1.

                                                                                                  Был бы здорово можеть и сегодня выпустить аналогичную книгу с учетом реалий. Прежде всего это не ПЛ/1, а естественно C/C++. Да и ассемблер совсем другой. Заменить оглавление с учетом этих замечаний и…
                                                                                                    0

                                                                                                    Так и не понял, почему фортран сравнивают с C/C++, которые даже программеры выбирают только тогда, когда уже деваться некогда (или когда больше ничего не умеют). Там 90% времени будет уходить совсем не на описание алгоритмов и логики.
                                                                                                    Есть же специальные научные среды: Matlab, Mathmatica и т.п., в которых не надо бедному физику постоянно думать в какую кучку какой указатель аллоцируется и прочую муру.

                                                                                                      0
                                                                                                      Никто в здравом уме, будучи знаком с C++ и Matlab не выбирает Matlab — все от него шарахаются. В С++ физику не нужно думать о кучках и указателях — вы имеете ввиду C. Писать софт в Математике, наверное, можно, но что-то я его особо не видал. Графики — да, матан — да. Но научный софт (не скрипты до 500 строк) пишут на C++ либо Python. Остальное используется от безысходности (legacy, отсутствие желания знакомится с python/c++ или наоборот желание попробовать «новый» для учёного язык типа Haskell, C# или Java). Исключения бывают, наверное, но всё же в подавляющем большинстве случаев выбор физика сегодня падает на C++/Python.
                                                                                                      0
                                                                                                      Странно, но в институте физики имени Л.В. Киренского почти все пользуются MatLab для моделирования, по крайней мере в области квантовой механики. Я сам пробовал сравнивать скорость работы кода на MatLab, C++ и Python/Scipy (который, внезапно, использует для вычислений LAPACK/BLAS написанный на Fortran). Код выкладывать не буду, ибо стыдно. Но смысл в том что неплохо зная Python я смог написать код который был в 3-4 раза медленнее чем на MatLab, для моделирования движения квантовой частицы в оптической решетке. Я пробовал заменить BLAS на ATLAS, но не сильно помогло. И даже попытавшись тоже самое написать на С++ я потратил около месяца в попытках оптимизировать скорость вычислений с помощью boost/uBLAS, и все равно не приблизился к скорости MatLab. Поэтому научиться писать код на С++ не трудно, а вот научится его писать быстрым уже не так просто, да и зачем если за тебя уже написали, пусть и на очень неудобном MatLab.
                                                                                                        0
                                                                                                        Потому от Matlab и отказываются повсеместно (вопреки сложившейся ранее традиции, когда у него не было конкурентов), что научится писать на Python код во всех отношениях лучше, чем Matlab-овский проще, чем изучить Matlab и им пользоваться. При этом возможности Python много шире и пользы от знания Python много больше. Если сравнение идёт по скорости, то Matlab надо сравнивать numpy или вообще numba, может быть. И я ниразу не видел что бы в этом сравнении Matlab одержал победу.
                                                                                                        0
                                                                                                        Обсуждение все больше скатывалось к идее «какой язык лучше»…
                                                                                                        Да, микроскопом можно забивать гвозди, а молотком можно достать соринку из глаза. При большом желании =))
                                                                                                        Лучше тот, который ты ЗНАЕШЬ! В совершенстве. Если ни одного — тот, который тебе легче будет выучить.

                                                                                                        В сухом остатке — Фортрану фортраново, С — сишное, и т.д.
                                                                                                        Само разнообразие и конкуренция языков — это чудесно.
                                                                                                          0
                                                                                                          Но есть одно но. Некоторые устаревшие языки не превосходят более новые вообще ни в чём. Это скорее как арифмометр vs калькулятор, а не как молоток vs микроскоп. Единственная причина, почему ими продолжают пользоваться — инертность: legacy код и нежелательность обучения новому неизвестному языку.
                                                                                                          0
                                                                                                          В C/C++ для этого требуется следующая запись:

                                                                                                          int **array;
                                                                                                          array = malloc(nrows * sizeof(double *));

                                                                                                          for(i = 0; i < nrows; i++){
                                                                                                          array[i] = malloc(ncolumns * sizeof(double));
                                                                                                          }

                                                                                                          Для освобождения массива в Fortran

                                                                                                          deallocate(name_of_array)

                                                                                                          В C/C++ для этого

                                                                                                          for(i = 0; i < nrows; i++){
                                                                                                          free(array[i]);
                                                                                                          }
                                                                                                          free(array);


                                                                                                          1) Исправьте int на double.
                                                                                                          2) Не в C/C++, а в C. В C++ для этого есть vector, а начиная с C++14 — dynarray (в частности, не нужно явное освобождение — в C++ автоматическое управление ресурсами). А в C99 есть variable length arrays, вообще идеально решающие эту задачу (правда, в C11 ставший опциональным, и с C++ они несовместимы).
                                                                                                          3) Это явно не самый лучший способ выделить память под двумерный массив. Лучше выделить единым блоком — и выделение/освобождение проще, и работа будет эффективнее за счёт большей локальности данных и меньшей косвенности в обращении (правда, индексировать его будет сложнее).

                                                                                                          Хотя не являющиеся программистами люди действительно так и будут писать.

                                                                                                          Проблема в том, что const real отличается от простого real. Если функция, принимающая real, получит const real, она вернёт ошибку.


                                                                                                          ???

                                                                                                          int f(double x);
                                                                                                          int fc(const double x);
                                                                                                          ...
                                                                                                          double y = 5;
                                                                                                          const double yc = 9;
                                                                                                          f(y); //OK
                                                                                                          fc(y); //OK
                                                                                                          f(yc); //OK
                                                                                                          fc(yc); //OK
                                                                                                          


                                                                                                          Может, имелась в виду какая-нибудь передача по указателю, для которого забыли написать const? (T* к const T* прекрасно преобразуется, если что.)

                                                                                                          C – язык сравнительно примитивный, поэтому физики, избирающие себе C/C++, занимаются объектно-ориентированным программированием.

                                                                                                          Это предложение сломало мне мозг. Имелось в виду, что физики, выбирающие C/C++, в силу примитивности C смотрят в сторону C++, а он объектно-ориентированный? И жалуются потом, что им сложно? И поэтому надо выбирать фортран?

                                                                                                          Странная логика. Тем более что ООП — просто парадигма. Можно и на C++ писать в процедурном стиле (и не углубляться в изучение языковых средств поддержки ООП), а можно и на фортране мутить ООП, если очень надо.

                                                                                                          Объекты – очень громоздкие структуры по сравнению со структурами данных, предпочитаемыми физиками: массивами.


                                                                                                          В C++ классы могут быть неполиморфными, в силу чего их объекты физически будут представлять собой просто записи из полей (подобно derived type в том же самом фортране).

                                                                                                          Объекты и массивы сравнивать бессмысленно, они разные задачи решают. Но даже если совсем забить на инкапсуляцию и вообще философию ООП, то «объекты» и «массивы» — это разные способы построения одних типов данных из других, они друг с другом не конкурируют. Массив — большое или неопределённое количество однородных элементов, объект — определённый набор разных по типу и/или смыслу элементов (лишь с учётом вышесказанного; на самом деле, разумеется, эта некая целостная сущность предметной области, а не агрегат для данных).

                                                                                                          Если бы мы передавали его по ссылке, переданные данные не располагались бы в памяти подряд.


                                                                                                          И как вы себе представляете в Си передачу по ссылке подмассива, элементы которого расположены неподряд?

                                                                                                          Если первый индекс — индекс молекулы, то координаты одной молекулы будут располагаться подряд. В противном случае программисту на Си придётся вручную сформировать временный массив. Если только он явно не сделал одним из передаваемых параметров шаг (наряду с указателем на первый элемент и размером), специально для таких случаев.

                                                                                                            0

                                                                                                            Из моего опыта могу сказать следующее:
                                                                                                            Чего не хватает в си++ из коробки — это нормальных многомерных массивов.
                                                                                                            Что мешает в фортране — это отсутствие удобного ввода вывода и то что все переменные надо объявлять в начале функции.
                                                                                                            Чего не хватает везде — это удобной интеграции с python/numpy array, потому что отдает голый указатель а не нормальный класс.
                                                                                                            В остальном все работает одинаково имхо.
                                                                                                            Буду рад увидеть в обсуждении конкретные примеры и опыт использования существующих инструментов.

                                                                                                              0
                                                                                                              Чего не хватает в си++ из коробки — это нормальных многомерных массивов.

                                                                                                              Есть «почти» из коробки — Boost.MultiArray. Не могу сказать, является ли эта библиотека исчерпывающим решением проблемы, но когда мне подобное нужно было — хватило.
                                                                                                              P.S. Для линейной алгебры (2D) лучше Eigen, Armadillo и т.д.

                                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                            Самое читаемое