Why isn't Lazarus / Free Pascal more popular?

[Seenkao]

Fanatics of some platform are usually hard to change their minds.

*facepalm*

Я не фанат "платформы". Я программист, пользующийся Pascal, Assembler, Java. Читающий код на многих других ЯП, потому что мне необходима информация.
Ещё раз повторюсь. Всеми своими ответами, вы только подтверждаете мои слова. Не более и не менее (и при этом, похоже, даже не читали мой пост полностью).

Напомню: не важен ЯП, важен человек, который использует этот ЯП.

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


Google translate:
I am not a fan of the "platform". I am a programmer who uses Pascal, Assembler, Java. I read code in many other PLs because I need information.
I will repeat myself once again. With all your answers, you only confirm my words. No more and no less (and it seems that you did not even read my post in full).

Let me remind you: the PL is not important, the person who uses this PL is important.

You can rely on a supercompiler, but you will never make code better and faster (in terms of code execution speed) than the person who will think with his head and see where the program can be optimized and where it cannot.
Your opinion is based on money and you need a quick solution (because it depends more on the organization). That is why we are talking about different things!

[Seenkao]

Дабы было понятно многим читающим.
Я примерно знаю как работает компилятор FPC. Я знаю его недостатки. Это мне позволяет "подсказать" компилятору, как лучше сделать, чтобы конечный код работал быстрее. Изначально я смотрел мелочи, но чем больше разбирался, тем было более понятно, как можно строить код, а как не желательно. Я стараюсь работу перевести в статические/динамические данные (в том числе и табличные). Вместо расчётов, я получаю код приближенный к конечному, который оптимизировать достаточно сложно (да, да, компилятор C/C++ улучшит положение, но не намного, потому что код уже оптимизирован).

А в ситуациях, когда есть данные/код в разных модулях, зависящих друг от друга и можно структурировать данные/код одного модуля, для того, чтоб улучшить код другого модуля и улучшить работу конечного кода.
- Если вы думаете что какой-то компилятор это сделает, то вы ошибаетесь. Компилятор не будет просматривать взаимосвязи модулей. И мелочи ему недоступны. Он не умеет думать, но  в него заложены знания многих людей. Именно из-за того, что в компилятор вложили много человеческих знаний, он может сопоставить внутренний код (примеры) с кодом который ему прислали, и оптимизировать. Но это не значит, что компилятор сможет заменить человека. Не надейтесь на это. Считайте что компилятор это ваш помощник, который помогает вам делать программы.
----------------------------------------------------------------


Google translate:
So that it is clear to many readers.
I know roughly how the FPC compiler works. I know its shortcomings. This allows me to "hint" the compiler on how best to make the final code work faster. Initially, I looked at the little things, but the more I understood, the clearer it was how you can build the code, and how it is not desirable. I try to translate the work into static/dynamic data (including tabular). Instead of calculations, I get code close to the final one, which is quite difficult to optimize (yes, yes, the C/C++ compiler will improve the situation, but not much, because the code is already optimized).

And in situations where there is data/code in different modules that depend on each other and you can structure the data/code of one module in order to improve the code of another module and improve the work of the final code.
- If you think that some compiler will do this, then you are mistaken. The compiler will not view the interrelationships of modules. And the little things are not available to it. It can't think, but it has the knowledge of many people. It is because a lot of human knowledge was put into the compiler that it can compare the internal code (examples) with the code that was sent to it, and optimize. But this does not mean that the compiler can replace a person. Do not count on it. Consider the compiler as your assistant, which helps you make programs.

[marcov]

F.ex. already now we have been looking for an employee for more than half a year for one of our projects. And finally we found only a person of pre-retirement age.

In a previous job, they advertised for C++ programmers. Worked pretty well.

[Lenny33]

and it seems that you did not even read my post in full

I carefully read all posts including yours.
But in your posts I see only assurances of your alleged superpower to think better than the compiler.
Perhaps you are such an optimizing superhero, but you haven't presented any evidence yet.

