Performance comparison of standard Delphi compilers, pascalABC.net and C++

Once again, another student with burning eyes announced that " everything we have written in Delphi is slow and ugly, and if we really don't want to switch to C++, then why not switch to pascalABC.net it is significantly faster."

The student was instructed to check all this. A specific task (I will try to define it in terms of the speed of compilers, as I was pointed out in the comments): compare the performance of standard Delphi compilers, PascalABC.net and MS VS (the versions that we have. Not so ancient, although it is sometimes difficult to always have the latter under an academic license). The calculations that he brought from the network, in general, are not particularly convincing. Yes, faster, but in specific examples. How they relate to our tasks is not entirely clear. The student was instructed, as a result, to check everything in practice.

Question, maybe someone has already encountered the need to compare the speed on large bioinformatics projects (or similar: the main body of work - strings, a large number of them, comparison, accurate and fuzzy search, tree construction, loops, statistics) Delphi vs PascalABC.net and maybe C++?

The principle of the approach to the projectile is clear, the amount of work is also clear. But, as a student's supervisor, I would like to understand how well he did his job. To do this, it would be nice to compare its results with those already available, if any.

Author: Kromster, 2017-12-25

3 answers

It seems that every third student has such desires :) At least, we often have similar student tasks, especially if students come from mehmat or VIT and want to do only programming. Well, okay, that's the lyrics.

On business. Now we have three students working on a big task to optimize the pipeline анализ->расшифровка->расчеты->моделирование->диагноз, in particular, most of it is occupied by the performance problems of our packages, including those created by different developers. compilers. The list of compilers has all three listed by you, so I can generally describe the comparison picture. I can give intermediate conclusions. I can publish detailed data only with the permission of the authors (the thesis is not finished), if it is, I will supplement the answer.

I will immediately give a class of tasks in our packages. This includes working with huge and small strings, matrices (to a lesser extent), search problems, dynamic programming, sets, Fourier series, and wavelets, I / O. The calculation time of the result of the analysis of one patient when working in one flow can reach 10-12 hours, so that errors in fractions of a second when measuring the working time can be neglected. The average of the ratio of working hours was taken into account. For different situations, the number of measurements is different, but always more than 7.

Compiler versions: Delphi for Win64 31.0 (Delphi 10.1), PascalABC.net 3.2.0.1415, VS 2015 (14.00.24720)

  1. A Delphi package written with using only standard Delphi methods and functions, in a single thread, was inferior in performance and PascalABC.net and, especially, C++. The difference in our main package could reach, depending on the data, 1.3 times with pascal and up to 1.5 x times with C++ (there are different results for different processors, this is the biggest difference). So, if you do not want to do profiling, and the speed of work is critical, I would not recommend writing in Delphi.
  2. The same thing, but in a multithreaded form. Most of our tasks are successfully parallelized, so we are willing to use multithreading. The difference between Delphi and C++ in the worst case remained about 1.5 x times, with PascalABC.net -1.1 times. Most likely, in PascalABC.net multithreading is still poorly "licked".
  3. Multithreaded profiled task. In this case, the "bottle necks" were identified and the problem areas were rewritten in assembly language. This was done for Delphi and C++. PascalABC.net does not support embedded assembler, were attempts have been made to connect libraries, but the expected success has not yet been achieved. As a result, the comparison of Delphi with C++ is a 1.15-fold lag (on Intel), an unoptimized package PascalABC.net lost to Delphi by 1.6 times
  4. Same thing, but with SIMD support. Here it is almost parity. The lag of Delphi from C++ on Intel processors is 1.06 times (it would be interesting to compile with an Intel compiler with intrinsiks, but I do not know whether it will be implemented or not), on AMD processors - 1.01 times. PascalABC was not compared - the reason is in point 3

It was also optimized for specific cores. There are generally interesting results here (in particular, when optimizing for Zen cores on Ryzen 1700 in a 16-type application, the Delphi package was repeatable faster than anyone else, which we can't clearly explain yet), but they are not presented in the intermediate output, I can't give them without the permission of the authors.

 9
Author: Viktor Tomilov, 2017-12-26 19:14:26

Select specific test tasks and describe their algorithms, highlight the typical performance indicators (CCI) of the algorithms. Encode the algorithms in all the languages of interest, including the TPP calculation. If necessary, use different compilers and hardware platforms for a program in the same language. Run through what happened and compare the results. What university do you study at? Why can't I intuitively understand what I wrote?

 3
Author: Eugene Bartosh, 2017-12-25 03:51:52
  • About the performance in the calculations. I write in Delphi scientific programs (vych. hydrodynamics) for 15 years. Before that, there were Fortran, PL\1. I know that it is now considered good form to spit aside Delphi, and praise Java or C#. I tried them, of course. However, I stayed on Delphi: it is more convenient for me in the first place when developing GUI, and secondly - when communicating with various databases that store the source data for scientific calculations.
    • Further. For scientific software the key is performance and multithreaded computing. In terms of speed , let the "student with burning eyes" not listen to anyone: he tries it himself, for example, he will write a simple matrix conversion in VS C++, Delphi 64bit, Java, C#, Python. Compares the execution time (in a loop-several matrix accesses, then in multithreaded calculation mode). And only then does he draw conclusions: they will surprise him.
    • Recently, I built access from the Delphi code (interface part) to graphics (stream) accelerator (GPU): language OpenCL 1.2. For this language, the KERNEL code itself, running on the video card, is written in C99 (ep. OpenCL versions 2.0-2.2-already C++); no compiler required-compiles the graphics card driver itself. All Delphi/C99 code is perfectly edited-analyzed in Embarcadero RAD Studio. The increase in the speed of program execution after transferring calculations to the GPU is enormous, even in comparison with multithreaded calculations on the CPU (once every 30).
    • Moral. I do not agitate for Delphi: it is unjustifiably so much dirt is being poured on it (and buried for 20 years) that the student mentioned in the topic is unlikely to find a job purely for it. But learning how to program calculations (or, say, image processing) on a GPU using OpenCL (AMD + NVidia + Intel) or CUDA (NVidia only) is very promising. And jumping from one new - fangled language to another is a waste of time. Examples of the Delphi 64bit OpenCL bundle can be found here search in the Internet for these cl. words.
 2
Author: Владимир Прокофьев, 2018-06-04 13:09:24