Free Pascal быстрее Си

[Balans]

Интересные результаты тестирования простейшей программы, написанной на наиболее популярных языках программирования.

Исследование велось на предмет:
1) количества системных вызовов;
2) времени выполнения;
3) количества выполняемых инструкций.

Результат Pascal, Lua, Perl, TCL, etc.


Результат Ассемблер, Си, Ruby, Python, Java, Go, etc.


К слову, Lua тоже не плох. По меньшей мере для интерпретируемых языков.
Остальные ЯП не впечатляют. Java – полный провал.

Источник.

[Дож]

1. Результаты тестов для Си и паскаля взяты с разных машин. Можно ли сравнивать их друг с другом?

2. Где полный исходник программы на паскале? С какими аргументами она компилировалась перед замером показателей?

3. Почему из вывода perf stat автор берёт task-clock, а не time elapsed?

[SSerge]

Balans, стоит только в тестируемый код внести строки и сложные многочисленные операции с ними, при этом не "оптимизируясь под компилятор", а следуя простой логике получения результатов, как freepascal окажется на одном из самых последних мест по производительности. Но слегка обгонит C++ со строками библиотеки STL.

А еще, если в том же самом перле гонять цикл из мульёнов итераций, в ктором например одной переменной присваивается одно и то же значение, он исполнится мгновенно. Потому что вообще исполнится один раз. Это будет показателем того что перл чрезвычайно быстр?

[vada]

10 лет работал с JAVA. Таких тормозов не встречал. Там что, суммировали все начиная с запуска JAVA машины?
Хотелось бы на код теста посмотреть. А то "разогретый" на JAD байт-код JAVA работает, зачастую, побыстрее С.

[iskander]

Качество генерируемого кода в транковой версии FPC, кажется, значительно улучшилось.
Бенчмарканье дело конечно холиварное, но забавное, с удовольствием бы поучаствовал, если найдутся ещё желающие. Только вот helloworld это как-то уж слишком угрюмо, может лучше что-нибудь вроде посчитать частоты вхождений слов в файле?

[Tango]

Уже где то тут писал.
Сравнивал FPC с Delphi 10, FPC быстрее. На сколько не помню, но точно не на единицы процентов.
Тестовый код, архиватор LZW.

[olegy123]

Только вот helloworld это как-то уж слишком угрюмо

а кроме как "да здравствует мир" и сортировка каким-то методом вы действительно не узнаете истинную скорость. более сложные задачи уже потребуют вызовов ядра системы, библиотек. Что будет с программой, когда операционка решит сбросить буфера, или прокачать по DMA тонну данных?
еще сильно может влиять флажки компилятора.
Если тестеры тестят просто, без оптимизаций - тогда естественно жаба может прийти к финишу первой.
Так что кроме как изучения под лупой asm кода действительно сложно установить качество генерации кода.

Один видео-блогер решил "научно" проверить зависимость кэша процессора от частоты памяти. Тестировал он разумеется на Win10. Возмущался, что результаты не совсем поддаются логике.

[SSerge]

>> кроме как "да здравствует мир" и сортировка каким-то методом вы действительно не узнаете истинную скорость

Реальную скорость и реальное качество как раз зачастую определяет качество реализации исполняющей подсистемы (RTL в случае паскаля). И если там принципиальные проблемы со скоростью инициализации/деинициализации динамических объектов, то никакие тесты и оптимальность на целых числах или тем более математические библиотеки не помогут со скоростью вашей программе, плотно работающей со строками или динамическими массивами. Алсо, если еще не замечено - как-то принято массово использовать контейнерные невизуальные типы LCL типа наследников TStringList, не задумываясь над тем, что они по реализации крайне неэффективны, ибо начально предназначены для работы со списками не более сотни-двух элементов длиной и происходят из необходимости обработки экранных элементов.

Итожа сказанное: чтобы что-то тестировать на производительность, нужно досконально знать, для чего именно проводятся тесты.
Синтетика типа сферического коня в вакууме может давать хорошие результаты, но особого смысла в них может не быть.
В виде примера: нет никакого смысла говорить о скорости передачи данных в mySQL из программ паскаля - в любом случае ограничителем будет не производительность программ паскаля, а то, что данные транслируются в исполняющую систему в текстовом виде и с этим не сделаете ничего.

[iskander]

Уже где то тут писал.
Сравнивал FPC с Delphi 10, FPC быстрее. На сколько не помню, но точно не на единицы процентов.
Тестовый код, архиватор LZW.

Tango, беглый поиск по форуму показал 2013 год, тех пор много воды утекло.

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

"за державу обидно"(c).
Если серьёзно, мне почти нравится транковый fpc.
А почему я упомянул подсчёт частот слов - мне несколько раз попадались подобные бенчи, это очень простая программа, требуется только чтение/запись файла, хеш-таблица и сортировка. На паскале можно изобразить за десять минут.

[Cheb]

Я лет... шесть, наверно, назад составлял тесты сравнивая производительность Фри Паскаля и жаваскрипта (в файрфоксе). В некоторых моментах (работа с целыми, индексация простого массива) паскаль вытирал о жаваскрипт тапочки. В других случаях (работа со строками) уже жаваскрипт вытирал о паскаль тапочки. В чём-то они были равноценны. В среднем - ничья.

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

Подобной глубины тесты есть?

[iskander]

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

[Mirage]

Да вот же рейкаст бенмарк.
https://forum.lazarus.freepascal.org/in ... 700.0.html
Интересно, насколько сейчас ситуация поменялась. Джава тоже ведь не стоит на месте.
Забавно, что при обсуждении подобных тем любителеи заявить, что джава тормозная, т.к. компилирует в ненативный код, как будто б испаряются.

[iskander]

Вот это был бы номер, если бы жабка, после того как в неё вбухали столько сил и средств, всё равно бы работала из рук вон плохо.
Mirage, ну почему вы не появились хотя бы на пару дней раньше, я уже начал помаленьку реализовывать то что озвучил, бросить будет уже жалко.
Впрочем, в любом случае интересно, сейчас попробую. Но у меня джава живет только в виртуалке.

Добавлено спустя 49 минут 17 секунд:
Что получилось:
Виртуальная машина - однопроцессорная Ubuntu MATE 18.04, 3ГБ RAM

java:
openjdk 10.0.2 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed mode) - 19-21 fps

fpc: 3.3.1-r44264 x86_64 - 23-25 fps

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

Добавлено спустя 13 минут 7 секунд:
картинки

[Сквозняк]

Да вот же рейкаст бенмарк.
https://forum.lazarus.freepascal.org/in ... 700.0.html
Интересно, насколько сейчас ситуация поменялась. Джава тоже ведь не стоит на месте.
Забавно, что при обсуждении подобных тем любителеи заявить, что джава тормозная, т.к. компилирует в ненативный код, как будто б испаряются.

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

[GeorgiPrivet]

iskander
Может после каждого запуска теста необходимо почистить оперативную память? Вполне вероятно, что после нескольких подряд тестов тайминг ее работы будет хромать. Почитай тут как это правильно сделать https://tehnichka.pro/customize-ram-in-bios/ Если не поможет, то jdk версией пониже попробуй поставить.

-----

Топовые компы для разработки, подобрать можно у https://elsolo.ru/