Легче ли оптимизировать Fortran, чем C, для тяжелых вычислений?
https://stackoverflow.com/questions/146159
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Время от времени я читаю, что Фортран быстрее или может быть быстрее C для тяжелых вычислений.Неужели это правда?Должен признаться, что я почти не знаю Фортрана, но код Фортрана, который я видел до сих пор, не показал, что у языка есть функции, которых нет в C.
Если это правда, скажите, пожалуйста, почему.Пожалуйста, не говорите мне, какие языки или библиотеки подходят для обработки чисел, я не собираюсь писать приложение или библиотеку для этого, мне просто любопытно.
Решение
Языки имеют схожие наборы функций.Разница в производительности связана с тем, что в Фортране псевдонимы не разрешены, если не используется оператор EQUIVALENCE.Любой код, имеющий псевдонимы, не является допустимым для Фортрана, но обнаружение этих ошибок зависит от программиста, а не от компилятора.Таким образом, компиляторы Фортрана игнорируют возможные псевдонимы указателей памяти и позволяют им генерировать более эффективный код.Взгляните на этот небольшой пример на 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 вынужден перезагрузить четыре значения матрицы из памяти для всех вычислений.
В Фортране компилятор может загрузить значения матрицы один раз и сохранить их в регистрах.Это возможно, поскольку компилятор Фортрана предполагает, что указатели/массивы не перекрываются в памяти.
К счастью, restrict Ключевое слово и строгий псевдоним были введены в стандарт C99 для решения этой проблемы.В настоящее время он также хорошо поддерживается большинством компиляторов C++.Ключевое слово позволяет вам дать компилятору подсказку о том, что программист обещает, что указатель не будет псевдонимом какого-либо другого указателя.Строгое псевдонимирование означает, что программист обещает, что указатели разных типов никогда не будут перекрываться, например double* не будет пересекаться с int* (за конкретным исключением, которое char* и void* может пересекаться с чем угодно).
Если вы их используете, вы получите ту же скорость, что и на C и на Фортране.Однако возможность использовать restrict Ключевое слово только для функций, критически важных для производительности, означает, что программы на C (и C++) намного безопаснее и проще писать.Например, рассмотрим неверный код Фортрана: CALL TRANSFORM(A(1, 30), A(2, 31), A(3, 32), 30), который большинство компиляторов Фортрана с радостью компилирует без предупреждения, но содержит ошибку, которая проявляется только на некоторых компиляторах, на некотором оборудовании и с некоторыми параметрами оптимизации.
Другие советы
Да, в 1980 году;в 2008?зависит от
Когда я начал профессионально программировать, доминированию Фортрана в скорости только что был поставлен вызов.Я помню прочитал об этом в Dr.Доббс и рассказал о статье программистам постарше — они засмеялись.
Поэтому у меня есть два мнения по этому поводу: теоретическое и практическое. В теории Сегодня Fortran не имеет существенных преимуществ перед C/C++ или даже над любым языком, допускающим ассемблерный код. На практике Сегодня Фортран по-прежнему пользуется преимуществами наследия истории и культуры, построенной на оптимизации числового кода.
Вплоть до выхода Fortran 77 включительно при проектировании языка основное внимание уделялось оптимизации.Из-за состояния теории и технологии компиляторов это часто означало ограничивающий функции и возможности, чтобы дать компилятору наилучшие возможности для оптимизации кода.Хорошая аналогия — представить Fortran 77 как профессиональный гоночный автомобиль, жертвующий характеристиками ради скорости.В наши дни компиляторы для всех языков стали лучше, а функции, повышающие производительность программистов, стали более цениться.Однако все еще есть места, где люди в основном озабочены скоростью научных вычислений;эти люди, скорее всего, унаследовали код, обучение и культуру от людей, которые сами были программистами на Фортране.
Когда кто-то начинает говорить об оптимизации кода, возникает множество проблем, и лучший способ понять это — прятаться там, где находятся люди, чья работа — иметь быстрый цифровой код.Но имейте в виду, что такой критически чувствительный код обычно составляет небольшую часть от общего числа строк кода и очень специализирован:Большая часть кода на Фортране так же «неэффективна», как и большая часть другого кода на других языках. оптимизация даже не должна быть главной задачей такого кода.
Прекрасное место для начала изучения истории и культуры Фортрана — это Википедия. Запись на Фортране в Википедии превосходен, и я очень ценю тех, кто потратил время и усилия, чтобы сделать его ценным для сообщества Fortran.
(Сокращенная версия этого ответа могла бы быть комментарием в отличной теме, начатой Нильс но у меня нет кармы, чтобы сделать это.На самом деле, я бы, вероятно, вообще ничего не написал, если бы эта ветка не содержала реального информационного содержания и обмена информацией, а не пламенных войн и языкового фанатизма, что является моим основным опытом работы с этой темой.Я была потрясена и должна была поделиться любовью.)
В некоторой степени Фортран был разработан с учетом оптимизации компилятора.Язык поддерживает операции с целыми массивами, где компиляторы могут использовать параллелизм (особенно на многоядерных процессорах).Например,
Умножение плотной матрицы просто:
matmul(a,b)
Норма L2 вектора x равна:
sqrt(sum(x**2))
Более того, такие высказывания, как FORALL, PURE & ELEMENTAL процедуры и т. д.дополнительная помощь в оптимизации кода.Даже указатели в Фортране не такие гибкие, как в C, по этой простой причине.
Будущий стандарт Фортрана (2008 г.) содержит совместные массивы, которые позволяют легко писать параллельный код.G95 (с открытым исходным кодом) и компиляторы от CRAY уже поддерживают его.
Так что да, Фортран может быть быстрым просто потому, что компиляторы могут оптимизировать/распараллеливать его лучше, чем C/C++.Но опять же, как и во всем остальном в жизни, есть хорошие и плохие компиляторы.
Забавно, что здесь много ответов от незнания языков.Это особенно актуально для программистов C/C++, которые открыли старый код FORTRAN 77 и обсуждают его слабые места.
Я полагаю, что проблема скорости — это в основном вопрос между C/C++ и Fortran.В Huge коде это всегда зависит от программиста.Есть некоторые особенности языка, которые Фортран превосходит, и некоторые функции, которые делает C.Итак, в 2011 году никто толком не сможет сказать, кто из них быстрее.
Что касается самого языка, Fortran в настоящее время поддерживает функции полного ООП и полностью обратно совместим.Я тщательно использовал Fortran 2003 и могу сказать, что было просто приятно его использовать.В некоторых аспектах Fortran 2003 все еще отстает от C++, но давайте посмотрим на его использование.Фортран в основном используется для числовых вычислений, и никто не использует сложные функции ООП C++ из соображений скорости.В высокопроизводительных вычислениях C++ почти некуда пойти (взгляните на стандарт MPI, и вы увидите, что C++ устарел!).
Сегодня вы можете просто заниматься программированием на смешанных языках с использованием Fortran и C/C++.В Фортране даже есть интерфейсы для GTK+.Есть бесплатные компиляторы (gfortran, g95) и множество отличных коммерческих.
Есть несколько причин, по которым Фортран может быть быстрее.Однако величина, которую они имеют значение, настолько несущественна или ее все равно можно обойти, что это не должно иметь значения.Основная причина использования Fortran в настоящее время — поддержка или расширение устаревших приложений.
Ключевые слова PURE и ELEMENTAL для функций.Это функции, которые не имеют побочных эффектов.Это позволяет проводить оптимизацию в определенных случаях, когда компилятор знает, что одна и та же функция будет вызываться с теми же значениями. Примечание:GCC реализует «чистый» язык как расширение.Другие компиляторы тоже могут.Межмодульный анализ также может выполнить эту оптимизацию, но это сложно.
стандартный набор функций, работающих с массивами, а не с отдельными элементами.Такие вещи, как sin(), log(), sqrt(), принимают массивы вместо скаляров.Это облегчает оптимизацию рутины. Автоматическая векторизация дает те же преимущества в большинстве случаев, если эти функции являются встроенными или встроенными.
Встроенный комплексного типа.Теоретически это может позволить компилятору изменить порядок или исключить определенные инструкции в определенных случаях, но, вероятно, вы увидите ту же самую выгоду с struct { double re, im;};идиома, используемая в C.Однако это ускоряет разработку, поскольку операторы работают со сложными типами в Фортране.
Я думаю, что ключевым моментом в пользу Фортрана является то, что этот язык немного больше подходит для выражения математических вычислений на основе векторов и массивов.Проблема анализа указателей, упомянутая выше, реальна на практике, поскольку переносимый код не может реально предполагать, что вы можете что-то сообщить компилятору.ВСЕГДА есть преимущество в том, что вычисления выражений приближены к тому, как выглядит предметная область.В C на самом деле вообще нет массивов, если присмотреться, просто что-то вроде того и ведет себя так.В Фортране есть настоящие массивы.Это упрощает компиляцию определенных типов алгоритмов, особенно для параллельных машин.
В глубине души в таких вещах, как система времени выполнения и соглашения о вызовах, C и современный Фортран настолько похожи, что трудно понять, что может иметь значение.Обратите внимание, что C здесь на самом деле является базой C:C++ — это совершенно другая проблема с совершенно другими характеристиками производительности.
Не существует такого понятия, чтобы один язык был быстрее другого, поэтому правильный ответ: нет.
Что вы действительно должны спросить, так это «Скомпилируется ли код с компилятором Fortran x быстрее, чем эквивалентный код, скомпилированный с C Compiler y?» Ответ на этот вопрос, конечно, зависит от того, какие два компилятора вы выбираете.
Другой вопрос, который можно было бы задать, был бы в соответствии с «Учитывая то же количество усилий, которые прилагаются к оптимизации в их компиляторах, какой компилятор будет производить более быстрый код?» Ответ на это будет на самом деле Фортран.Компиляторы Фортрана имеют определенные преимущества:
- Фортрану приходилось конкурировать с Ассемблером в те времена, когда некоторые поклялись никогда не использовать компиляторы, поэтому он был разработан для скорости.C был разработан, чтобы быть гибким.
- Ниша Фортрана была связана с числами.В этом домене код никогда достаточно быстро.Поэтому всегда было большое давление, чтобы сохранить эффективность языка.
- Большая часть исследований по оптимизации компилятора проводится людьми, заинтересованными в ускорении кода обработки чисел Фортрана, поэтому оптимизация кода Фортрана — гораздо более известная проблема, чем оптимизация любого другого компилируемого языка, и новые инновации появляются в первую очередь в компиляторах Фортрана.
- Бигги:C поощряет гораздо большее использование указателей, чем Fortran.Это резко увеличивает потенциальный объем любого элемента данных в программе на C, что значительно затрудняет их оптимизацию.Обратите внимание, что Ada также намного лучше, чем C в этой области, и является гораздо более современным объектно-ориентированным языком, чем широко распространенный Fortran77.Если вам нужен объектно-ориентированный язык, который может генерировать код быстрее, чем C, это вариант для вас.
- Опять же, из-за своей ниши, связанной с обработкой чисел, клиенты компиляторов Fortran, как правило, больше заботятся об оптимизации, чем клиенты компиляторов C.
Однако ничто не мешает кому-то приложить массу усилий для оптимизации своего компилятора C и заставить его генерировать более качественный код, чем компилятор Fortran их платформы.Фактически, большие продажи компиляторов C делают этот сценарий вполне осуществимым.
Есть еще один момент, в котором Фортран отличается от Си — и потенциально быстрее.В Фортране правила оптимизации лучше, чем в C.В Фортране порядок вычисления выражений не определен, что позволяет компилятору оптимизировать его — если кто-то хочет установить определенный порядок, нужно использовать круглые скобки.В C порядок гораздо более строгий, но с опциями «-fast» они более расслаблены и «(...)» также игнорируются.Я думаю, что в Фортране есть способ, который находится посередине.(Ну, IEEE усложняет жизнь, поскольку некоторые изменения порядка вычислений требуют, чтобы не происходило переполнения, что либо нужно игнорировать, либо затруднять вычисление).
Еще одна область более разумных правил — комплексные числа.Мало того, что они появились в C только до C 99, но и правила управляют ими лучше в Фортране;поскольку библиотека gfortran для Fortran частично написана на C, но реализует семантику Fortran, у GCC появилась опция (которая также может использоваться с «обычными» программами на C):
-FCX-FORTRAN-RULES СООБЩЕНИЕ ИСПЕРТИТЕЛЬНЫЕ И РАЗДЕЛ ИСПОЛЬЗОВАТЬ ПРАВИЛА ФОРТРАНА.Уменьшение диапазона выполняется как часть комплексного деления, но при этом не проверяется, является ли результатом комплексного умножения или деления «NaN + I*NaN», с попыткой спасти ситуацию в этом случае.
Упомянутые выше правила псевдонимов являются еще одним бонусом, а также - по крайней мере, в принципе - операциями со всем массивом, которые, если их правильно принять во внимание оптимизатором компилятора, могут привести к более быстрому написанию кода.С другой стороны, некоторые операции занимают больше времени, например.если кто-то выполняет присваивание выделяемому массиву, необходимо выполнить множество проверок (перераспределить?[Функция Fortran 2003], имеет шаги массива и т. д.), которые делают простую операцию более сложной за кулисами - и, следовательно, медленнее, но делают язык более мощным.С другой стороны, операции с массивами с гибкими границами и шагами упрощают написание кода, а компилятор обычно лучше оптимизирует код, чем пользователь.
В целом, я думаю, что и C, и Fortran примерно одинаково быстры;выбор должен заключаться в том, какой язык вам больше нравится, или использование операций над целыми массивами Фортрана и его лучшая переносимость более полезны - или лучший интерфейс к системе и библиотекам графического пользовательского интерфейса в C.
Нет ничего о языки Fortran и C, которые делают один быстрее другого для конкретных целей.Есть вещи о конкретных составители для каждого из этих языков, что делает некоторые из них более подходящими для определенных задач, чем другие.
В течение многих лет существовали компиляторы Фортрана, которые могли творить черную магию с вашими числовыми программами, делая многие важные вычисления безумно быстрыми.Современные компиляторы C также не могли этого сделать.В результате на Фортране появилось множество замечательных библиотек кода.Если вы хотите использовать эти хорошо протестированные, зрелые и замечательные библиотеки, вам понадобится компилятор Фортрана.
Мои неофициальные наблюдения показывают, что в наши дни люди пишут свои тяжелые вычислительные задачи на любом старом языке, и если это требует времени, они находят время в каком-нибудь дешевом вычислительном кластере.Закон Мура делает нас всех дураками.
Я сравниваю скорость Fortran, C и C++ с классическим тестом Levine-Callahan-Dongarra из netlib.Многоязычная версия с OpenMPhttp://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectorsC уродливее, поскольку он начался с автоматического перевода, плюс вставка ограничений и прагм для некоторых компиляторов.C++ — это просто C с шаблонами STL, где это применимо.На мой взгляд, STL представляет собой неоднозначную картину с точки зрения улучшения удобства обслуживания.
Автоматическое встраивание функций выполняется лишь в минимальной степени, чтобы увидеть, в какой степени это улучшает оптимизацию, поскольку примеры основаны на традиционной практике Фортрана, где встраивание мало полагается.
В компиляторе C/C++, который на сегодняшний день используется наиболее широко, отсутствует автоматическая векторизация, от которой во многом зависят эти тесты.
Перечитайте пост, который был незадолго до этого:есть несколько примеров, когда в Фортране круглые скобки используются для указания более быстрого или точного порядка вычислений.Известные компиляторы C не имеют возможности наблюдать за скобками без отключения более важных оптимизаций.
Несколько лет я занимался обширной математикой на FORTRAN и C.По своему опыту я могу сказать, что FORTRAN иногда действительно лучше C, но не из-за его скорости (можно заставить C работать так же быстро, как FORTRAN, используя соответствующий стиль кодирования), а скорее из-за очень хорошо оптимизированных библиотек, таких как LAPACK, и из-за отличное распараллеливание.На мой взгляд, с FORTRAN действительно неудобно работать, а его преимуществ недостаточно, чтобы компенсировать этот недостаток, поэтому сейчас я использую C+GSL для вычислений.
Я программист-любитель и владею обоими языками «средне».Мне проще писать быстрый код на Фортране, чем код на C (или C++).И Фортран, и C являются «историческими» языками (по сегодняшним стандартам), широко используются и имеют хорошую поддержку бесплатных и коммерческих компиляторов.
Я не знаю, является ли это историческим фактом, но Фортран кажется, что он создан для распараллеливания/распределения/векторизации/многоядерности.И сегодня это практически «стандартный показатель», когда мы говорим о скорости:"он масштабируется?"
Для чистой работы процессора я люблю Фортран.Во всем, что связано с вводом-выводом, мне проще работать с C.(в любом случае это сложно в обоих случаях).
Конечно, для параллельного кода с интенсивными математическими вычислениями вы, вероятно, захотите использовать свой графический процессор.И C, и Fortran имеют множество более или менее хорошо интегрированных интерфейсов CUDA/OpenCL (а теперь и OpenACC).
Мой умеренно объективный ответ:Если вы одинаково хорошо/плохо знаете оба языка, то я думаю, что Фортран быстрее, потому что мне легче писать параллельный/распределенный код на Фортране, чем на C.(как только вы поймете, что можете писать на Фортране «свободной формы», а не просто строгий код F77)
Вот второй ответ для тех, кто хочет меня понизить, потому что им не нравится первый ответ:Оба языка обладают функциями, необходимыми для написания высокопроизводительного кода.Таким образом, это зависит от алгоритма, который вы реализуете (интенсивный процессор?ио интенсив?интенсивно использует память?), аппаратное обеспечение (один процессор?многоядерный?распространять суперкомпьютер?ГПГПУ?FPGA?), ваши навыки и, в конечном итоге, сам компилятор.И C, и Fortran имеют потрясающий компилятор.(я серьезно поражен тем, насколько продвинуты компиляторы Fortran, но не менее продвинуты и компиляторы C).
PS:Я рад, что вы специально исключили библиотеки, потому что я могу сказать много плохого о библиотеках графического интерфейса Фортрана.:)
Я не слышал, чтобы Fortan значительно быстрее C, но вполне возможно, что в некоторых случаях он будет быстрее.И дело не в тех особенностях языка, которые присутствуют, а в тех, которые (обычно) отсутствуют.
Примером являются указатели C.Указатели C используются практически везде, но проблема с указателями заключается в том, что компилятор обычно не может определить, указывают ли они на разные части одного и того же массива.
Например, если вы написали процедуру strcpy, которая выглядела так:
strcpy(char *d, const char* s)
{
while(*d++ = *s++);
}
Компилятор должен работать в предположении, что d и s могут быть перекрывающимися массивами.Поэтому он не может выполнить оптимизацию, которая давала бы разные результаты при перекрытии массивов.Как и следовало ожидать, это значительно ограничивает возможности оптимизации.
[Я должен отметить, что в C99 есть ключевое слово «restrict», которое явно сообщает компиляторам, что указатели не перекрываются.Также обратите внимание, что в Фортране тоже есть указатели, семантика которых отличается от семантики C, но указатели не являются повсеместными, как в C.]
Но возвращаясь к C vs.Проблема Fortran, вполне возможно, что компилятор Fortran способен выполнять некоторые оптимизации, которые могут быть невозможны для (просто написанной) программы C.Так что я бы не сильно удивился такому утверждению.Однако я ожидаю, что разница в производительности будет не такой уж большой.[~5-10%]
Любая разница в скорости между Fortran и C будет скорее зависеть от оптимизации компилятора и базовой математической библиотеки, используемой конкретным компилятором.В Фортране нет ничего такого, что могло бы сделать его быстрее, чем C.
В любом случае, хороший программист может писать на Фортране на любом языке.
Быстро и просто:Оба одинаково быстры, но Фортран проще.Что на самом деле быстрее, зависит от алгоритма, но в любом случае значительной разницы в скорости нет.Это то, что я узнал на семинаре по Фортрану в центре высокопроизводительных вычислений в Штутгарде, Германия, в 2015 году.Я работаю и с Фортраном, и с Си и разделяю это мнение.
Объяснение:
Язык C был разработан для написания операционных систем.Следовательно, у него больше свободы, чем необходимо для написания высокопроизводительного кода.В целом это не проблема, но если программировать неаккуратно, можно легко замедлить работу кода.
Фортран был разработан для научного программирования.По этой причине он поддерживает написание быстрого кода с точки зрения синтаксиса, поскольку это основная цель Фортрана.В отличие от общественного мнения, Фортран не является устаревшим языком программирования.Его последний стандарт — 2010 г., и новые компиляторы публикуются регулярно, поскольку большая часть высокопроизводительного кода пишется на Фортране. Фортран также поддерживает современные функции в виде директив компилятора (в прагмах C).
Пример: Мы хотим передать большую структуру в качестве входного аргумента функции (fortran:подпрограмма).Внутри функции аргумент не изменяется.
C поддерживает как вызов по ссылке, так и вызов по значению, что является удобной функцией.В нашем случае программист может случайно использовать вызов по значению.Это значительно замедляет работу, поскольку сначала структуру необходимо скопировать в память.
Фортран работает только с вызовом по ссылке, что заставляет программиста копировать структуру вручную, если ему действительно нужна операция вызова по значению.В нашем случае fortran будет автоматически работать так же быстро, как версия C с вызовом по ссылке.
Обычно FORTRAN медленнее, чем C.C может использовать указатели аппаратного уровня, позволяющие программисту выполнять оптимизацию вручную.FORTRAN (в большинстве случаев) не имеет доступа к аппаратным средствам адресации памяти.(VAX FORTRAN — это отдельная история.) Я время от времени использовал FORTRAN с 70-х годов.(Действительно.)
Однако, начиная с 90-х годов, FORTRAN стал включать в себя определенные языковые конструкции, которые можно оптимизировать в параллельные алгоритмы, которые может реально кричать на многоядерный процессор.Например, автоматическая векторизация позволяет нескольким процессорам одновременно обрабатывать каждый элемент вектора данных.16 процессоров — 16 векторных элементов — обработка занимает 1/16 времени.
В C вам приходится управлять своими собственными потоками и тщательно разрабатывать алгоритм для многопроцессорной обработки, а затем использовать кучу вызовов API, чтобы убедиться, что параллелизм происходит правильно.
В FORTRAN вам нужно только тщательно спроектировать свой алгоритм для многопроцессорной обработки.Все остальное за вас сделают компилятор и среда выполнения.
Вы можете прочитать немного о Высокопроизводительный Фортран, но вы найдете много мертвых ссылок.Вам лучше прочитать о параллельном программировании (например, OpenMP.org) и как FORTRAN это поддерживает.
Более быстрый код на самом деле не соответствует языку, это компилятор, поэтому вы можете видеть «компилятор» ms-vb, который генерирует раздутый, медленный и избыточный объектный код, который связан внутри «.exe», но powerBasic генерирует слишком сильно. лучший код.Объектный код, созданный компиляторами C и C++, генерируется в несколько этапов (минимум 2), но по конструкции большинство компиляторов Fortran имеют как минимум 5 этапов, включая оптимизацию высокого уровня, поэтому по замыслу Fortran всегда будет иметь возможность генерировать высокооптимизированный код.Итак, в конце концов, это компилятор, а не тот язык, который вам следует запрашивать. Самый лучший компилятор, который я знаю, это компилятор Intel Fortran, потому что вы можете получить его в LINUX и Windows, и вы можете использовать VS в качестве IDE, если вы ищете дешевый жесткий компилятор, который вы всегда можете передать на OpenWatcom.
Дополнительная информация об этом:http://ed-thelen.org/1401Project/1401-IBM-Systems-Journal-FORTRAN.html
В Фортране есть лучшие процедуры ввода-вывода, например.Подразумеваемая возможность do дает гибкость, с которой не может сравниться стандартная библиотека C.
Компилятор Fortran непосредственно обрабатывает более сложный синтаксис, и, поскольку такой синтаксис не может быть легко сведен к форме прохождения аргумента, C не может эффективно реализовать его.
Используя современные стандарты и компилятор, нет!
Некоторые из присутствующих здесь предположили, что FORTRAN быстрее, потому что компилятору не нужно беспокоиться о псевдонимах (и, следовательно, он может делать больше предположений во время оптимизации).Тем не менее, это было решено в C со времен стандарта C99 (я думаю) с включением ключевого слова ограничения.По сути, это сообщает компилятору, что в заданной области указатель не имеет псевдонимов.Более того, C обеспечивает правильную арифметику указателей, где такие вещи, как псевдонимы, могут быть очень полезны с точки зрения производительности и распределения ресурсов.Хотя я думаю, что более поздние версии FORTRAN позволяют использовать «правильные» указатели.
В современных реализациях C в целом превосходит FORTRAN (хотя он тоже очень быстр).
http://benchmarksgame.alioth.debian.org/u64q/fortran.html
РЕДАКТИРОВАТЬ:
Справедливой критикой этого подхода является то, что эталонный анализ может быть предвзятым.Вот еще один источник (относительно C), который помещает результат в больший контекст:
http://julialang.org/benchmarks/
Вы можете видеть, что C обычно превосходит Fortran в большинстве случаев (опять же см. критические замечания ниже, которые применимы и здесь);как заявляли другие, бенчмаркинг — это неточная наука, которую можно легко загрузить, чтобы отдать предпочтение одному языку перед другими.Но это дает представление о том, почему Fortran и C имеют схожую производительность.
Фортран может очень удобно обрабатывать массивы, особенно многомерные.Нарезка элементов многомерного массива в Фортране может быть намного проще, чем в C/C++.В C++ теперь есть библиотеки, которые могут выполнять эту работу, например Boost или Eigen, но все-таки это внешние библиотеки.В Фортране эти функции являются встроенными.
Будет ли Фортран быстрее или удобнее для разработки, во многом зависит от работы, которую вам нужно выполнить.Как специалист по научным вычислениям в области геофизики, я выполнял большую часть вычислений на Фортране (я имею в виду современный Фортран, >=F90).
Это более чем субъективно, потому что это больше всего влияет на качество компиляторов и тому подобное.Однако, чтобы более прямо ответить на ваш вопрос, говоря с точки зрения языка/компилятора, в Fortran нет ничего по сравнению с C, что могло бы сделать его по своей сути быстрее или лучше, чем C.Если вы выполняете тяжелые математические операции, все будет зависеть от качества компилятора, навыков программиста на каждом языке и встроенных библиотек поддержки математических операций, которые поддерживают эти операции, чтобы в конечном итоге определить, какая из них будет быстрее для данной реализации. .
РЕДАКТИРОВАТЬ:Другие люди, такие как @Nils, подняли хороший вопрос о разнице в использовании указателей в C и возможности псевдонимов, которые, возможно, замедляют самые наивные реализации в C.Однако в C99 есть способы справиться с этим с помощью флагов оптимизации компилятора и/или того, как на самом деле написан C.Это хорошо описано в ответе @Nils и последующих комментариях к его ответу.
В большинстве постов уже представлены убедительные аргументы, поэтому я просто добавлю пресловутые 2 цента к другому аспекту.
Быть быстрее или медленнее Фортрана с точки зрения вычислительной мощности, в конце концов, может иметь значение, но если для разработки чего-то на Фортране требуется в 5 раз больше времени, потому что:
- ему не хватает хорошей библиотеки для задач, отличных от чистого вычисления чисел
- ему не хватает достойного инструмента для документирования и модульного тестирования.
- это язык с очень низкой выразительностью, в котором резко возрастает количество строк кода.
- он очень плохо обрабатывает строки
- у него безумное количество проблем с разными компиляторами и архитектурами, которые сводят вас с ума.
- у него очень плохая стратегия ввода-вывода (ЧТЕНИЕ/ЗАПИСЬ последовательных файлов.Да, файлы произвольного доступа существуют, но видели ли вы когда-нибудь, чтобы они использовались?)
- он не поощряет хорошие практики разработки и модульность.
- фактическое отсутствие полностью стандартного, полностью совместимого компилятора с открытым исходным кодом (и 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.Помимо этих проблем, вопрос об относительной производительности становится более придирчивым и зависит от местных правил выбора компиляторов и опций.
