[Feature Request]: Compatibility with FPC Unleashed

[mobius1qwe]

Suggestion Description

Add compatibility with FPC unleashed

Assets

https://github.com/fpc-unleashed/freepascal
https://github.com/fpc-unleashed/lazarus
https://github.com/fpc-unleashed/installer

Reason for the suggestion

No response

Additional Info

No response

Referral

No response

[fibodevy]

Hello, Unleashed maintainer here.

What's preventing this from compiling specifically under Unleashed?

I changed the IFDEFs from UNLEASHED to FPC and it compiled:

diff --git a/src/database/RALDBBase.pas b/src/database/RALDBBase.pas
index c2fab4a..8a39476 100644
--- a/src/database/RALDBBase.pas
+++ b/src/database/RALDBBase.pas
@@ -51,13 +51,13 @@ type
 
     class function DatabaseName : StringRAL; virtual; abstract;
     class function PackageDependency : StringRAL; virtual; abstract;
-    {$IFDEF unleashed}
+    {$IFDEF FPC}
     property DriverType: TRALDBDriverType read GetDriverType;
     {$ENDIF}
   published
     property Database: StringRAL read FDatabase write FDatabase;
     property DatabaseType: TRALDatabaseType read FDatabaseType write FDatabaseType;
-    {$IFNDEF unleashed}
+    {$IFNDEF FPC}
     property DriverType: TRALDBDriverType read GetDriverType;
     {$ENDIF}
     property Hostname: StringRAL read FHostname write FHostname;
diff --git a/src/database/RALDBSQLCache.pas b/src/database/RALDBSQLCache.pas
index dcd6a96..bfa130a 100644
--- a/src/database/RALDBSQLCache.pas
+++ b/src/database/RALDBSQLCache.pas
@@ -62,12 +62,12 @@ type
   public
     constructor Create;
     destructor Destroy; override;
-    {$IFDEF unleashed}
+    {$IFDEF FPC}
     property DriverType: TRALDBDriverType read FDriverType write FDriverType;
     {$ENDIF}
   published
     property BookMark: TBookMark read FBookMark write FBookMark;
-    {$IFNDEF unleashed}
+    {$IFNDEF FPC}
     property DriverType: TRALDBDriverType read FDriverType write FDriverType;
     {$ENDIF}
     property ExecType: TRALDBExecType read FExecType write FExecType;

So this appears to be an upstream FPC issue rather than an Unleashed issue.

I also couldn't compile the package without the following patch:

diff --git a/src/base/RALConsts.pas b/src/base/RALConsts.pas
index 075bd8c..e0b5d07 100644
--- a/src/base/RALConsts.pas
+++ b/src/base/RALConsts.pas
@@ -78,7 +78,7 @@ resourcestring
   {$ELSEIF DEFINED(LANG_ESES)}
     {$I ..\languages\ralconsts_eses.inc}
   {$ELSE}
-    {$I ..\languages\ralconsts_enus.inc}
+    {$I ..\base\ralconsts_enus.inc}
   {$IFEND}
 
 implementation

[mobius1qwe]

The unleashed support is still under development, I haven't tested it fully yet under all the OS'es nor tested all the parts of the project. Which is why this feature request is still open. But for windows it worked.

About the language path it's probably a commit mistake, that path is on dev branch, master branch uses the changed path you set. Sorry for that.

I'll try to finish this support as soon as possible or if you would like to help, you can add a PR targeting the dev branch and it'll be merged into the repo.

Thanks for making unleashed and for commenting here

[mobius1qwe]

So, apparently unleashed is faster than regular FPC on Linux:

IDE	Engine	Avg (ms)	95% Line	Requests/s	Max Concurrent
FPC/Lazarus	mORMot2	183	555	10143,2	7500
Unleashed	mORMot2	171	455	11516,1	7500

All the other features seems to be working, no compiler errors were found, need to run some more tests to confirm.

[fibodevy]

Wow, that's great to hear - and thank you for taking the time to benchmark it properly, with a real workload and concurrency numbers.

Your benchmark made me run one myself, and indeed Unleashed is faster - and I located the exact commit that did it.

Current trunk vs Unleashed, same machine, same source file, plain {$mode objfpc}, -O2, min of 3 runs. No Unleashed feature is used anywhere in the benchmark:

FPC 3.3.1 x86_64-Win64, -O2, min of 3 runs

