Google дал оценку Java и C++

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

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

Обычно это делается с помощью PARAMETER.

Если уж Вы действительно хотите предложить предметную область, где Фортрану 77 будет нелегко, я думаю нужно двигаться в сторону AMR, или разреженной линейной алгебры, где всё чаще встречаются графовые алгоритмы на поиск кратчайшего пути или сведение к остовному дереву. Но вот беда, это примеры невычислительных задач - они целочисленные...

Чем библиотека quad отличается от любой другой, где аргументы функции передаются как dummy variables?

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

Уважаемый ogronom. При всём моём к Вам уважении, мне кажется Вы не очень хорошо знакомы с Фортраном, раз задаёте такой вопрос. Конечно, я могу отослать Вас к коду, скажем, NWchem, или GAMESS, где 7-мерные массивы прекрасно уживаются с очень внимательным использованием памяти (хорошо, согласен, части NWChem уже используют ALLOCATE).

allocate нету в стандарте ф77. чтд?

Да, фортран (и именно Ф77) знаю не особо и сильно его не люблю, хотя фактически с него начинал учиться программировать и писал на нем относительно долго. Не сложилось у меня с ним, из-за многих фактов: отсутствие рекурсии + код библиотек которые я использовал (в одной из них вообще был костыль-самописный препроцессор). После того как полез в код gsl, писать на фортране как-то расхотел. Обвязка на библиотеки делается элементарно. При типичном времени исполнения программы в 2-ое суток, разница между си и фортраном врядли была бы принципиальной, а удобство написания ощутимое.

Сейчас написал маленький синтетический тест: генерация матрицы и вектора с помощью функций из стандартной библиотки, и их перемножение. Прогнал 10 раз на gcc 4.5: в 9 случаев из 10 победил фортран с максимальным отрывом в 23с (из ~ 550), один раз победил си с отрывом 6 сек.

PARAMETER надо повторять в каждой рутине.

К тому же точно так же надо перекомпилировать программу, по сравнению скажем с получением параметра из файла или коммандной строки.

Ладно, Ты меня убедил, у Фортрана производительность выше си. Просто, по-моему, у Фортрана много недочетов, не критичных, но достаточно чтобы не захотеть на нем писать, когда есть си под рукой.

> Да, фортран (и именно Ф77) знаю не особо и сильно его не люблю, хотя фактически с него начинал учиться программировать и писал на нем относительно долго. Не сложилось у меня с ним, из-за многих фактов: отсутствие рекурсии + код библиотек которые я использовал (в одной из них вообще был костыль-самописный препроцессор).

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

С ходу мне на ум приходит два примера, когда рекурсия кажется подходящей: вычисление спецфункций (Гамма, Бесселя, факториал, числа Фибоначчи, и тому подобное) и обход структур данных (типа графов или даже LU декомпозиция). Может есть и другие случаи, но не забывайте - мы говорим про вычислительные алгоритмы, а мои познания еще и ограничены применением в HPC. Так вот в первом случае никто не использует рекурсию - функции просто табулируют. Во-втором все посложнее. Проблема рекурсии - в упорядочении вычислений, в создании зависимости вызовов. Для многопоточных и/или многозадачных систем такое упорядочение убивает потенциальное распараллеливание. Поэтому да, можно написать рекурсивно обратный ход в LU разложении, но так никто не делает - посмотрите пример ScaLAPACK или HPL. Потому, вывод в духе ЛОРа - «рекурсия не нужна». Она просто не востребована на практике.

> PARAMETER надо повторять в каждой рутине.

Точнее INCLUDE, что гарантирует одинаковость параметра во всей программе.

К тому же точно так же надо перекомпилировать программу, по сравнению скажем с получением параметра из файла или коммандной строки.

Удобство аргументом не является - уже обсуждали.

Ладно, Ты меня убедил, у Фортрана производительность выше си.

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

Подведем итог дискуссии: Фортран не без недостатков, нo лучшего пока не придумали. Ну что делать - нет в мире совершенства. Спасибо за беседу!

> Подведем итог дискуссии: Фортран не без недостатков, нo лучшего пока не придумали.

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

