Легче ли оптимизировать Fortran, чем C, для тяжелых вычислений?

Время от времени я читаю, что Fortran является или может быть быстрее C для тяжелых вычислений. Это действительно так? Я должен признать, что почти не знаю Фортрана, но код Фортрана, который я видел до сих пор, не показал, что в языке есть функции, которых нет в Си.

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

Языки имеют похожие наборы функций. Разница в производительности объясняется тем, что Fortran говорит, что использование псевдонимов недопустимо, если только не используется оператор EQUIVALENCE. Любой код, имеющий псевдонимы, не является допустимым Fortran, но это зависит от программиста, а не от компилятора, чтобы обнаружить эти ошибки. Таким образом, компиляторы Fortran игнорируют возможные псевдонимы указателей памяти и позволяют им генерировать более эффективный код. Взгляните на этот маленький пример в C:

void transform (float *output, float const * input, float const * matrix, int *n)
{
    int i;
    for (i=0; i<*n; i++)
    {
        float x = input[i*2+0];
        float y = input[i*2+1];
        output[i*2+0] = matrix[0] * x + matrix[1] * y;
        output[i*2+1] = matrix[2] * x + matrix[3] * y;
    }
}

Эта функция будет работать медленнее, чем аналог Фортрана после оптимизации. Почему так? Если вы записываете значения в выходной массив, вы можете изменить значения матрицы. В конце концов, указатели могут перекрываться и указывать на один и тот же кусок памяти (включая intуказатель!). Компилятор C вынужден перезагружать четыре значения матрицы из памяти для всех вычислений.

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

К счастью, restrictключевое слово и строгое псевдонимы были введены в стандарт C99 для решения этой проблемы. Это хорошо поддерживается в большинстве компиляторов C ++ и в наши дни. Ключевое слово позволяет дать компилятору подсказку, что программист обещает, что указатель не совпадает с каким-либо другим указателем. Строгий-альясинг означает , что программист обещает , что указатели различного типа никогда не перекрывается, например, double*не будет перекрываться с int*(с конкретным исключением того, что char*и void*может перекрываться с чем - либо).

Если вы используете их, вы получите одинаковую скорость от C и Fortran. Тем не менее, возможность использовать restrictключевое слово только с функциями, критически важными для производительности, означает, что программы на C (и C ++) намного безопаснее и их легче писать. Например, рассмотрим недопустимый код Fortran:, CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30)который большинство компиляторов Fortran с радостью компилирует без каких-либо предупреждений, но вносит ошибку, которая появляется только на некоторых компиляторах, на некоторых аппаратных средствах и с некоторыми опциями оптимизации.

Да, в 1980 году; в 2008? зависит

Когда я начал профессионально программировать, доминирование в скорости на Фортране было под вопросом. Я помню, как читал об этом в «Докторе Доббсе» и рассказывал старшим программистам о статье - они смеялись.

Поэтому у меня есть два взгляда на это: теоретический и практический. Теоретически, Fortran сегодня не имеет внутреннего преимущества для C / C ++ или даже для любого языка, который допускает ассемблерный код. На практике сегодня Fortran по-прежнему пользуется преимуществами истории и культуры, построенной вокруг оптимизации числового кода.

Вплоть до и включая Fortran 77 вопросы разработки языка были в центре внимания оптимизации. Из-за состояния теории и технологии компилятора это часто означало ограничение возможностей и возможностей, чтобы дать компилятору наилучший шанс для оптимизации кода. Хорошая аналогия - думать о Fortran 77 как о профессиональной гоночной машине, которая жертвует характеристиками ради скорости. В наши дни компиляторы стали лучше на всех языках, а функции для повышения производительности программирования более ценны. Тем не менее, есть еще места, где люди в основном заинтересованы в скорости в научных вычислениях; эти люди, скорее всего, унаследовали код, обучение и культуру от людей, которые сами были программистами на Фортране.

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

Прекрасным местом для изучения истории и культуры Фортрана является Википедия. Запись в Fortran Wikipedia великолепна, и я очень ценю тех, кто потратил время и силы, чтобы сделать ее полезной для сообщества Fortran.

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

В некоторой степени Fortran был разработан с учетом оптимизации компилятора. Язык поддерживает операции с целыми массивами, где компиляторы могут использовать параллелизм (особенно на многоядерных процессорах). Например,

