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

выступления Фортрана на Компьютерный Язык Бенчмарк Игра на удивление плохо. Сегодняшний результат ставит Fortran 14th и 11th на два четырехъядерных теста, 7th и 10th на одиночных ядрах.

теперь я знаю, что тесты никогда не бывают идеальными, но все же, Fortran был (есть?) часто рассматривается язык для высокопроизводительных вычислений, и похоже, что тип проблем, используемых в этом тесте, должен быть в интересах Fortran. В недавней статье о вычислительной физика Ландау (2008) писал:

однако [Java] не так эффективен или также поддержанный для HPC и параллели обработка как FORTRAN и C, последних двух высоко развитых компиляторы и многие другие научные подпрограммы библиотеки. Фортран, в свою очередь, по-прежнему доминирующий язык для HPC, с FORTRAN 90/95 быть удивительно хороший, современный и эффективный язык; но увы, вряд ли учил любым ЦЕЗИЙ отделы и компиляторы могут быть дорогой.

Это только из-за компилятора, используемого языковой перестрелкой (бесплатный компилятор Intel для Linux) ?

6
benchmarking comparison fortran performance

6 ответов

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

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

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

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

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

4

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

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

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

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

позвольте мне привести вам пример-программа "обратного дополнения", которая должна читать большой (порядка 10^8 B) файл из stdin строка за строкой, делает что-то с ним и печатает полученный большой файл в stdout. Довольно прямая программа Fortran примерно в 10 раз медленнее на одном ядре (~10s), чем сильно оптимизированный C++ (~1s). Когда вы пытаетесь играть с программой, вы увидите, что только простой формат чтения и записи занимает более 8 секунд. В Fortran way, если вы заботитесь об эффективности, вы просто напишете неформатированную структуру в файл и прочитаете ее в кратчайшие сроки (что полностью непереносимо и все такое, но кого это волнует-эффективный код должен быть быстрым и оптимизированным для конкретной машины, не способным работать везде).

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

2

этот тест вообще глупый.

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

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

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

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

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

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

2

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

2

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

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

Edit:

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

1