переходя от теории к практике
пример программы на фортране
версия 8.08 написана на делфи, версия 8.1 написана на фортране (внешний вид несколько отличается, но это не из-за языков)
при оценке расчетной части выяснилось, что фортран в 2 раза бысрее делфи (на одинаковых алгоритмах)

кстати, для любителей ООП. делфи на процедурах с винапи32 в два раза быстрее чем делфи с ООП (объектами и методами) на одинаковых алгоритмах.

Ну тут-то как раз ничего удивительного. Компилятор Delphi имеет очень хорошую оптимизацию; процедурный подход программирования, т.е. в том числе написанные на WinAPI программы, всегда выполняются быстрее написанных средствами ООП - нет виртуальных методов, высокой абстракции языка. Поэтому, кстати, Фортран очень поздно получил полноценное ООП и оно маловостребовано. 
Но прирост производительности всего в 2 раза не удивляет. Т.к., как я понимаю, вы писали графический интерфейс на WinAPI, то ограничением скорости являются вызовы API-функций из dll-библиотек ОС (это всегда медленнее, чем вызовы статических библиотек, но экономит память), поэтому более высокой скорости мы не получим.

В чисто вычислительных задачах без использования GUI и подключения разделяемых библиотек и при разумной организации ввода-вывода я получал прирост производительности над С до 20%, над С++ - в 2-3 раза. Вопрос в другом: а везде ли нужна высокая скорость исполнения кода? Ведь часто она достигается в ущерб трудоёмкости разработки. 

Какой компилятор Fortran и какие флаги оптимизации вы использовали? 
Кстати, для организации GUI в Фортран-приложениях я всё чаще стал использовать Python или TCL/Tk.
Либо, если это чисто научная графика -  MATFOR.

WinAPI вызывают все, никто их в программу в виде статических библиотек не берет.
в фортране (интел. вер.10.01) в релизе практически ничего не менял. все задачи загружали только один процессор, т.е. распараллеливание не использовалось (его и по задаче не было). ввод-вывод взят из апи, динамическое распределение памяти через alloc и realloc, как и в программе на делфи. внутри все устроено на списковых структурах и динамически размещенных записях. для вывода опенжл.
скорость расчета нужна - и чем больше тем лучше. для этого и был сделан переход на фортран. и сравнение результатов показывает что смысл в этом был.

Да, вы, однако, прямо-таки свободный радикал какой-то Я и не говорю, что API-функции надо статически линковать Речь идёт о другом: производительность программы уже ограничена скоростью вызова и исполнения API. Не важно какого API - WinAPI или OpenGL. Намного быстрее она даже на ассемблере работать не будет, если из ассемблера  всё равно вызываются сторонние функции. 

Ещё одно узкое место - ввод-вывод. Вычислительный алгоритм в идеале вообще не должен обращаться к вводу-выводу. Это лучше делать до или после него, или в отдельном асинхронном потоке. Иначе скорость выполнения кода упирается в ввод-вывод.

Поэтому, если код написан хорошо, то достигнута практически предельная скорость.

Это сообщение отредактировал(а) Cr@$h - 19.1.2009, 15:47