I 'm not a optimization superhero, I'm just a regular programmer with some experience in C/C++, Java, C# & Delphi/Lazarus, x86 Asm, and so on.
But unlike you I was not lazy to download scimark2 once again and even found the Delphi version for you.
scimark2 (Java & C): http://math.nist.gov/scimark
skimark2 (Delphi port): http://code.google.com/p/scimark-delphi/

It's pretty simple code there, no object approach. All actions are extremely simple and C style.
Again, all algorithms and data structures are extremely similar for all languages just to see how compilers will manage it.
I was not even lazy to add the "inline" specifier for most functions in Delphi sources and replace Integer in some places with NativeInt (in case of Delphi it can speed up even simple loops a bit, but for Lazarus - I don't know).

The code compiled by VC++2022 with optimization options /O2 and /GL gave this results:
Composite Score:         4902.81
FFT             Mflops:  3969.82    (N=1024)
SOR             Mflops:  3315.19    (100 x 100)
MonteCarlo:     Mflops:  1832.32
Sparse matmult  Mflops:  5375.93    (N=1000, nz=5000)
LU              Mflops: 10020.80    (M=100, N=100)

The code compiled by Lazarus 4.0RC2 with maximum optimization level -O4 and turned off all Checks and  Assertion gave this results:
Composite Score MFlops:  2694,44
FFT             Mflops:  2301,68    (N=1024)
SOR             Mflops:  2054,35    (100 x 100)
MonteCarlo:     Mflops:   404,23
Sparse matmult  Mflops:  4503,95    (N=1000, nz=5000)
LU              Mflops:  4207,98    (M=100, N=100)

As everyone can see VC++ created code that executes almost twice as fast as the code created by Lazarus.
And the worst results Lazarus show on MonteCarlo benchmark - only 404,23 vs 1832.32 (VC++) -> 4.5 times slower.

I was curious to why it so and was not too lazy to look at the assembly code for MonteCarlo benchmark.
In short VC++ has made most procedures as inline even though it was not asked to do so.
Whereas Lazarus left half of the procedures marked as inline as callable procedures (obviously oriented on their size).
In addition VC++ rethought the sequence of actions in some procedures (for example, in the Random_nextDouble procedure), while Lazarus clearly did everything as it was told in the source.
As a result, we got a code that works in this particular algorithm 4.5 times faster actually from the same sources.

I already anticipate in advance that you will once again tell us a fairy tale about how you will rewrite all this yourself (probably even in assembly language) and everything will work even faster.
But it is much easier for us "humble programmers" (not a fairy tale optimization superheroes as you) to entrust this time critical algorithms to compilers like VC++
And believe me, my opinion is based not only on money, as you wrote.
Although, in our solutions signal processing time is also can be money for the clients.

[Martin_fr]

I was not even lazy to add the "inline" specifier for most functions in Delphi sources and replace Integer in some places with NativeInt (in case of Delphi it can speed up even simple loops a bit, but for Lazarus - I don't know).

Admitting to my own lazyness, could you rerun the Lazarus tests, and please add at the top of each unit/file

Code: Pascal  [Select][+][-]

1. {$CodeAlign proc=$20 loop=$20}
2. {$Optimization STACKFRAME}

Thanks

It wont make up for everything. Just curious if it will at all for the given tests.

It may, it may not at all.

Also, fpc 3.3.1 is likely a bit faster. But likely only 3 or 4% => so not much to matter for this comparison.

[Seenkao]

skimark2 (Delphi port): http://code.google.com/p/scimark-delphi/

Code: Pascal  [Select][+][-]

1. function Random_nextDouble(R: PRandom): double;
2. Var
3.   k, I, j: Integer;
4.   m: PIntegerArray;
5. Begin
6.   I := R^.i;
7.   j := R^.j;
8.   m := @R^.m[0];
9.  
10.   if ((m[I] - m[j]) < 0) then
11.     inc(R^.m[j], m1);
12.  
13.   if (I = 0) then
14.     R^.i := 16
15.   else
16.     dec(R^.i);
17.  
18.   if (j = 0) then
19.     R^.j := 16
20.   else
21.     dec(R^.j);
22.     Result := dm1 * R^.m[j];
23. End;

test - MonteCarlo
No need to thank. I hope you know which module this needs to be inserted into?

--------------------------------------------------------------------------------
Другие бенчмарки я не буду корректировать, думаю на этом примере вы сами сможете их "улучшить".

Google translate:
I will not correct other benchmarks, I think you will be able to "improve" them yourself using this example.

---------------------------------------------------------------------------------

I carefully read all posts including yours.

Нет, вы прочитали то, что хотели прочитать, а не то что я пишу! Вы приравниваете банальные вещи, к суперспособностям...

Google translate:
No, you read what you wanted to read, not what I write! You equate banal things with superpowers...

[Seenkao]

Code: Pascal  [Select][+][-]

1. function Random_nextDouble(R: PRandom): double;
2. Var
3.   k, I, j: Integer;
4.   m: PIntegerArray;
5. Begin
6.   m := @R^.m[0];
7.  
8.   k := m[R^.i] - m[R^.j];
9.   if (k < 0) then
10.     inc(R^.m[R^.j], m1)
11.   else
12.     R^.m[R^.j] := k;
13.  
14.   if (r^.i = 0) then
15.     R^.i := 16
16.   else
17.     dec(R^.i);
18.  
19.   Result := dm1 * R^.m[R^.j];
20.   if (R^.j = 0) then
21.     R^.j := 16
22.   else
23.     dec(R^.j);
24. End;

обновил ранее скинутый код. Как обычно в спешке исправил код и внёс туда ошибки. 

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


Google translate:
updated the previously dropped code. As usual, I hastily corrected the code and introduced errors there.

If you dig deeper into the code, you can improve it even more. I replaced some values ​​with pointer work and got a little more growth. But that's not the most important thing. There is an array that spins in a circle. If you optimize it, I think you can get a very good growth, even compared to what I've already done.

[Lenny33]

I will not correct other benchmarks, I think you will be able to "improve" them yourself using this example...You equate banal things with superpowers

About "superpower" you don't seem to understand irony
For you to understand: This is not a CPU benchmark, but a compiler comparison (comparison of built-in optimization features that result in final code speed)
This is a test of how compilers handle such optimization tasks.
So both Java and VC++ as we see able to manage such optimization with this task without your intervention, and for at least the last 15 years.
Then why are you personally needed? Just because the more simple and less intelligent Delphi/FPC compiler can't do it?
So then who needs it in high load computing? The correct answer is almost nobody.

Personally, we use Lazarus just as a handy tool for creating cross-platform desktop interfaces.
Theoretically we could also use Qt, but a lot of code was migrated with minimal changes from an old Delphi project.
And it is certainly faster and more convenient than rewriting everything from scratch on a completely new platform without any special advantages in our case.
But all heavy computations are only in C++ libraries as before.

As usual, I hastily corrected the code and introduced errors there.

In fact, you've made another mistake. You forgot about the condition “if (R^.haveRange) then”.
But it doesn't really matter in the essence of the question.
One more time for you: we are talking here about poor optimization of the compiler itself, not about your “superpower” ability of optimization. 
And by the way, despite all your efforts, VC++ assembly code is still more optimal.
Besides, you haven't affected “inline” in any way. That's why MonteCarlo's execution speed has increased to 916 MFlops but it is still twice slower than VC++ (1832.32 MFlops).

I can partly understand why FPC compiler backwardness in optimization is a pain point for you.
You're making some game engine on FPC for some reason, although usually ~99% of developers use C++ for that, for obvious reasons.
What should I say? Then best of luck with your endless manual optimization.
Every masochist likes to experience pain differently

[Lenny33]

Admitting to my own lazyness, could you rerun the Lazarus tests, and please add at the top of each unit/file

Code: Pascal  [Select][+][-]

1. {$CodeAlign proc=$20 loop=$20}
2. {$Optimization STACKFRAME}

Thanks

It wont make up for everything. Just curious if it will at all for the given tests.
It may, it may not at all.

I tried it but unfortunately on my PC I can't see any difference. The average results are the same.

[Martin_fr]

Admitting to my own lazyness, could you rerun the Lazarus tests, and please add at the top of each unit/file

Code: Pascal  [Select][+][-]

1. {$CodeAlign proc=$20 loop=$20}
2. {$Optimization STACKFRAME}

Thanks

It wont make up for everything. Just curious if it will at all for the given tests.
It may, it may not at all.

I tried it but unfortunately on my PC I can't see any difference. The average results are the same.

Ok, it is possible that it comes to the same. Some code does benefit, but not every code.

Its for (mostly) smaller loops, some cache (not ram, but microcode translations) inside the CPU.
Might also differ by CPU.

[Seenkao]

You forgot about the condition “if (R^.haveRange) then”.

Я не забыл. Вы просто даже не исследовали код и не поняли почему я эту часть убрал.
Важно, что компилятор C/C++ со мной согласен.   


Google translate:
I haven't forgotten. You just haven't even examined the code and didn't understand why I removed that part.
The important thing is that the C/C++ compiler agrees with me. 

I can partly understand why FPC compiler backwardness in optimization is a pain point for you.

*facepalm*
Вы очередной раз что-то себе там надумали. И как обычно поняли по своему. Я не писал про компилятор, и я не говорил что он лучший. Я писал кое-что другое то, чего вы понять не хотите.
Но зато теперь, я более точно понял вас! Да, компилятор не лучший и потому я помогаю ему, в нужный момент. Вместе с ним мы неплохо справляемся.

Google translate:
Once again you have imagined something there. And as usual you have understood it in your own way. I did not write about the compiler, and I did not say that it is the best. I wrote something else that you do not want to understand.
But now I have understood you more accurately! Yes, the compiler is not the best and that is why I help it, at the right moment. Together with it we cope well.

[Lenny33]

Yes, the compiler is not the best and that is why I help it, at the right moment. Together with it we cope well.

The compiler isn't the best, the language is also already a decade behind the leaders of the genre.
Young people don't look at that language anymore either.
As we see from this test they can write more productive code even in Java without much effort.
As a consequence, it is  hard to find anyone for support and even less to develop.

Colleague, don't you think we're picking at a corpse?
To be honest, I don't like it. Well, at least I'm forced to, because there's too much interface legacy code.
But you seem to like it. 
Well, if that's your hobby, then why not.

I haven't forgotten. You just haven't even examined the code and didn't understand why I removed that part.
The important thing is that the C/C++ compiler agrees with me. 

I took another close look and once again convinced myself that such manual optimization of yours can do more harm than good.
The text with a condition was written because an alternative function can be used for tests:
Random new_Random(int seed, double left, double right),
where R->haveRange = 1;
If you leave your manual optimization - it won't work anymore.

IMHO: In 2025, it's too presumptuous to be smarter in optimization than a good optimizing compiler that has been worked on by hundreds of narrowly focused specialists.

[korba812]

Colleague, don't you think we're picking at a corpse?
To be honest, I don't like it. Well, at least I'm forced to, because there's too much interface legacy code.
But you seem to like it. 
Well, if that's your hobby, then why not.

I am guided by preferences when choosing music to listen to, a book or a snack. But never when choosing tools. I choose the tool that fits the task or problem at hand. Have you ever asked your mechanic which screwdriver or socket wrench he likes best?

[dsiders]

I'm so glad we have another troll to feed... I was getting bored.

[TRon]

I'm so glad we have another troll to feed... I was getting bored.

However (sad) it does (partly) answers OP's question