Легче ли оптимизировать Fortran, чем C, для тяжелых вычислений? - PullRequest
388 голосов
/ 28 сентября 2008

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

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

Ответы [ 23 ]

1 голос
/ 28 сентября 2008

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

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

0 голосов
/ 26 мая 2015

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

0 голосов
/ 20 июля 2009

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

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

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

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

...