Плотное матричное умножение это просто:

matmul(a,b)

L2 норма вектора x равна:

sqrt(sum(x**2))

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

Предстоящий стандарт Fortran (2008) имеет совместные массивы, которые позволяют легко писать параллельный код. G95 (с открытым исходным кодом) и компиляторы из CRAY уже поддерживают его.

Да, Fortran может быть быстрым просто потому, что компиляторы могут оптимизировать / распараллелить его лучше, чем C / C ++. Но опять же, как и все в жизни, есть хорошие компиляторы и плохие компиляторы.

Забавно, что здесь много ответов от незнания языков. Это особенно верно для программистов на C / C ++, которые открыли старый код FORTRAN 77 и обсудили его слабые стороны.

Я полагаю, что проблема скорости - это в основном вопрос между C / C ++ и Fortran. В огромном коде это всегда зависит от программиста. Есть некоторые особенности языка, которые Фортран превосходит, и некоторые функции, которые делает С. Таким образом, в 2011 году никто не может сказать, какой из них быстрее.

Что касается самого языка, Fortran в настоящее время поддерживает функции Full OOP и полностью обратно совместим. Я использовал Fortran 2003 полностью, и я бы сказал, что использовать его было просто восхитительно. В некоторых аспектах Fortran 2003 все еще отстает от C ++, но давайте посмотрим на его использование. Fortran в основном используется для численных вычислений, и никто не использует причудливые функции C ++ ООП по соображениям скорости. В высокопроизводительных вычислениях C ++ практически некуда деваться (взгляните на стандарт MPI, и вы увидите, что C ++ устарел!).

В настоящее время вы можете просто заниматься программированием на разных языках с помощью Fortran и C / C ++. Есть даже интерфейсы для GTK + в Фортране. Есть бесплатные компиляторы (gfortran, g95) и много отличных коммерческих.

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

• ЧИСТЫЕ и ЭЛЕМЕНТНЫЕ ключевые слова о функциях. Это функции, которые не имеют побочных эффектов. Это позволяет выполнять оптимизацию в определенных случаях, когда компилятор знает, что одна и та же функция будет вызываться с одинаковыми значениями. Примечание: GCC реализует «чистый» как расширение языка. Другие компиляторы могут также. Межмодульный анализ также может выполнить эту оптимизацию, но это сложно.

• стандартный набор функций, которые работают с массивами, а не с отдельными элементами. Такие вещи, как sin (), log (), sqrt () принимают массивы вместо скаляров. Это облегчает оптимизацию рутины. Автоматическая векторизация дает те же преимущества в большинстве случаев, если эти функции встроены или встроены

• Встроенный комплексный тип. Теоретически это может позволить компилятору переупорядочить или исключить определенные инструкции в определенных случаях, но, скорее всего, вы увидите то же преимущество с struct {double re, im; }; идиома, используемая в C. Это ускоряет разработку, хотя операторы работают со сложными типами в фортране.

Я думаю, что ключевым моментом в пользу Fortran является то, что это язык, немного более подходящий для выражения математики на основе векторов и массивов. Упомянутая выше проблема анализа указателей является реальной на практике, поскольку переносимый код не может предположить, что вы можете что-то сказать компилятору. ВСЕГДА преимущество в вычислениях выражений заключается в том, что они ближе к тому, как выглядит домен. У C на самом деле нет массивов, если присмотреться, просто что-то вроде этого. Фортран имеет настоящие массивы. Что облегчает компиляцию для определенных типов алгоритмов, особенно для параллельных машин.

Глубоко в таких вещах, как система времени выполнения и соглашения о вызовах, C и современный Fortran достаточно похожи, поэтому трудно понять, что изменит ситуацию. Обратите внимание, что C здесь действительно является базовым C: C ++ - это совершенно другая проблема с очень разными характеристиками производительности.

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

То, что вы действительно должны спросить, это «код скомпилирован с компилятором Fortran X быстрее, чем эквивалентный код скомпилирован с компилятором C Y?» Ответ на этот вопрос, конечно, зависит от того, какие два компилятора вы выберете.

Другой вопрос, который можно было бы задать, звучит так: «Учитывая тот же объем усилий, приложенных для оптимизации их компиляторов, какой компилятор будет производить более быстрый код?» Ответом на этот вопрос будет Фортран . Компиляторы Fortran имеют ряд преимуществ:

