Производительность программ на fpc

[serg_iv]

Человек сравнивает скорость работы компиляторов. Скорость работы java кода, почему то, опережает даже С - код:

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

Я провёл небольшое тестирование, где сравниваются C, D, Scheme, Pascal, Java
Компиляторы - gcc, dmd, gdc, stalin, sun jde, fpc

В качестве теста на всех языках считается функция Фибоначчи от числа 45.
Функция намеренно реализована неэффективно. Особенность реализации в том, что функция будет вызываться очень часто.
Её текст на C:
Код
unsigned fibonacci(unsigned n) {
return n == 0 ? 0 : n == 1 ? 1 : fibonacci(n - 1) + fibonacci(n - 2);
}

На остальных языках код аналогичен, с точностью до синтаксиса.

Каждый тест запускался 3 раза. Время замерялось командой time.
Некоторые характеристики тестовой машины: CPU: Pentium D 3 GHz (dual core); RAM: 2 GiB

Результаты теста:
CODE
c-O0 (1)

real 0m25.608s
user 0m25.530s
sys 0m0.000s


c-O0 (2)

real 0m26.141s
user 0m25.700s
sys 0m0.100s


c-O0 (3)

real 0m25.603s
user 0m25.430s
sys 0m0.020s


c-O3 (1)

real 0m8.909s
user 0m8.880s
sys 0m0.010s


c-O3 (2)

real 0m8.921s
user 0m8.890s
sys 0m0.020s


c-O3 (3)

real 0m9.271s
user 0m9.070s
sys 0m0.060s


d-dmd (1)

real 0m23.863s
user 0m23.490s
sys 0m0.070s


d-dmd (2)

real 0m24.415s
user 0m24.030s
sys 0m0.070s


d-dmd (3)

real 0m23.819s
user 0m23.320s
sys 0m0.170s


d-gdc (1)

real 0m9.098s
user 0m8.940s
sys 0m0.050s


d-gdc (2)

real 0m9.077s
user 0m8.910s
sys 0m0.030s


d-gdc (3)

real 0m9.233s
user 0m9.050s
sys 0m0.020s


scheme (1)

real 0m38.923s
user 0m38.770s
sys 0m0.070s


scheme (2)

real 0m39.553s
user 0m38.630s
sys 0m0.390s


scheme (3)

real 0m39.363s
user 0m39.000s
sys 0m0.040s


java (1)

real 0m12.731s
user 0m12.680s
sys 0m0.010s


java (2)

real 0m12.828s
user 0m12.770s
sys 0m0.000s


java (3)

real 0m12.762s
user 0m12.610s
sys 0m0.010s


pascal (1)

real 0m23.176s
user 0m22.800s
sys 0m0.090s


pascal (2)

real 0m21.799s
user 0m21.790s
sys 0m0.010s


pascal (3)

real 0m21.670s
user 0m21.640s
sys


Как видно, Java опережает многие компилируемые языки, и вплотную приближается к C. К сожалению протестировать C# нет возможности.
Надеюсь, этот пример развеет миф о том, что байткод == тормоз.

Взято отсюда:
http://linuxforum.ru/index.php?s=8d9540 ... opic=44651

[bw]

Python в некоторых моментах обгоняет Си.
Только это проблема Си программиста, а не заслуга Python компилятора. Если по сути.

..bw

[Sergei I. Gorelkin]

Вот здесь: http://shootout.alioth.debian.org/ народ занимается всяческими сравнениями более основательно. FPC, правда, представлен версией 2.0.4, которая уже весьма морально устарела. Думаю, следующий релиз будет заметно отличаться в лучшую сторону. Ждать уже не так долго...

[alexs]

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

[bw]

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

p.s. Я не учитывал использование Psyco.

..bw

[alexs]

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

что такое шаблон в вашем понимании?

и ещё:

грамотно написанного компилируемого кода

т.е. максимум скорость будет равна на некоторых атомарных операциях

конечно если подходть строго формально - то компилятор для VM интерпретатора и тестируемой программы должен быть одинаков

