Сравнение производительности штатных компиляторов Delphi, pascalABC.net и C++

#cpp #delphi #строки #производительность #pascalabcnet

В очередной раз очередной студент с горящими глазами объявил, что "всё, что у нас
написано на Delphi - медленно и безобразно и, если мы уж не хотим перейти на C++, то
почему бы не перейти на pascalABC.net, он быстрее значительно".

Студенту поручили проверить всё это. Конкретная задача (постараюсь определить в терминах
скорости компиляторов, как мне указали в комментариях): сравнить производительность
штатных компиляторов Delphi, PascalABC.net и MS VS (версий, которые у нас имеются.
Не такие древние, хотя по академической лицензии иметь всегда последнее порой сложно).
Выкладки, которые он привёл из сети, в целом не особо убедительны. Да, быстрее, но
в конкретных примерах. Как они относятся к нашим задачам - не совсем ясно. Студенту
поручили, в итоге, всё проверить на практике.

Вопрос, может, кто-то уже сталкивался с необходимостью сравнения скорости на больших
биоинформатических проектах (или похожих: основной массив работы - строки, большое
их количество, сравнение, точный и нечеткий поиск, построение деревьев, циклы, статистика)
Delphi vs PascalABC.net и, возможно, C++?

Принцип подхода к снаряду понятен, объём работы - тоже. Но, мне, как куратору студента,
хотелось бы понимать, насколько правильно он выполнил свою работу. Для этого неплохо
было бы и сравнить его результаты с уже имеющимися, если таковые есть.
    

Ответы

Ответ 1

Похоже, такие желания появляются у каждого третьего студента :) По крайней мере,
у нас часто возникают схожие студенческие задачи, особенно, если приходят студенты
с мехмата или ВИТ и желают заниматься только программированием. Ну, ладно, это лирика.  

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

Сразу приведу класс задач в наших пакетах. Это работа с огромными и маленькими строками,
матрицами (в меньшей степени), проблемы поиска, динамическое программирование, множества,
ряды Фурье и вейвлеты, ввод-вывод. Время расчёта результата анализа одного пациента
при работе в один поток может достигать 10-12 часов, так что погрешностями в долях
секунды при замере времени работы можно пренебречь. В расчет принималось среднее от
отношения времен работы. Для разных ситуаций количество замеров разное, но всегда больше 7.

Версии компиляторов: Delphi for Win64 31.0 (Delphi 10.1), PascalABC.net 3.2.0.1415,
VS 2015 (14.00.24720)


Пакет на Delphi, написанный с использованием только стандартных методов и функций
Delphi, в один поток, уступал по производительности и PascalABC.net и, тем более, C++.
Разница в нашем основном пакете могла достигать, в зависимости от данных, 1.3 раза
с паскалем и до 1.5х раз с C++ (есть разные результаты для разных процессоров, это
самая большая разница). Так что, если не желаете заниматься профилировкой, а скорость
работы критична, я бы не рекомендовал писать на Delphi. 
То же самое, но в многопоточном виде. Большинство наших задач успешно распараллеливаются,
так что мы охотно применяем многопоточность. Разница Delphi супротив C++ в худшем случае
осталась около 1.5х раз, с PascalABC.net - 1.1 раза. Скорее всего, в PascalABC.net
многопоточность ещё плохо "вылизана".
Многопоточная профилированная задача. В данном случае были выявлены "бутылочные горла"
и проблемные места переписаны на ассемблере. Это было сделано для Delphi и C++. PascalABC.net
не поддерживает встроенный ассемблер, были сделаны попытки подключения библиотек, но
ожидаемого успеха пока не добились. Как итог, сравнение Delphi с C++ - отставание в
1.15 раза (на Intel), неоптимизированный пакет PascalABC.net проиграл Delphi в 1.6 раза
То же самое, но с поддержкой SIMD. Вот тут уже почти паритет. Отставание Delphi от
C++ на процессорах Intel - 1.06 раза (было бы интересно скомпилировать компилятором
от Intel с интринсиками, но не знаю, будет ли реализовано или нет), на процессорах
AMD - 1.01 раза. PascalABC не сравнивался - причина в п. 3


Была еще проведена оптимизация под конкретные ядра. Тут вообще интересные результаты
(в частности, при оптимизации под ядра Zen на Ryzen 1700 в 16-типоточном приложении
пакет на Delphi был повторяемо быстрее всех, что мы пока не можем внятно объяснить),
но в промежуточном выводе они не представлены, без разрешения авторов я их дать не могу.


Ответ 2

Выберите характерные тестовые задачи и опишите их алгоритмы, выделите типовые показатели
производительности (ТПП) алгоритмов. 
Закодируйте алгоритмы на всех интересующих языках, в том числе обеспечьте вычисление
ТПП. 
При необходимости для программы на одном языке используйте различные компиляторы,
аппаратные платформы. 
Прогоните то что получилось и сравните результаты. 
В каком ВУЗе вы учитесь? Почему интуитивно то что я написал не удается понять?


Ответ 3

Насчёт производительности в расчётах. Пишу на Delphi научные
программы (выч.гидродинамика) уже лет 15. До этого были Fortran,
PL\1. Знаю, что сейчас считается хорошим тоном плюнуть в сторону
Delphi, и похвалить Java или C#. Пробовал и их, разумеется. Однако ж,
остался на Delphi: мне он удобнее в первую очередь при разработке
GUI, и во-вторых - при общении с различными БД, в которых хранятся
исходные данные для научных расчётов. 


Далее. Для научного софта ключевым моментом является быстродействие и многопоточные
вычисления. По быстродействию - пусть
тот "студент с горящими глазами" не слушает никого: пробует сам,
например, простое обращение матрицы напишет на VS C++, Delphi 64bit,
Java, C#, Python. Сравнит время выполнения (в цикле - несколько
обращений матриц, затем в многопоточном режиме вычислений). А только
потом делает выводы: они его удивят. 
Последнее время построил доступ из Delphi-кода (интерфейсная часть) к графическому
(потоковому) ускорителю (GPU): язык OpenCL
1.2. Для этого языка сам код KERNEL, работающий на видео-карте, пишется на C99 (посл.
версии OpenCL 2.0-2.2 - уже С++); компилятор не
требуется - компилирует сам драйвер видеокарты. Весь код Delphi/C99
отлично редактируется-анализируется в Embarcadero RAD Studio. Прирост
в скорости выполнения программ после переноса расчётов на GPU -
колоссальный, даже в сравнении с многопоточными вычислениями на CPU
(раз в 30). 
Мораль. Не агитирую именно за Delphi: на него необоснованно столько сейчас грязи
льют (и хоронят уже лет 20), что работу чисто
под него упомянутый в топике студент вряд ли найдёт. Но вот научиться
программировать расчёты (или, скажем, обработку изображений) на GPU с
применением OpenCL (AMD + NVidia + Intel) или CUDA (только NVidia) -
весьма перспективно. А перескакивать с одного языка на другой
новомодный - бесполезная трата времени.
Примеры связки Delphi 64bit OpenCL найдёте поиском в ИНЕТ по этим кл.словам.