• Fortran пришлось конкурировать с Assembly в тот день, когда некоторые пообещали никогда не использовать компиляторы, поэтому он был разработан для скорости. C был разработан, чтобы быть гибким.
• Ниша Фортрана была хрустом номера. В этом домене код никогда не бывает достаточно быстрым. Так что всегда было большое давление, чтобы язык был эффективным.
• Большая часть исследований по оптимизации компилятора проводится людьми, заинтересованными в ускорении обработки кода на Fortran, поэтому оптимизация кода на Fortran является гораздо более известной проблемой, чем оптимизация любого другого скомпилированного языка, и сначала в компиляторах Fortran появляются новые инновации.
• Biggie : C поощряет гораздо большее использование указателей, чем Fortran. Это резко увеличивает потенциальную область действия любого элемента данных в программе на C, что значительно затрудняет их оптимизацию. Обратите внимание, что Ada также намного лучше, чем C в этой области, и является гораздо более современным языком OO, чем обычно встречающийся Fortran77. Если вы хотите OO-язык, который может генерировать более быстрый код, чем C, это вариант для вас.
• Из-за своей узкой ниши заказчики компиляторов Fortran, как правило, больше заботятся об оптимизации, чем заказчики компиляторов Си.

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

Есть еще одна вещь, где Фортран отличается от С - и потенциально быстрее. У Fortran есть лучшие правила оптимизации, чем у C. В Fortran порядок вычисления выражений не определен, что позволяет компилятору оптимизировать его - если кто-то хочет форсировать определенный порядок, нужно использовать круглые скобки. В C порядок намного строже, но с опциями «-fast» они более смягчены и «(...)» также игнорируются. Я думаю, что у Фортрана есть путь, который приятно лежит посередине. (Ну, IEEE усложняет работу, так как некоторые изменения порядка оценки требуют, чтобы не происходило переполнения, что либо должно быть проигнорировано, либо затрудняет оценку).

Другая область более разумных правил - комплексные числа. Мало того, что до C 99 у них были они, также правила управляют ими лучше в Фортране; Поскольку библиотека gfortran на Фортране частично написана на C, но реализует семантику на Fortran, GCC получила опцию (которую также можно использовать с «обычными» программами на C):

-fcx-fortran-rules Комплексное умножение и деление следуют правилам Фортрана. Уменьшение диапазона выполняется как часть сложного деления, но нет проверки, является ли результат сложного умножения или деления «NaN + I * NaN», с попыткой спасти ситуацию в этом случае.

Упомянутые выше правила псевдонимов являются еще одним бонусом, а также - по крайней мере в принципе - операциями с целым массивом, которые, если их должным образом учесть оптимизатор компилятора, могут привести к более быстрому коду. С другой стороны, если определенная операция занимает больше времени, например, если выполняется присвоение выделяемому массиву, необходимо выполнить много проверок (перераспределить? [Функция Fortran 2003], имеются шаги массива и т. Д.), Которые делают простая операция более сложна за кулисами - и, следовательно, медленнее, но делает язык более мощным. С другой стороны, операции с массивами с гибкими границами и шагами облегчают написание кода - и компилятор обычно лучше оптимизирует код, чем пользователь.

В целом, я думаю, что и C, и Fortran примерно одинаково быстры; выбор должен быть больше: какой язык больше нравится, или более полезны операции с целыми массивами Fortran и его лучшая переносимость, или лучшее взаимодействие с системными библиотеками и библиотеками пользовательского интерфейса в C.

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

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

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

Я сравниваю скорость Fortran, C и C ++ с классическим тестом Levine-Callahan-Dongarra от netlib. Мультиязычная версия с OpenMP http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors C более уродливая, так как она началась с автоматического перевода, а также с определенными ограничениями и прагмами. компиляторы. C ++ - это просто C с шаблонами STL, где это применимо. На мой взгляд, STL представляет собой смешанный пакет с точки зрения того, улучшает ли он ремонтопригодность.

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

Компилятору C / C ++, который на данный момент наиболее широко используется, не хватает авто-векторизации, на которую сильно влияют эти тесты.

В связи с постом, который был опубликован непосредственно перед этим: есть несколько примеров, где в Фортране используются скобки для определения более быстрого или более точного порядка оценки. Известные компиляторы C не имеют возможности соблюдать скобки, не отключая более важные оптимизации.