> Сейчас написал маленький синтетический тест: генерация матрицы и вектора с помощью функций из стандартной библиотки, и их перемножение. Прогнал 10 раз на gcc 4.5: в 9 случаев из 10 победил фортран с максимальным отрывом в 23с (из ~ 550), один раз победил си с отрывом 6 сек.

А можно глянуть на сишный код? ;)

> Подведем итог дискуссии...

Кстати, этот итог был уже давно озвучен: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Тем не менее, интересная штука нашлась: http://www.oonumerics.org/blitz/

Но сам про неё ничего не знаю, гугл рулез, числодробилки — не моя область.

>> Подведем итог дискуссии...

Кстати, этот итог был уже давно озвучен: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

Превосходное описание!

Apparently, written exact same but in English gives much more confidence!

Насколько я понимаю, быстрее фортран может быть только более оптимизированными библиотеками.

А по-моему, Вы только что сами опровергли этот тезис своей же ссылкой.

Тем не менее, интересная штука нашлась: http://www.oonumerics.org/blitz/

А вот это действительно прикол! Один из моих коллег сейчас бъется над этой библиотекой и не может ее запустить. Вот так совпадение...

> А по-моему, Вы только что сами опровергли этот тезис своей же ссылкой.

Публикация от 1998 года, а не дворе уже 2010. В Си многое с тех пор изменилось в плане оптимизаций, а вот в Фортране вряд ли. Но не берусь авторитетно ничего утверждать тут, поскольку не авторитет в области ;)

Как известно, все новое это хорошо забытое старое...

>Публикация от 1998 года, а не дворе уже 2010. В Си многое с тех пор изменилось в плане оптимизаций, а вот в Фортране вряд ли.

Фортран пилят с не меньшим упорством. И если компиляторы подтянутся к последнему стандарту, то не вижу уже почти никаких «неудобств» по сравнению с С. ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf

> Как уже писалось выше, Фортран программа чаще всего быстрее чем её С эквивалент.

Все время слышу эту городскую легенду и ни разу не видел примера такой программы.

>> А какая разница. на чем писать репликацию, хеш-таблицу и аллокатор с виртуальной памятью?

никакой
с той лишь разницей, что трудозатраты могут различаться

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

А если хотите официальные коды, то вот пример. http://www.aip.org/cip/langer.htm Результаты будут такие: фортран где-то как минимум 10-20% впереди версии на C.

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

Вот и сделай это «легко». Жду обозримый код на фортране и си.

http://www.aip.org/cip/langer.htm

нагуглил что-то, что сам не понял, и запостил? молодец!

для тех кто в танке:

A Comparison of the Floating-Point Performance of Current __Computers__

Да, еще эти результаты из прошлого тысячелетия, 1998 года

Результаты будут такие: фортран где-то как минимум 10-20% впереди версии на C.

давай сюда эти результаты на твоей машине, вместе с флагами компиляции и uname -a

>нагуглил что-то, что сам не понял, и запостил? молодец!

моя твоя по-английски не понимай? Я то точно знаю, что запостил, так как иногда в AIP журналaх и мое имя мелькает.

Да, еще эти результаты из прошлого тысячелетия, 1998 года

Хаха. Даже скомпилировать не под силу? Две строчки подправить всего.

Вот и сделай это «легко». Жду обозримый код на фортране и си.

А зачем? На фортране дать могу легко, а с С сами ворочайте.

Когда-то видел я код на фортране pо сравнению с cpp. Если перепишете на С, то будет любопытно http://pastebin.com/ZBE1tqmd http://pastebin.com/23DZECZe

забавно:

24.07.2010 Google дал оценку Java и C++

13.08.2010 Oracle подал в суд на Google за использование Java на Android

Ждём реакции Страуструпа.

>моя твоя по-английски не понимай?

достаточно понимаю, чтобы понять то, что ты не понял — сравнивались не языки, а железки

Вот и сделай это «легко». Жду обозримый код на фортране и си.

А зачем? На фортране дать могу легко, а с С сами ворочайте.

а вот 3.14здеть про 10-20% отставания си ты можешь и без этого

забывчивый ты наш

вопрос напомнить? он был не про проценты отставания, а про *конкретный код*, эти проценты реализующий

Я то точно знаю, что запостил, так как иногда в AIP журналaх и мое имя мелькает.

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