[Иван Шихалев]

никогда не поверю что интерпретируемый код будет работаь быстрее грамотно написанного компилируемого кода

Вообще может: оптимизация в рантайме, опираясь на конкретные данные в каких-то случаях может дать прирост производительности.

[alexs]

не убедительно
можно рассмотреть случай на заре развития жабы
тогды был прикол что она обгоняла в конкретном примере С аналог
но в итоге выяснилось что SAN встроила в интрепретатор сюрприз - виртуальная машина определяла заданную последовательноть строк (а именно тестовый пример) и запускала уже заранее написанныйй и супероптимизированный аналог в машинных кодах
но стоило в тестовом примере поменять строки местами - и всё возращалось на свои места

тогда по этому поводу был ещё крупный скандал
(кажется это около 10 лет назад было)

а так что ты грамотно напишиш функцию (или вызовеш стандартную), что туже функцию вызовет интерпретатор VM - гду тут выйгрыш?
причём мы всё время говорим о элементарных функциях - строк 10-12

а если уже дойдёт до реальной жизны (и реальных размеров проектов с большой вычислительной мощносью) то интерпритаторы не нужны вовсе.

моё мнение - интрепритаторы полезны в случае когда надо написать одноразовую небольшую последовательность действий и тут же её выкинуть

[debi12345]

моё мнение - интерпретаторы полезны в случае когда надо написать одноразовую небольшую последовательность действий и тут же её выкинуть

Они незаменимы, когда :

1) размер дискового ( флэшевого ) пространства ( или скорость загрузки кода через каналы связи ) имеют решающее значение :
2) мобильные устройства;
3) ХТТП-апплеты;
4) системы с обновлениями через каналы связи;

и имеют смысл, когда :

5) производительность не слишком важна;
6) мульти-платформенность, реализуемая через платформенные версии библиотек.

Сужу по своему опыту - TCl/Tk ( интерпретаторы ) GUI программа редко превышает несколько килобайт. Но в работе, конечно - тормоз страшенный.

[Anton]

Скорость работы java кода, почему то, опережает даже С - код

java и С# посути -родственники. Только Java не компилит в нативный код. И скорость работы java-приложений не сильно то зависит от ОС и ваших аппаратных возможностей.

[Matich]

>никогда не поверю что интерпретируемый код будет работаь быстрее грамотно написанного компилируемого кода

При правильном подходе может...
http://en.wikipedia.org/wiki/Dynarec

[trifon]

Говорят OCAML Фибоначчи считает даже быстрее чем СИ, ну или как минимум на уровне, я даже тест видел но забыл ссылку, однако в гугле можно полно подобного найти, OCAML наверное самый быстрый язык с автоматическим сбором мусора, а тем более среди функциональных.

[trifon]

Вот например ссылочка на тему векторов с плавающей запятой OCAML и C++, с построчным сравнением кода C++ vs OCaml: Ray tracer comparison, как видите по скорости OCAML идёт вровень с C++.
Жаба практически везде сливает по крупному, тот же пример - Ray tracer Benchmark, и это при том что OCAML функциональный язык, а жаба нет, по идее должно быть наоборот.

[trifon]

Ссылка взятая оттуда же "Compare programming language performance", сравнивается огромное количество языков, разными тестами, на скорость, использование памяти, размер кода, соответственно для каждого теста код так же доступен.
Если тестировать Full CPU Time и Memory Use, Free Pascal занимает первое место, обгоняя даже gcc, если только Full CPU, gcc - первый, fpc второе ,жаба проигрывает даже mono.
Так что если кто нибудь будет говорить, что Free Pascal - тормоз, есть куда носом ткнуть, и не надо сказок про жабу, тем более про питон рассказывать.

[trifon]

Вот здесь: http://shootout.alioth.debian.org/ народ занимается всяческими сравнениями более основательно.

- собственно говоря я дал ту же ссылку, невнимательно просмотрел предыдущие сообщения.