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

363

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

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

  • 48
    Нереально субъективно из ответов, приведенных ниже. Правильный заголовок: «Существуют ли какие-то основополагающие архитектурные причины, по которым компилятор Фортрана МОЖЕТ производить код с более высокими показателями, чем компилятор C», но это просто придирчивость.
  • 3
    Думаю, заглавный вопрос не столько субъективен, сколько недоразумен. Более подробный вопрос не субъективен.
Показать ещё 13 комментариев
Теги:
performance
fortran
compiler-construction

22 ответа

392
Лучший ответ

Языки имеют схожие функции. Разница в производительности возникает из-за того, что Fortran говорит, что сглаживание не допускается, если не используется оператор EQUIVALENCE. Любой код с псевдонимом не является допустимым. Фортран, но программист, а не компилятор, обнаруживает эти ошибки. Таким образом, компиляторы 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;
    }
}

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

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

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

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

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

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

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

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

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

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

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

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

56

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

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

matmul(a,b)

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

sqrt(sum(x**2))

Кроме того, инструкции, такие как процедуры FORALL, PURE и ELEMENTAL и т.д., также помогают оптимизировать код. Даже указатели в Fortran не так гибки, как C из-за этой простой причины.

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

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

  • 8
    Просто прочитайте о ключевом слове ELEMENTAL и ... вау.
  • 0
    Вы можете также прочитать pimiddy.wordpress.com/2012/04/20/pure-functions-in-cc и open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0078r0.pdf .
Показать ещё 1 комментарий
31

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

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

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

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

  • 7
    Не могли бы вы добавить источник, конкретный опыт или научный институт / агентство высокопроизводительных вычислений, которое либо уходит от C ++ для будущих проектов, либо переписывает проекты C ++ на другой язык. Я спрашиваю только потому, что знаю как минимум два научных учреждения, Sandia и CERN, которые интенсивно используют c ++ для своего высокопроизводительного моделирования. Кроме того, Сандия перевела одно из своих программ для моделирования (LAMMPS) с Fortran на C ++, добавив ряд удивительных улучшений.
  • 5
    LAMMPS написан на чрезвычайно простом C ++, который не использует большинство современных возможностей языка. Он представляет C ++, который программисты на Фортране, знающие C, пишут после изучения C ++ 98. Это не значит, что LAMMPS написан плохо, просто это не тот пример, который вы хотели бы привести, выступая за C ++ в HPC.
27

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

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

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

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

  • 1
    msgstr "но, вероятно, вы увидите то же преимущество с struct { double re, im; }; идиома, используемая в C". Компиляторы Си, скорее всего, будут возвращать эту структуру в виде sret с выделением пространства стеком вызывающей стороны, передавая указатель вызываемому объекту, который его заполняет. Это в несколько раз медленнее, чем возвращение нескольких значений в регистрах, как это делает компилятор Фортрана. Обратите внимание, что C99 исправил это в особом случае complex.
  • 0
    Я не уверен, что согласен с вашей главной причиной. Мне лично нравится использовать fortran для тяжелого математического кода, где массивы и математические функции являются наиболее важной частью кода. Но я точно знаю, что во многих государственных учреждениях и банках они продолжают использовать фортран для поддержки или расширения устаревшего кода. Я лично использовал Fortran, чтобы расширить код профессора на мой доктор философии. комитет написал.
Показать ещё 1 комментарий
24

Я думаю, что ключевым моментом в пользу Fortran является то, что это язык, немного более подходящий для выражения математики на основе вектора и массива. Указанная выше проблема анализа указателей на практике реальна, поскольку переносимый код не может действительно предположить, что вы можете что-то сказать компилятору. Преимущество выражения computaitons в ALWAYS намного ближе к тому, как выглядит домен. C на самом деле не имеет массивов, если вы внимательно посмотрите, что-то такое ведет себя так. У Fortran есть реальные арравы. Это упрощает компиляцию для определенных типов алгоритмов, особенно для параллельных машин.

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

19

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

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

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

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

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

  • 3
    Согласен. И позвольте мне добавить, что когда в конце 50-х - начале 60-х был представлен Fortran (это был первый язык высокого уровня), многие скептически относились к его эффективности. Поэтому его разработчики должны были доказать, что Fortran может быть эффективным и полезным, и начали «оптимизировать его до смерти», чтобы доказать свою точку зрения. C пришел гораздо позже (в начале и середине 70-х) и ему было нечего доказывать, так сказать. Но к этому времени было написано много кода на фортранском языке, поэтому научное сообщество придерживалось его и до сих пор делает. Я не программирую на Фортране, но научился ссылаться на вызовы Фортрана из C ++.
  • 2
    Исследования по оптимизации компилятора были более разнообразными, чем вы думаете. Например, история реализаций LISP полна успехов в выполнении обработки чисел быстрее, чем Fortran (который остается претендентом по умолчанию на вызов). Кроме того, огромная часть оптимизации компилятора была нацелена на промежуточные представления компилятора, что означает, что, за исключением различий в семантике (например, псевдонимы), они применяются к любому языку программирования данного класса.
Показать ещё 3 комментария
18

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

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

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

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

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

  • 0
    Что может значимо «спасти» в деле Nan + INan? Что отличает бесконечности от NaN, так это то, что бесконечности подписаны. Операции, включающие некомплексные бесконечности, которые приводят к запутанному знаку, дают NaN, и я не вижу причины, по которой комплексные числа должны поступать иначе. Если умножить (DBL_MAX, DBL_MAX) на (2,2), возвести в квадрат результат, а затем возвести его в квадрат, каким должен быть знак результата в случае отсутствия переполнения? Что вместо этого умножить его на (1.001, DBL_MAX)? Я бы расценил (NaN, NaN) как правильный ответ, а любую комбинацию бесконечности и NaN как бессмысленную.
