Forum > FPC development

How optimized is the FPC compiler

<< < (29/29)

PascalDragon:

--- Quote from: Akira1364 on January 02, 2022, 11:51:54 am ---Yeah, that's what I was referring to in my comment. It works ok-ish as-is, but does not have any impact on pre-compiled units of course.

--- End quote ---

Of course it does not, because it needs to have the node tree available in the PPU which is only the case if the routine has the inline directive or was compiled while the AutoInline optimization was enabled.

Akira1364:

--- Quote from: PascalDragon on January 03, 2022, 02:08:28 pm ---
--- Quote from: Akira1364 on January 02, 2022, 11:51:54 am ---Yeah, that's what I was referring to in my comment. It works ok-ish as-is, but does not have any impact on pre-compiled units of course.

--- End quote ---

Of course it does not, because it needs to have the node tree available in the PPU which is only the case if the routine has the inline directive or was compiled while the AutoInline optimization was enabled.

--- End quote ---

Right, yeah, I'm aware of why it doesn't work that way currently. Again, my original comment was envisioning a world where FPC just auto-inlined appropriately all the time when compiling code (as most compilers do, at least nowadays) regardless of the presence of any particular modeswitch.


--- Quote from: Martin_fr on January 02, 2022, 01:12:24 pm ---If for example some commercially sold code is released as ppu/o only, then they may not want to distribute such extra info (which could be used to gain insight into their unpublished code).

--- End quote ---

I think if that sort of thing was actually a realistic concern in conjunction with inlining specifically, it would be a known issue to at least some extent in other languages. It's not though, at least as far as I've ever heard.

abouchez:
After decades working with Delphi, and now FPC as my main compiler, I don't think FPC is much slower. It is actually faster, in some areas.
Especially since FPC 3.2 code generation was much better. Much less bloated asm as it did with previous versions.

I agree that the RTL is sometimes non-optimal (missing "const" or "inline").
But its purpose was to be cross-platform and maintainable.
This is why with my mORMot I rewrote most of the RTL, and bypassed it, writing some optimized asm for the most critical part.
https://github.com/synopse/mORMot2

Honestly, the server side is where performance matters - especially multi-threaded performance.
For LCL or client applications, compiler quality is less essential. You can have reactive apps written in python. :)

When I run the mORMot 2 regression tests, I have a huge set of realistic benchmarks, which cover a lot of aspects, like data structures, JSON, cryptography, http/websockets client and server, database, multi-threading....
Then we can compare between compilers and systems.
The fastest is with FPC and Linux on x86_64, with our own x86_64 memory manager written in asm. https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.fpcx64mm.pas is worth a try and gives a noticeable performance boost on server processing and memory usage, especially on multi-threading process.

From those regression tests, Delphi is behind, especially due to the Windows overhead, and also to more tuned pascal code targeting FPC.
Delphi outside Win32/Win64 is simply not optimized - even if they use LLVM as codegen backend, LLVM is not leveraged and resulting asm is not very good.
So I stick with FPC as my main target for optimization. And even if AARCH64 codegen is not optimal, it is pretty stable and we can have good numbers with a few bit of asm and statically linked library - see https://blog.synopse.info/?post/2021/08/17/mORMot-2-on-Ampere-AARM64-CPU

Of course, this is only an opinion.
And I like FPC so much that I am officially biased.  O:-) But I have no wish to come back to Delphi. Lazarus is so more light and stable for daily use - and with fpdebug starts to be good enough for debugging. But as a compiler, FPC is amazing and do a very good job.
Open Source rocks!

Navigation

[0] Message Index

[*] Previous page

Go to full version