Unleashed faster than stock FPCSo, it turns out programs compiled with Unleashed run faster than the same code compiled with stock FPC. Two reports came in first, then I measured it myself.
PascalRAL: [Feature Request]: Compatibility with FPC UnleashedSo, 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.
I just tried FPC unleashed with a pet project and the performance increased 75% 
My first assumption was that this is simply upstream progress - Unleashed is trunk-based and the last stable release is over five years old. So I sat down and measured it properly:
current trunk vs Unleashed, same machine, same source file,
-O2, minimum 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) |
+----------------------+--------------+---------+------------+---------+------------+--------------------------------+
Pure arithmetic is identical, as expected - same code generator. The two thread-local rows measure access to per-thread state, which the RTL relies on internally - and that is where the difference starts. In these tests, everything involving allocation was faster.
I benchmarked on Win64, while
@mobius1qwe measured his boost on Linux - a completely different benchmark, I don't have the source - and got Unleashed 7-14% faster there. No
{$mode unleashed} in either case, just regular
objfpc.
I did locate the commit responsible for the Win64 boost (
@MathMan: no, it's not Int128, as you guessed it might be). I haven't looked into the Linux side - didn't feel like it, maybe some day. But it has to be a different commit, because the one I found is Windows-specific.
Either way: the benchmarks available so far show Unleashed running faster on both Windows and Linux, and no
{$mode unleashed} is required to get that improvement.
So, on top of that speed, Unleashed adds a large number of language features - inline variables,
match, tuples, statement expressions, string interpolation,
async/
await,
parallel for,
Int128, composable records and more - and it is
still faster, not slower. That is measured now, not claimed.
And more is coming. I deliberately don't publish too many features in too short a time, so as not to overwhelm existing and new users, but let me assure you I have quite a few ideas - plus yours.
Make FPC great again!
A word about process. Take
Record Composition by
@Warfley,
merge request !498, opened 2023-09-25.
The syntax was originally
uses TInner. In Unleashed I simply added a new keyword:
embed TInner - it sits behind a modeswitch, so it cannot break a single line of existing code. Upstream refused that route and reused an existing keyword instead. The result is
contains TInner, which, to my ear, is considerably less natural than
embed TInner.
The core team said what needed changing.
@Warfley changed it - all of it. The result: the merge request is still open, nearly three years later.
Meanwhile
@Margers just opened
Feature request: add int128 type - a feature Unleashed already ships - and referred to its origin somewhat indirectly:
As in the Free Pascal fork we don't name.
A word of thanks to the
forum administration for remaining neutral about the fork and allowing it to have a place here. They limited discussion of Unleashed to a single topic, which I completely understand and consider a fair boundary. This is, after all, the official Free Pascal forum, not an Unleashed forum. Unleashed has been allowed to exist and be discussed here without unnecessary interference, and I genuinely appreciate that.
I only wish the same neutrality existed everywhere around the project. Someone was once told off on GitLab merely for mentioning Unleashed.
But hey - someone over there said it more than once, although I don't remember who: don't like it? Fork it and make your own changes. So I did.
The funny part is that, for years, what I had been asking for was simply inline variables. That's it. Had they been added back then, Unleashed would probably never have existed. So... thanks?
This is volunteer work, done in
my own time and at
my own expense, and all of the code is public. Take it and put it in stock FPC - that is what a permissive licence is for. I will even help:
if I am given a commitment that the MR will actually be merged, I will prepare a stock-FPC version of an Unleashed feature myself. Pick one. The only exception is
Int128 - it is too large to port on a promise, with nearly 5000 lines spread across 68 files in the compiler and RTL, not counting tests and docs. Sorry.
What I will not do is spend weeks preparing a feature MR without reasonable confidence that it will be reviewed and merged, knowing what happened to !498.