12

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

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

Компилятор C/С++, который на сегодняшний день является самым распространенным использованием, не имеет автоматической векторизации, на которой эти критерии сильно зависят.

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

12

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

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

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

  • 11
    Почти обновил это. Проблема заключается в том, что Fortran имеет некоторые преимущества , присущие. Тем не менее, вы совершенно уверены, что важнее всего обращать внимание на компилятор, а не на язык.
10

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

9

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

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

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

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

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

Вот 2-й ответ для тех, кто хочет понизить меня, потому что им не нравится первый ответ: на обоих языках есть функции, необходимые для написания высокопроизводительного кода. Таким образом, он зависит от алгоритма, который вы реализуете (интенсивный интенсивный интенсивный? Интенсивный? Объем памяти?), Аппаратное обеспечение (однопроцессорный многоядерный дистрибутив суперкомпьютера GPGPU? FPGA?), Ваше умение и, в конечном счете, сам компилятор. У C и Fortran есть потрясающий компилятор. (я серьезно удивлен тем, насколько продвинутыми компиляторами Fortran являются, но также являются компиляторами C).

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

8

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

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

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

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

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

[Я должен отметить, что C99 имеет ключевое слово "ограничивать", которое явно сообщает компиляторам, что указатели не перекрываются. Также обратите внимание, что в Fortran также есть указатели с семантикой, отличной от семантики C, но указатели не являются повсеместными, как в C.]

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

8

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

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

  • 0
    @ Скотт Клоусон: ты получил -1, и я не знаю почему. +1 я бы исправил это. Однако следует учитывать, что Фортран существует дольше, чем многие наши родители. Много времени потрачено на оптимизацию вывода компилятора: D
  • 0
    @sixlettervariables - хорошо, сэр! Ударь меня к этому. Иногда ТАК странно ...
Показать ещё 3 комментария
7

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

Объяснение:

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

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

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

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

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

  • 0
    Можете ли вы написать собственное параллельное приложение на C (т.е. без вызова каких-либо библиотек?). Можете ли вы написать собственное параллельное приложение на Фортране? Да, несколькими разными способами. Ergo, Fortran "быстрее". Хотя, честно говоря, в 2010 году, когда вы написали свой комментарий, поддержка параллельных операций и функций совместного использования массивов в Fortran, вероятно, была не так широко распространена, как сейчас.
7

Обычно FORTRAN медленнее, чем C. C может использовать указатели аппаратного уровня, позволяющие программисту оптимизировать вручную. FORTRAN (в большинстве случаев) не имеет доступа к хакерским адресам аппаратной памяти. (VAX FORTRAN - это еще одна история.) Я использовал FORTRAN с 70-х годов. (Действительно.)

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

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

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

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

  • 6
    @ S.Lott: Я не мог представить, как ужасный код на C должен выглядеть так же хорошо, как просто написанный на Fortran для большинства кодов, которые у нас здесь есть ... и я программист на C. Вы получите лучшую производительность из более простого кода на Фортране. Не то чтобы вы или я не могли найти контрпример. : D
  • 1
    Ни один компилятор не собирается распределять вычисления по 16 элементам вектора на 16 разных ЦП. Это было бы в сотни раз медленнее ...
Показать ещё 10 комментариев
4

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

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

2

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

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

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

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

EDIT:

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

http://julialang.org/benchmarks/

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

  • 0
    Было бы хорошо узнать, почему комментарии отклонены.
  • 0
    Спасибо за комментарии. Я надеюсь, что мой «ответ» более квалифицирован.
Показать ещё 1 комментарий
2

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

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

  • 1
    У вас есть тесты, которые показывают, что Фортран побеждает C за ввод-вывод?
2

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

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

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

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

  • 3
    не одобряется, потому что, хотя вы поднимаете интересные вопросы, которые дополняют обсуждение преимуществ / недостатков Fortrans по сравнению с другими языками (с которыми я не полностью согласен), на самом деле это не ответ на вопрос ...
  • 0
    @steabert: на самом деле, я сказал, I will just add the proverbial 2 cents to a different aspect
Показать ещё 7 комментариев
0

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

EDIT: Другие люди, такие как @Nils, подняли точку зрения на разницу в использовании указателей на C и возможность для псевдонимов, что, возможно, делает более наивные реализации медленнее на C. Однако есть способы справиться с что на C99, посредством флагов оптимизации компилятора и/или в том, как на самом деле написано C. Это хорошо освещено в ответе @Nils и последующих комментариях, которые следуют его ответу.

  • 0
    Это звучит как эталонный тест алгоритма. Что занимает меньше времени, Фортран или С? Не звучит субъективно для меня. Возможно, я что-то упустил.
  • 1
    Не согласен. Вы сравниваете компиляторы, а не языки. Я думаю, что первоначальный вопрос заключается в том, есть ли что-либо в ЯЗЫКЕ, что делает его по сути лучше. Другие ответы здесь входят в некоторые тонкие сомнительные различия, но я думаю, что мы больше всего согласны, что они в шуме.
Показать ещё 2 комментария
-2

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

  • 0
    Недавние обновления gcc исправили проблему с сочетанием Openmp и fast-math.
  • 0
    Этот ответ на самом деле о пользователях, которые не понимают флаги по умолчанию для своих компиляторов, а не сами языки.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню