So for a while now fpc 3.3.1 receives new optimizations => which is great / big fan of it.

And hence I thought, lets see how much of an impact they have. And in my test, they had none :(
Wondering if any one else has measured them?

My tests:
Win-10 64 bit
3.3.1  905c485ff413cd48f98891e2075c814759d0c6f1
3.2.3  2022-02-04
both compilers with each O2 and O4

Using the testcase for FpDebug (which runs a decent spread of code). Testcase with O2 and O3

And I got no noticeable difference.
I also tried {$CodeAlign proc=32 loop=32} for O2 (test and fpc), also no diff.

O2 / fpc: o2 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.406 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.063 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.609 O2 / fpc: o2 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.251 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.031 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  21.531

O3 / fpc: o2 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.687 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.281 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.469 O3 / fpc: o2 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  23.203 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.250 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.140

O3 / fpc: o4 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  23.063 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.250 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.875 O3 / fpc: o4 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.577 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.094 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.235

{$CodeAlign proc=32 loop=32}
O2 / fpc: def 323
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.453 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.328 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.656 O2 / fpc: def 331
TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.079 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  22.234 TestWatchesValue_fpc 264_Dwarf_32Bit_FpDebug       :  21.984

Optimizations beyond O2 (or even O1) most of the times do not make a difference for the average user.
There is much randomness in the performance of an application caused by things you cannot control, which have more influence on the performance of the application
I watched a video about this not so long ago (it was about optimization levels in gcc), which explained all this, but I'm unable to find that again and unanble to reproduce what was being said there.

I disagree here. It depends on what you are doing.

That may have been "-Performance Matters- by Emery Berger". By I find it a nonsense video.

Regards,

Adriaan van Os

My peephole optimisations mostly save only a handful of cycles each time which probably won't add up to much for a relatively short test.  The most major optimisation I can think of, although I'm not quite sure when it was merged, is the method of replacing divisions by a constant with an equivalent reciprocal multiplication.  You'll see the biggest savings there.  There's other difficulties like processors being intelligent with caching and out of order execution, for example, that are disguising some inefficiencies.  And some seek only to reduce code size with no loss of speed.

What are your timings like when compiling with COREAVX or COREAVX2?  A couple of recent peephole optimizations make use of BMI1 and BMI2.

I can't remember the proverb that Florian used, but it essentially boils down to very small changes, individually not amounting to much, but which accumulate into a noticable difference when in large numbers.

Kit

I know the video.

Eyeballing and alignment issues were among the causes. For the latter I tried to see if codealign would have an effect. Though of course if it had, it be a lucky strike.

Adriaan van Os wrote

That may have been "-Performance Matters- by Emery Berger". By I find it a nonsense video.

Only that last year, I had some code where it happened to me. Some code (that had no change in itself, other than a routine above it (which was not part of the benchmark) had changed, and hence the tested code changed alignment. IIRC over 20% speed diff. Matched exactly what he described.

J. Gareth Moreton via fpc-devel schrieb am
Mi., 1. März 2023, 12:25:

It's a German proverb: "Mühsam ernährt sich das Eichhörnchen"

Regards,
Sven

I had -CpCOREAVX2 supplied. (my fpc is a good week old, so if recent is less than that...)
I don't have many divisions in that code.

Most of the good is going through big data in memory. So its possible that any gained processing speed, just has to wait for data to be fetched.

I can't remember the proverb that Florian used, but it essentially boils down to very small changes, individually not amounting to much, but which accumulate into a noticable difference when in large numbers.

Hence testing back to  3.2.3 ( unfortunately 3.2.2 has a bug that matters in this code)

Also, I didn't expect any huge diffs, just wanted to see if anything can be noted at all. (and if lucky, in that test I run)

I did a test on a more limited scope (testing only a handful of functions. That test runs 4 Min 20 sec under 3.2.3. And 2 extra seconds with 3.3.1.  But then I only had 2 sample runs for each fpc version....

2 seconds out of 4:20 is not conclusive unfortunately, unless you're able to exactly control the machine state each time, which is next to impossible in the modern day.  I am curious of the slowdown though, even if it is very slight.

Kit

Sven Barth wrote

It's a German proverb: "Mühsam ernährt sich das Eichhörnchen" Regards, Sven

Thanks Sven!

Kit

It will be to much code to find it....

It's looping and setting up different combinations of data/structures...

It is the test in ide/packages/idedebugger
subtest: TestWatchArrayStuct
(I did not check the others subtests, but this test is combining some of the others...)

The diff also happened when I did (for some of the involved units / not for all)
{$CodeAlign proc=32 loop=32}

But it could still be that some code got to an unfortunate alignment.

---
For more testing I would need to set up scripts, to compile and run automatically with lots of settings (and then run over night, when nothing else goes on).
Also find other PC with diff CPU ....

For now, I just wanted to do a quick test. (balance my interest with the time I have...). So I wont set up in depth testing now.

Maybe more like "Kleinvieh macht auch Mist" ?

Mattias

These proverbs come from the "German Farmer & gardeners association"'s yearly gift calendar ?

Michael.

On Wed, 1 Mar 2023 15:02:25 +0100 (CET)
Michael Van Canneyt via fpc-devel

Although the German Farmers' Association has a saying in German politics, the proverbs are much older.

Mattias

The squirrel has a hard time feeding itself

Maybe more like "Kleinvieh macht auch Mist" ?

Small livestock makes crap too

both make sense! LOL