Я программист-любитель, и я "средний" на обоих языках. Мне легче писать быстрый код на Фортране, чем на C (или C ++). И Fortran, и C являются «историческими» языками (по сегодняшним стандартам), интенсивно используются и хорошо поддерживают бесплатный и коммерческий компилятор.

Я не знаю, является ли это историческим фактом, но Фортран чувствует, что он построен так, чтобы быть параллельным / распределенным / векторизованным / каким бы многоядерным он ни был. И сегодня это в значительной степени «стандартная метрика», когда мы говорим о скорости: «она масштабируется?»

За чистоту процессора я люблю Фортран. Для всего, что связано с IO, мне легче работать с C. (в любом случае это сложно в любом случае).

Теперь, конечно, для параллельного математического кода вы, вероятно, захотите использовать свой графический процессор. И C, и Fortran имеют много более или менее хорошо интегрированного интерфейса CUDA / OpenCL (а теперь и OpenACC).

Мой умеренно объективный ответ таков: если вы знаете оба языка одинаково / плохо, то я думаю, что Fortran быстрее, потому что мне легче писать параллельный / распределенный код на Fortran, чем на C. (как только вы поняли, что вы можете писать "freeform" fortran и не просто строгий код F77)

Вот второй ответ для тех, кто хочет меня понизить, потому что им не нравится первый ответ: оба языка имеют функции, необходимые для написания высокопроизводительного кода. Таким образом, это зависит от алгоритма, который вы реализуете (интенсивное использование процессора, интенсивное использование памяти), аппаратного обеспечения (одноядерный процессор, многоядерный распределительный суперкомпьютер, GPGPU, FPGA), ваших навыков и, в конечном счете, самого компилятора. И C, и Fortran имеют отличный компилятор. (Я серьезно удивлен тем, насколько продвинуты компиляторы Фортрана, но так же, как и компиляторы Си).

PS: я рад, что вы специально исключили библиотеки, потому что у меня есть много плохого, что можно сказать о библиотеках Fortran GUI. :)

Я пару лет занимался обширной математикой с Фортраном и Си. Исходя из своего собственного опыта, я могу сказать, что FORTRAN иногда действительно лучше, чем C, но не за его скорость (можно заставить C работать так же быстро, как FORTRAN, используя соответствующий стиль кодирования), а скорее из-за очень хорошо оптимизированных библиотек, таких как LAPACK, и из-за отличное распараллеливание. На мой взгляд, с FORTRAN действительно неудобно работать, и его преимущества недостаточно хороши, чтобы устранить этот недостаток, поэтому сейчас я использую C + GSL для расчетов.

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

В любом случае, хороший программист может писать на Фортране на любом языке.

Я не слышал, чтобы Фортан был значительно быстрее, чем С, но вполне возможно, что в некоторых случаях он будет быстрее. И ключ не в языковых особенностях, которые присутствуют, а в тех, которые (обычно) отсутствуют.

Примером являются C указатели. Указатели на Си используются практически везде, но проблема с указателями заключается в том, что компилятор обычно не может определить, указывают ли они на разные части одного и того же массива.

Например, если вы написали подпрограмму strcpy, которая выглядела так:

strcpy(char *d, const char* s)
{
  while(*d++ = *s++);
}

Компилятор должен работать в предположении, что d и s могут быть перекрывающимися массивами. Таким образом, он не может выполнить оптимизацию, которая выдала бы другие результаты, когда массивы перекрываются. Как и следовало ожидать, это значительно ограничивает виды оптимизации, которые могут быть выполнены.

[Следует отметить, что в C99 есть ключевое слово restrict, которое явно указывает компиляторам, что указатели не перекрываются. Также обратите внимание, что у Фортрана тоже есть указатели, семантика которых отличается от семантики C, но указатели не являются повсеместными, как в C.]

Но, возвращаясь к проблеме C и Fortran, вполне возможно, что компилятор Fortran способен выполнить некоторые оптимизации, которые могут быть невозможны для (написанной прямо) программы на C. Так что я не был бы слишком удивлен иском. Тем не менее, я ожидаю, что разница в производительности не будет такой большой. [~ 5-10%]

