03.01.2017 18:32
geher 31800 Источник
Не знаю, как будет выглядеть язык программирования в 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, ещё предстоит увидеть. В любом случае, подозреваю, что это будет происходить очень долго.
Поделиться с друзьями
-->

Комментарии ()


  1. AntonSor
    03.01.2017 21:45
    #9792554

    Интересно, а бывает Visual Fortran? :)


    1. Nikobraz
      03.01.2017 22:03
      #9792586

      Погуглите, на первой странице результатов поиска я много интересного нашел.


      1. AntonSor
        03.01.2017 22:07
        #9792598

        Действительно…


    1. SLY_G
      04.01.2017 00:33
      #9792798

      https://habrahabr.ru/post/202680/


  1. sielover
    03.01.2017 22:31
    #9792644
    +3

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


  1. mirsev
    04.01.2017 00:32
    #9792788
    -1

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


    1. SLY_G
      04.01.2017 00:32
      #9792794
      +7

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


    1. argentumbolo
      04.01.2017 01:19
      #9792830
      +10

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


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


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


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


      1. mirsev
        04.01.2017 06:54
        #9792924
        -3

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


        1. argentumbolo
          04.01.2017 09:35
          #9793000
          +6

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


        1. ustaspolansky
          04.01.2017 10:05
          #9793022

          Как новичок начавший изучать C++ выскажусь субъективно о решении из «коробки»:
          — Достаёшь решение из «коробки», а там ещё «коробка», в ней ещё «коробка», в ней…
          — Ну ок.
          — Иду в сеть почитать какое оптимальное решение есть.
          — Читаешь а там «Решение А», «Решение А.at(i)», «Решение ***А»,…
          — Читаю статью про Fortran.


          1. immaculate
            04.01.2017 16:08
            #9793482

            Хорошо, что на Javascript никому еще не пришло в голову программировать алгоритмы. Потому что в Javascript для любой проблемы есть минимум 10,000 готовых библиотек, из которых 9,999 считаются устаревшими и немодными, а 1 ­— является слишком новой и продвинутой, и потому ни с чем другим (включая существующие среды исполнения).


            1. DistortNeo
              04.01.2017 17:36
              #9793580

              У меня студент как-то обработку изображений на NodeJS делал. На вопрос «почему» ответил, что хочет просто получить опыт программирования на JS. Кстати, не так уж и медленно работало.


      1. DaylightIsBurning
        04.01.2017 19:26
        #9793698

        У фортратна была в науке (физике) своя ниша, но сейчас, на практике, по моим наблюдениям новый код никто (в физике) на fortran не пишет, да и старый даже иногда на C/C++ переписывают.


  1. FransuaMaryDelone
    04.01.2017 00:46
    #9792806

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


  1. Dum_spiro_spero
    04.01.2017 01:01
    #9792812
    +4

    Ого!
    Как много я не знал о Фортране! Это я про матричные операции.
    Фортран был в институте, но я его забросил в пользу Си.
    Сейчас всерьез задумался — а не вернуться ли?
    И даже есть книжки по Куде оказывается.
    (Загуглил — нашел «CUDA FORTRAN ДЛЯ УЧЕНЫХ И ИНЖЕНЕРОВ»).
    В общем ничего не мешает попробовать.
    Спасибо за статью!
    — mirsev
    возможности введения классов и переопределении операторов в C++,
    Как ни грустно — шикарные возможности С++ используются крайне мало.
    Вокруг почти все (научные сотрудники-физики) пишут разные программы обработки данных или расчетов на чистом С, не используя плюс-плюсовские плюшки.
    Есть конечно библиотеки типа Blitz++, но ими тоже далеко не все пользуются. Почему? Ну потому что чего там… циклы есть, условия есть, массивы есть. Всё. Что еще надо от языка? )))
    — Еще одна мысль — научные программы не предполагают длительного использования. Т.е. мы хотим что-то рассчитать — быстренько написали, посчитали, написали статью — можно переходить к новой задаче, а этот код или забросить или модифицировать под новую задачу. Т.е. типичная научная программа не предполагает долгого обдумывания структуры, а значит парадигма велосипедно-костыльного программирования оказывается вполне жизнеспособной.
    — Бывают исключения — находятся герои которые минимальным коллективом создают программные комплексы которые могут соперничать с программами-монстрами типа Fluent, CFX, Comsol, и т.п… Потом этими программами пользуются разные научные группы. Но в этих коллективах как правило люди сильно уклонились от физики в сторону программирования.


  1. ik62
    04.01.2017 01:21
    #9792832

    Когда-то давно приходилось для физических расчетов оптимизировать сишную программу и разбираться в том какой код генерит компилятор для сопроцессора плавающей точки. Последующая ручная оптимизация помогла ускорить расчет в разы. Интересно было бы узнать дают ли свойства фортрана какие-то преимущества для оптимизации бинарного кода компилятором.


  1. geisha
    04.01.2017 01:24
    #9792834
    -7

    Для матричного умножения используется 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 говорю.


  1. Saffron
    04.01.2017 01:25
    #9792836

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


  1. KennyGin
    04.01.2017 01:30
    #9792838
    -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. vasimv
      04.01.2017 02:02
      #9792848
      -1

      А почему python, у которого синтаксис совершенно непохож на C, а не тот же perl?


      1. Hellsy22
        04.01.2017 11:38
        #9793132

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


        1. Nikobraz
          04.01.2017 11:56
          #9793168

          Никто не говорил, что они будут лучше программировать. Как минимум это не их профиль, у них нет цели оптимизировать код, их цель — чтобы он выдал корректный результат с минимумом усилий. А интеллект у средних ученых повыше будет, чем у средних программистов. Сам сейчас в НИИ работаю.


          1. Hellsy22
            04.01.2017 12:30
            #9793212
            +1

            интеллект у средних ученых повыше будет, чем у средних программистов

            Это вы говорите, основываясь на результатах исследований или просто вам очень хочется, чтобы так было? Ведь вполне может быть, что поскольку вы работаете в НИИ, а зарплаты в российской науке несопоставимы с зарплатами в коммерческом IT, то вы просто выдумали себе компенсаторную легенду, согласно которой вы бедный, но умный.


            1. Nikobraz
              04.01.2017 13:00
              #9793254
              +4

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

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

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


              1. Hellsy22
                04.01.2017 13:26
                #9793284

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

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

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


                1. Nikobraz
                  04.01.2017 13:33
                  #9793294

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


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


      1. Nikobraz
        04.01.2017 11:45
        #9793146
        +2

        Тоже, что и с фортраном, куча уже написанного кода, и батарейки в комплекте!


  1. amarao
    04.01.2017 01:41
    #9792842

    У меня набор вопросов про фортран:

    1. Как у него с безразмерными целыми?
    2. Как у него зависит размер инта от битности процессора?
    3. Как осуществляется управление библиотечными зависимостями и их установка?
    4. На чём пишутся юнит-тесты для кода на фортране?
    5. Как у него обстоят дела с юникодом?


    1. argentumbolo
      04.01.2017 01:53
      #9792846
      +2

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


  1. FransuaMaryDelone
    04.01.2017 02:52
    #9792868
    +1

    Массивы, или, как их зовут физики, матрицы

    Вот так я впервые узнал, что зову массивы матрицами.


  1. KOLANICH
    04.01.2017 04:18
    #9792894
    -6

    У фортрана есть гигантский недостаток — код на нём не выполняется на GPU. В большинстве случаев лучше взять любую хорошую обёртку над OpenCL для любого любимого ЯП, хоть питона, и получить почти бесплатное распараллеливание. Так как математические и физические алгоритмы и в большинстве случаев формулируются терминах тензоров, матриц, и прочих линейноалгебраических структур и операций над ними, и эти операции хорошо параллелятся, более того gpu и были созданы специально чтобы выполнять на них линейно-алгебраические операции, то переписать это на класс-обёртку не должно составить труда, и получить более понятный и более параллельный и производительныйкод.
    Так что fortran — это чистой воды ретроградство.


    1. mirsev
      04.01.2017 06:16
      #9792914
      +5

      Там выше в комментариях написали кодовую фразу: «CUDA FORTRAN».


    1. koreec
      04.01.2017 07:41
      #9792942

      http://ccoe.msu.ru/ru/node/59


    1. Nikobraz
      04.01.2017 11:50
      #9793154
      +1

      Чтож вы так? Совсем гуглить разучились?


    1. Gumanoid
      04.01.2017 16:49
      #9793526

      Кроме CUDA для вычислений на GPU ещё можно использовать:
      https://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
      https://gcc.gnu.org/onlinedocs/gfortran/OpenACC.html


  1. Onkami
    04.01.2017 11:02
    #9793074
    +3

    Как человек, который писал этот самый астрофизический код на фортране-77, могу сказать, что maintainability такого кода стремится к нулю — ведь ученые вдобавок еще и никогда не были профессиональными программистами, отчего код не только исторический, но и ужасающий своей начинкой. (Да, сейчас я уже благополучно отошел от астрофизики несколько лет как)

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


    1. Dum_spiro_spero
      04.01.2017 11:58
      #9793174
      +2

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


      1. Onkami
        04.01.2017 12:55
        #9793242
        +1

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


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

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


  1. progchip666
    04.01.2017 11:30
    #9793120

    где то я эту булочку уже видел и не так давно…


  1. Idot
    04.01.2017 12:25
    #9793206

    Похоже это не заслуга Фортрана, а недоработка Си, в котором многих полезных вещей нет принципиально, потому что их переложили на библиотеки, нередко друг с другом не совместимые.


  1. guai
    04.01.2017 12:54
    #9793240

    Многие для этих целей смотрят на D. Фортран на мой прогерский взгляд странный чисто синтаксически, интуиция не работает.
    В Д красота, с указателями и аллокацией жестить не надо. Готовые алгоритмы тоже есть, если они есть на си. Компиляется быстрее плюсов.
    Настроить, поднять эклипс — всякое такое — тоже наверн не сложнее. С русскими мануалами разве что не густо, не уверен, как с этим у ученых в массе обстоят дела…


  1. doubtitall
    04.01.2017 14:35
    #9793366

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


    1. argentumbolo
      04.01.2017 15:41
      #9793446
      +3

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


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


      1. Romaker
        04.01.2017 20:13
        #9793780
        +1

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


        1. argentumbolo
          04.01.2017 20:35
          #9793812

          Дешевле докупить железа, чем связываться с «программистом-оптимизатором».

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


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


          1. Romaker
            04.01.2017 20:59
            #9793850

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


            1. argentumbolo
              05.01.2017 01:28
              #9794310

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


  1. mobi
    04.01.2017 20:13
    #9793782

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

    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. А виной этому, видимо, гарантированная (насколько это возможно) переносимость кода между разными платформами.


    1. Gumanoid
      04.01.2017 21:06
      #9793858

      1. Начиная с OpenMP 3.1 можно использовать min/max и в C/C++.


  1. h31
    04.01.2017 20:14
    #9793786
    +1

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


  1. Nurillo
    04.01.2017 20:15
    #9793788

    Очень интересная статья. Много узнал о Фортране.
    Спасибо за статью автору!


  1. GreenStore
    04.01.2017 20:15
    #9793790

    Мне кажется, что многие просто не могут осознать, какое это болото Fortran.

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

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


    1. argentumbolo
      04.01.2017 20:49
      #9793832

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


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


      1. GreenStore
        05.01.2017 01:42
        #9794326

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

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

        Авторы, конечно, молодцы, постарались сделать максимально удобно, но все равно это остается анахронизмом.


        1. argentumbolo
          05.01.2017 02:07
          #9794344

          Датирована 2014 годом, сделана с использованием fixed-form.

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


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

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


  1. tronix286
    04.01.2017 22:01
    #9793992
    +1

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


  1. BalinTomsk
    08.01.2017 08:30
    #9799112

    В Северной Америке любое производство должно пройти природоохранную экспертизу.
    Консалтинговые компании обязаны использовать утвержденный министерством код, который исторически был написан на фортране. Теперь этот код регулярно поправляется, но переводить на другой язык уже никто не будет.

    Оболочки теперь пишутся на C++/C#/Delphi/Java


  1. saipr
    13.01.2017 08:30
    #9811680

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

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

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