Производительность Фортрана

Нет, это не только из-за компилятора.

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

Это довольно ясно из полученных результатов. В общем, при достаточных усилиях по программированию и приличном компиляторе ни C, C ++, ни Fortran не будут значительно медленнее, чем ассемблерный код - конечно, не более чем на 5-10% в худшем случае, за исключением патологических случаев. Тот факт, что фактические результаты, полученные здесь, более разнообразны, чем это, указывает мне на то, что не было затрачено «достаточных усилий по программированию».

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

Точно так же исключение составляют такие вещи, как обработка строк, где вы сильно зависите от библиотеки времени выполнения (которая может быть разного качества; Fortran редко бывает тем случаем, когда быстрая библиотека строк будет приносить деньги поставщику компилятора!), И от базовое определение «строки» и то, как она представлена ​​в памяти.

Некоторые случайные мысли:

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

1. Компиляторы стали намного сложнее. В частности, огромные усилия были приложены к компиляторам c и c ++. Не отставали ли компиляторы fortran? Я полагаю, что gfortran использует ту же внутреннюю часть gcc и g ++, но что насчет компилятора Intel? Раньше было хорошо, но так ли это?
2. В некоторых языках есть много специализированных ключевых слов и синтаксиса для помощи компилятору (restricted и const int const *p в c и inline в c ++). Не зная фортран 90 или 95, я не могу сказать, успевают ли они.

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

Позвольте мне привести пример - программа 'обратного дополнения', которая должна считывать большой (порядка 10 ^ 8 Б) файл из стандартного ввода построчно, что-то делает с ним и печатает получившийся большой файл в стандартный вывод. Довольно простая программа Fortran примерно в 10 раз медленнее на одном ядре (~ 10 с), чем СЕРЬЕЗНО оптимизированный C ++ (~ 1 с). Когда вы попытаетесь поиграть с программой, вы увидите, что только чтение и запись в простом формате занимает более 8 секунд. На языке Fortran, если вы заботитесь об эффективности, вы просто напишите неформатированную структуру в файл и мгновенно прочитаете ее (что совершенно непереносимо и все такое, но кого это волнует - эффективный код должен быть быстрый и оптимизированный для конкретной машины, не может работать везде).

Итак, краткий ответ - не волнуйтесь, просто делайте свою работу - и если вы хотите написать сверхэффективную операционную систему, извините - Fortran просто не подходит для такой производительности.

Этот тест вообще тупой.

Например, они измеряют время ЦП для выполнения всей программы. Как заявил mcmint (и это может быть действительно так), ввод-вывод Fortran - отстой *. Но кого это волнует? В реальных задачах один считывает ввод в течение нескольких секунд, затем вычисляет часы / дни / месяцы и, наконец, записывает вывод за секунды. Вот почему в большинстве тестов операции ввода-вывода исключаются из измерений времени (если вы, конечно, не тестируете ввод-вывод сами по себе).

Норбер Винер в своей книге God & Golem, Inc. писал:

Предоставьте человеку то, что принадлежит человеку, а компьютеру то, что принадлежит ему.

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

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

Особенно это важно в реальных (огромных) приложениях. Грязные уловки (так часто используемые во многих тестах), даже если они могут в некоторой степени повысить эффективность (5%, может быть, 10%), не подходят для реальных проектов.

/ * C / C ++ использует потоковый ввод-вывод, но Фортран традиционно использует ввод-вывод на основе записей. Дополнительная литература. В любом случае ввод-вывод в этих тестах настолько удивителен. Использование перенаправления stdin / stdout также может быть источником проблемы. Почему бы просто не использовать возможность чтения / записи файлов, предоставляемую языком или стандартной библиотекой? И снова это будет более реальная ситуация.

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

Учитывая, что они не опубликовали точные параметры компилятора, которые они использовали для компилятора Intel Fortran Compiler, я мало верю в их тест.

Я также хотел бы отметить, что и математическая библиотека Intel, MKL, и математическая библиотека AMD, ACML, используют компилятор Intel Fortran.

Редактировать:

Я нашел параметры компиляции, когда вы нажимаете на название теста. Результат удивителен, поскольку уровень оптимизации кажется разумным. Возможно, дело в эффективности алгоритма.