Быстро и просто: оба одинаково быстры, но Фортран проще. То, что действительно быстрее в конечном итоге, зависит от алгоритма, но в любом случае разница в скорости отсутствует. Это то, что я узнал на семинаре по Fortran в высокопроизводительном вычислительном центре Штутгарда, Германия, в 2015 году. Я работаю с Fortran и C и разделяю это мнение.

Объяснение:

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

Фортран был разработан для научного программирования. По этой причине он поддерживает быстрое написание синтаксиса кода, так как это является основной целью Fortran. В отличие от общественного мнения, Фортран не является устаревшим языком программирования. Его последний стандарт - 2010, и новые компиляторы публикуются на регулярной основе, так как наиболее высокопроизводительный код написан на Фортране. Fortran также поддерживает современные функции в качестве директив компилятора (на языке C).

Пример: мы хотим дать большую структуру в качестве входного аргумента функции (fortran: подпрограмма). Внутри функции аргумент не изменяется.

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

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

Обычно FORTRAN работает медленнее, чем C. C может использовать указатели аппаратного уровня, позволяющие программисту оптимизировать работу вручную. ФОРТРАН (в большинстве случаев) не имеет доступа к аппаратному взлому адресации памяти. (VAX FORTRAN - другая история.) Я использовал FORTRAN и выключал его с 70-х годов. (В самом деле.)

Однако, начиная с 90 - х FORTRAN развивалась , чтобы включать в себя конкретные языковые конструкции , которые могут быть оптимизированы в своей сути параллельных алгоритмов , которые могут действительно кричать на многоядерной процессоре. Например, автоматическая векторизация позволяет нескольким процессорам обрабатывать каждый элемент вектора данных одновременно. 16 процессоров - 16 элементов вектора - обработка занимает 1/16 времени.

В C вы должны управлять своими собственными потоками и тщательно разрабатывать свой алгоритм для многопроцессорной обработки, а затем использовать кучу вызовов API, чтобы убедиться в правильности параллелизма.

В FORTRAN вам нужно только тщательно разработать свой алгоритм для многопроцессорной обработки. Компилятор и среда выполнения могут обработать все остальное за вас.

Вы можете прочитать немного о High Performance Fortran , но вы найдете много мертвых ссылок. Вам лучше прочитать о параллельном программировании (например, OpenMP.org ) и о том, как это поддерживает FORTRAN.

Более быстрый код не совсем соответствует языку, это компилятор, так что вы можете видеть ms-vb «компилятор», который генерирует раздутый, медленный и избыточный объектный код, который связан внутри «.exe», но powerBasic генерирует слишком лучший код. Объектный код, созданный компиляторами C и C ++, генерируется в некоторых фазах (по крайней мере, в 2), но по своей конструкции большинство компиляторов Fortran имеют по крайней мере 5 фаз, включая высокоуровневые оптимизации, поэтому по замыслу Fortran всегда будет иметь возможность генерировать высоко оптимизированный код. Таким образом, в конце концов, компилятор - это не тот язык, который вам нужен, лучший компилятор, которого я знаю, - это Intel Fortran Compiler, потому что вы можете получить его в LINUX и Windows, и вы можете использовать VS в качестве IDE, если вы ищете дешевый тугой компилятор вы всегда можете передать на OpenWatcom.

Подробнее об этом: http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html

Fortran имеет лучшие процедуры ввода / вывода, например, подразумеваемое средство do дает гибкость, с которой стандартная библиотека C не может сравниться.

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

Используя современные стандарты и компилятор, нет!

Некоторые из них предположили, что FORTRAN работает быстрее, потому что компилятору не нужно беспокоиться о псевдонимах (и, следовательно, он может делать больше предположений при оптимизации). Тем не менее, это было решено в C начиная со стандарта C99 (я думаю) с включением ключевого слова restrict. Что в основном говорит компилятору, что в заданной области указатель не является псевдонимом. Кроме того, C обеспечивает правильную арифметику указателей, где такие вещи, как псевдонимы, могут быть очень полезны с точки зрения производительности и распределения ресурсов. Хотя я думаю, что более поздняя версия FORTRAN позволяет использовать «правильные» указатели.

В современных реализациях C вообще превосходит FORTRAN (хотя он тоже очень быстрый).

http://benchmarksgame.alioth.debian.org/u64q/fortran.html

РЕДАКТИРОВАТЬ:

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