+----------------------+--------------+----------------------+----------------------+--------------------------------+
|                      |              |      Unleashed       |      Stock FPC       |                                |
| test                 |   iterations |   total |     per op |   total |     per op | diff (unleashed/stock)         |
+----------------------+--------------+---------+------------+---------+------------+--------------------------------+
| int64 add (control)  |    200000000 |   42 ms |    0.21 ns |   42 ms |    0.21 ns | 1.00 (equal)                   |
| thread-local (hoist) |    200000000 |   43 ms |    0.22 ns |   43 ms |    0.22 ns | 1.00 (equal)                   |
| thread-local w/ call |    200000000 |  308 ms |    1.54 ns |  473 ms |    2.37 ns | 0.65 (unleashed 53.90% faster) |
| getmem+freemem 128B  |      5000000 |   30 ms |    6.09 ns |   31 ms |    6.33 ns | 0.96 (unleashed  3.94% faster) |
| string setlength 64  |      5000000 |   49 ms |    9.88 ns |   66 ms |   13.26 ns | 0.75 (unleashed 34.21% faster) |
| string concat x2     |      5000000 |   85 ms |   17.01 ns |   95 ms |   19.17 ns | 0.89 (unleashed 12.70% faster) |
| string unique (COW)  |      5000000 |   64 ms |   12.96 ns |   67 ms |   13.49 ns | 0.96 (unleashed  4.09% faster) |
| dynarray setlen 128  |      2000000 |   40 ms |   20.16 ns |   44 ms |   22.01 ns | 0.92 (unleashed  9.18% faster) |
| class create+free    |      3000000 |   62 ms |   20.97 ns |   68 ms |   22.70 ns | 0.92 (unleashed  8.25% faster) |
| stringlist 16 adds   |       100000 |   91 ms |  916.41 ns |   97 ms |  971.03 ns | 0.94 (unleashed  5.96% faster) |
| random(1000)         |     50000000 |  162 ms |    3.26 ns |  174 ms |    3.49 ns | 0.93 (unleashed  7.06% faster) |
| exception raise      |       100000 |  132 ms | 1325.69 ns |  134 ms | 1346.87 ns | 0.98 (unleashed  1.60% faster) |
+----------------------+--------------+---------+------------+---------+------------+--------------------------------+

Note that this was measured on Win64, and the commit responsible for that boost is Windows-specific. So your 7-14% on Linux almost certainly comes from something else entirely - maybe I'll dig into what gives the boost there later.

Either way, one thing would help me interpret your numbers: did you compare against FPC trunk, or the old 3.2.2 stable release? And which optimization level, the same on both sides?

[mobius1qwe]

Either way, one thing would help me interpret your numbers: did you compare against FPC trunk, or the old 3.2.2 stable release? And which optimization level, the same on both sides?

The FPC/Lazarus version is 3.2.3/4.3, fixes for 3.2.2 and fixes for 4.2, haven't configured the 4.9 version yet. Same default "release" optimization level on both ends, the O1 I think.

I plan on doing a deeper stresstest with all the engines to see how they compare against each other and against Delphi as well, that test was just to check reliability of unleashed compared to default FPC and it is great!

Now back to this old question:

What's preventing this from compiling specifically under Unleashed?
I changed the IFDEFs from UNLEASHED to FPC and it compiled:

That part if you remove the "public" declaration and remove the ifdef on the "published" one, you'll see the error message when compiling:
"this property cannot be published"

That didn't happened with FPC, only with unleashed, but in another part of the code (in dev branch) I got the same error with a different method signature of a different section, which I'll need to review the whole thing.

[fibodevy]

Thanks, that explains a lot - and it does change the picture.

You benchmarked FPC 3.2.3, which is the fixes branch of the 3.2.x line. It gets bugfixes backported, but none of the optimizer and RTL work that has gone into trunk since 3.2 branched off years ago. Unleashed is trunk-based, so on Linux you were effectively measuring "old release line vs trunk", not "stock vs Unleashed". Most of that 7-14% is almost certainly plain upstream progress, not anything I did.

Windows is a different story. There I measured trunk vs Unleashed - same machine, same flags, same source - and Unleashed is genuinely faster. I found the commit responsible, and as I mentioned, it is Windows-specific, so it doesn't apply to your Linux numbers at all.

So would trunk vs Unleashed still show a difference on Linux? Honestly, I don't know. It's possible some other change helps there too, but I wouldn't bet on it - my guess is they would come out roughly equal.

What I'd suggest:

1. Install FPC trunk (3.3.1). fpcupdeluxe makes this painless.
2. Re-run your benchmark as trunk vs Unleashed. That isolates what Unleashed actually adds - and I'd genuinely like to see the result.

Independently of Unleashed: 3.2.x is over five years old by now. Moving to trunk is worth it on its own.

---

On the IFDEF - I don't think this is an Unleashed thing at all, it's most likely a newer-FPC thing. Unleashed is trunk plus my changes, and I haven't touched published property rules.

I tried to reproduce the "this kind of property cannot be published" difference here across 3.2.2, trunk and Unleashed, using several shapes - class property, record-typed property, indexed property, class-function getter - and trunk and Unleashed behaved identically in every single case. That's why I'm fairly confident this is a version boundary, not a fork one.

And you already answered it yourself, really: you wrote "That didn't happened with FPC, only with unleashed" - and your FPC is 3.2.x. So that's probably exactly it: 3.2.x accepts it, 3.3.1 doesn't. Just change the ifdef:

// currently
{$IFDEF unleashed}

// should be
{$IF FPC_FULLVERSION >= 30301} // 3.3.1 and up

and that's it. It will then do the right thing on 3.2.x, on trunk and on Unleashed alike, without special-casing my fork at all.