http://julialang.org/benchmarks/

Вы можете видеть, что C, как правило, превосходит Fortran в большинстве случаев (снова см. Ниже критические замечания, которые применимы и здесь); как заявляли другие, сравнительный анализ - это неточная наука, которую легко загрузить, чтобы отдать предпочтение одному языку перед другими. Но это говорит о том, что Fortran и C имеют одинаковую производительность.

Fortran может очень удобно обрабатывать массивы, особенно многомерные. Нарезка элементов многомерного массива в Fortran может быть намного проще, чем в C / C ++. C ++ теперь имеет библиотеки, которые могут выполнять эту работу, такие как Boost или Eigen, но они все-таки внешние библиотеки. В Фортране эти функции присущи.

Быстрее или удобнее ли разрабатывать Fortran, зависит от того, какую работу вы должны выполнить. Как научный специалист по геофизике, я делал большинство вычислений на Фортране (я имею в виду современный Фортран,> = F90).

Это более чем субъективно, потому что это влияет на качество компиляторов и тому подобное больше всего на свете. Однако, чтобы более прямо ответить на ваш вопрос, говоря с точки зрения языка / компилятора, в Fortran over C нет ничего, что сделало бы его по своей природе быстрее или лучше, чем C. Если вы выполняете тяжелые математические операции, все сводится к качество компилятора, умение программиста на каждом языке и встроенные библиотеки поддержки математики, которые поддерживают эти операции, чтобы в конечном итоге определить, что будет быстрее для данной реализации.

РЕДАКТИРОВАТЬ: Другие люди, такие как @Nils, подняли хороший вопрос о разнице в использовании указателей в C и возможности псевдонимов, что, возможно, делает наиболее наивные реализации медленнее в C. Однако, есть способы справиться с этим в C99 через флаги оптимизации компилятора и / или в том, как на самом деле написан Си. Это хорошо освещено в ответе @Nils и последующих комментариях к его ответу.

Большинство постов уже содержат убедительные аргументы, поэтому я просто добавлю пресловутые 2 цента к другому аспекту.

Быть Fortran быстрее или медленнее с точки зрения вычислительной мощности в конечном итоге может иметь значение, но если для разработки чего-то в Fortran требуется в 5 раз больше времени, потому что:

• ему не хватает хорошей библиотеки для задач, отличных от перебора чисел
• не хватает достойного инструмента для документации и модульного тестирования
• это язык с очень низкой выразительностью, который взлетает до количества строк кода.
• у него очень плохая обработка строк
• у него огромное количество проблем среди разных компиляторов и архитектур, сводящих вас с ума.
• у него очень плохая стратегия ввода-вывода (READ / WRITE последовательных файлов. Да, файлы с произвольным доступом существуют, но вы когда-нибудь видели, чтобы они использовались?)
• это не поощряет хорошие практики развития, модульность.
• эффективное отсутствие полностью стандартного, полностью совместимого компилятора с открытым исходным кодом (и gfortran, и g95 не поддерживают все)
• очень плохая совместимость с C (искажение: одно подчеркивание, два подчеркивания, без подчеркивания, в общем, одно подчеркивание, но два, если есть другое подчеркивание. и просто давайте не углубляться в ОБЩИЕ блоки ...)

Тогда вопрос не имеет значения. Если что-то происходит медленно, большую часть времени вы не можете улучшить его за пределами указанного предела. Если вы хотите что-то быстрее, измените алгоритм. В конце концов, компьютерное время дешево. Человеческого времени нет. Цените выбор, который сокращает человеческое время. Если это увеличивает время работы компьютера, это все равно экономически эффективно.

Фортран традиционно не устанавливает такие параметры, как -fp: strict (который ifort требует для включения некоторых функций в USE IEEE_arithmetic, части стандарта f2003). Intel C ++ также не устанавливает -fp: strict по умолчанию, но это требуется, например, для обработки ERRNO, а другие компиляторы C ++ не делают удобным отключение ERRNO или оптимизацию усиления, например сокращение simd. gcc и g ++ потребовали, чтобы я настроил Makefile, чтобы избежать использования опасной комбинации -O3 -ffast-math -fopenmp -march = native. Помимо этих проблем, этот вопрос об относительной производительности становится более требовательным и зависит от местных правил выбора компиляторов и опций.