Hello,

Here is my little brute-force test for FPC, C and C# compilers. http://arbinada.com/main/en/node/1532

The results are not so good with FPC but I cannot use Delphi to compare on Linux.

Could anyone make the series on Windows with FPC, Delphi and MS .Net? The test of FPC 3.0 and any other comments are welcome.

Regards,
Serguei

Thanks for share the test. The result for Core i7 2.20 GHz 6 GB Windows 7 64 bits FPC 3.0 (last week trunk):

Found 4816030 tickets. Elapsed time, msec: 268

Delphi on Linux, how? o_O

Hi,
 
64-bit Linux, , FPC3.0.0:
 
Pascal: 440 ms
C:  163ms
Delphi )*: 515ms
 
)* Delphi7, personal edition, under wine, command: wine happyd7.exe ______________________________________________________________

Hello,

Here is my little brute-force test for FPC, C and C# compilers. http://arbinada.com/main/en/node/1532 <http://arbinada.com/main/en/node/1532>

The results are not so good with FPC but I cannot use Delphi to compare on Linux.

Could anyone make the series on Windows with FPC, Delphi and MS .Net? The test of FPC 3.0 and any other comments are welcome.

Regards,
Serguei

I think that the C code has a small problem:

Found tickets. Time elapsed: 0 msec

Just added the %d instead of %:

printf("Found %d tickets. Time elapsed: %.0f msec\n", tickets_count, msec);

Now:

gcc happytickets.c -O2 -o happytickets
./happytickets
Found 4816030 tickets. Time elapsed: 0 msec

Core i7 2.20 GHz 6 GB Windows 7 64 bits
gcc version 5.2.0 (Rev4, Built by MSYS2 project) MinGW-w64

A slightely modified testcase because MSElang has no RTL yet: "
program test;

var
  n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
  TicketsCount: int32;
  i1: int32;
begin
 for i1:= 0 to 9 do begin
  TicketsCount := 0;
  for n1 := 0 to 9 do
    for n2 := 0 to 9 do
      for n3 := 0 to 9 do
        for n4 := 0 to 9 do
          for n5 := 0 to 9 do
            for n6 := 0 to 9 do
              for n7 := 0 to 9 do
                for n8 := 0 to 9 do
                  if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
                    inc(TicketsCount);
 end;
 writeln('Found ', TicketsCount, ' tickets.');
end.
"
"
#include <stdio.h>
#include <stdint.h>

int main()
{

  unsigned char n1, n2, n3, n4, n5, n6, n7, n8;
  int i1;
  int tickets_count;

for (i1 = 0; i1 < 10; i1++){

  tickets_count = 0;
  for (n1 = 0; n1 < 10; n1++)
    for (n2 = 0; n2 < 10; n2++)
      for (n3 = 0; n3 < 10; n3++)
        for (n4 = 0; n4 < 10; n4++)
          for (n5 = 0; n5 < 10; n5++)
            for (n6 = 0; n6 < 10; n6++)
              for (n7 = 0; n7 < 10; n7++)
                for (n8 = 0; n8 < 10; n8++)
                  if (n1 + n2 + n3 + n4 == n5 + n6 + n7 + n8)
                    tickets_count++;

}

  printf("Found %i tickets.",tickets_count);
  return 0;

}
"
MSElang with LLVM 3.7.0 backend -O3:
"
time ./test.bin
Found 4816030 tickets.

real 0m0.997s
user 0m0.993s
sys 0m0.003s
"
FPC 3.0 -O3:
"
time ./testfpc.bin
Found 4816030 tickets.

real 0m5.576s
user 0m5.572s
sys 0m0.002s
"
gcc 4.8.1 -O3:
"
time ./testgcc.bin
Found 4816030 tickets.
real 0m1.649s
user 0m1.645s
sys 0m0.002s
"
Stripped binary size:
MSElang 5.5KB
FPC 3.0 21.6KB
gcc 4.8.1 5.5KB

Linux x86, AMD Athlon 4000+ 1GHz

Martin

No surprises there, you are comparing FPC with llvm.

Michael.

Stripped binary size: MSElang 5.5KB FPC 3.0 21.6KB gcc 4.8.1 5.5KB

-static flag must be missing for C(-backend) :p

Here's a test from my machine (Manjaro Linux x86_64 KDE desktop kernel 4.4.1 Core i5-4200u):

$ fpc -CX -XXs -O3 test.pas
Hint: End of reading config file /etc/fpc.cfg
Target OS: Linux for x86-64
Compiling test.pas
Linking test

/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 25 lines compiled, 0.4 sec
1 hint(s) issued
$ time ./test
Found 4816030 tickets. Elapsed time, msec: 225

real 0m0.226s
user 0m0.223s
sys 0m0.000s
$ clang -o test -s -O3 test.c
$ time ./test
Found 4816030 tickets. Time elapsed: 70 msec

real 0m0.071s
user 0m0.070s
sys 0m0.000s
$ gcc -o test -s -O3 test.c
$ time ./test
Found 4816030 tickets. Time elapsed: 109 msec

real 0m0.110s
user 0m0.107s
sys 0m0.000s
$ mcs test.cs -optimize
$ time mono test.exe
Found 4816030 tickets. Time elapsed: 236 msec

real 0m0.267s
user 0m0.260s
sys 0m0.003s

Below is the produced assembly from fpc, gcc and clang (no idea how to get one for mono):
test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s> test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s> test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s>

I hope they can be optimizers' / code generator writers' reference to improve our compiler.

Anyway, I've tried changing the for loop into while since Pascal's for isn't a syntactic sugar for while as in C's for, but apparently that didn't change anything so the emitted code is already as best as it can.

Damn, nabble doesn't like the double file extension :( Reuploaded:
FPC: test.pas_s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724117/test.pas_s> GCC: test.gcc_s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724117/test.gcc_s> Clang: test.clang_s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724117/test.clang_s>

Thanks, but assembler links are wrong, all seem to point to test.c.  
V. aka Blaazen
 
______________________________________________________________

Here's a test from my machine (Manjaro Linux x86_64 KDE desktop kernel 4.4.1 Core i5-4200u):

Below is the produced assembly from fpc, gcc and clang (no idea how to get one for mono):
test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s <http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s>>   test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s <http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s>>   test.s
<http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s <http://free-pascal-general.1045716.n5.nabble.com/file/n5724116/test.s>>  

I hope they can be optimizers' / code generator writers' reference to improve our compiler.

Anyway, I've tried changing the for loop into while since Pascal's for isn't a syntactic sugar for while as in C's for, but apparently that didn't change anything so the emitted code is already as best as it can.

Serguei TARASSOV wrote

Could anyone make the series on Windows with FPC, Delphi and MS .Net? The test of FPC 3.0 and any other comments are welcome.

On my PC with Windows 8.1, fpc 2.6.4 32bits, when I changed the line:
inc(TicketsCount);
to:
TicketsCount := TicketsCount + 1;

the results improved from:
C:\tmp\tests>HappyTickets.exe
Found 4816030 tickets. Elapsed time, msec: 323

to

C:\tmp\tests>HappyTickets.exe
Found 4816030 tickets. Elapsed time, msec: 262

Paulo Costa

I can confirm, Inc(); is slower. Change decreased time from 440 to 390 ms.  
Quick test (empty project in Laz.):
unit1.pas:35                              inc(TicketsCount); 000000000046DB18 4883c001                 add    $0x1,%rax unit1.pas:36                              TicketsCount+=1; 000000000046DB1C 488d4001                 lea    0x1(%rax),%rax unit1.pas:37                              TicketsCount:=TicketsCount+1; 000000000046DB20 488d5801                 lea    0x1(%rax),%rbx ______________________________________________________________

Serguei TARASSOV wrote

Could anyone make the series on Windows with FPC, Delphi and MS .Net? The test of FPC 3.0 and any other comments are welcome.

On my PC with Windows 8.1, fpc 2.6.4 32bits, when I changed the line:
inc(TicketsCount);
to:
TicketsCount := TicketsCount + 1;

the results improved from:
C:\tmp\tests>HappyTickets.exe
Found 4816030 tickets. Elapsed time, msec: 323

to

C:\tmp\tests>HappyTickets.exe
Found 4816030 tickets. Elapsed time, msec: 262

Paulo Costa

Vojtěch Čihák wrote

I can confirm, Inc(); is slower. Change decreased time from 440 to 390 ms.

my 10 run averages seems to all be right in the same neighborhood... maybe my machine has a lot more going on in the background which is affecting my simplistic testing?

AMD Vishera Black FX 8350 8-core 4Ghz 16.0MB cache Kubuntu 14.04 - 16GB RAM - there are at least 8 VMs running at all times plus several servers and numerous user apps...

FWIW: these are the results of my tests...

===== inc(TicketsCount) =====
~/development/projects/misc$ for foo in 0 1 2 3 4 5 6 7 8 9; do time ./happytickets; done;
Found 4816030 tickets. Elapsed time, msec: 331

real 0m0.333s
user 0m0.316s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 341

real 0m0.344s
user 0m0.326s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 315

real 0m0.317s
user 0m0.303s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 323

real 0m0.325s
user 0m0.325s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 336

real 0m0.340s
user 0m0.315s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 320

real 0m0.321s
user 0m0.320s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 318

real 0m0.319s
user 0m0.315s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 388

real 0m0.390s
user 0m0.309s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 278

real 0m0.281s
user 0m0.265s
sys 0m0.004s
Found 4816030 tickets. Elapsed time, msec: 297

real 0m0.298s
user 0m0.298s
sys 0m0.000s
===== end =====

===== TicketsCount += 1 =====
~/development/projects/misc$ for foo in 0 1 2 3 4 5 6 7 8 9; do time ./happytickets; done;
Found 4816030 tickets. Elapsed time, msec: 319

real 0m0.321s
user 0m0.311s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 301

real 0m0.302s
user 0m0.302s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 297

real 0m0.299s
user 0m0.277s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 309

real 0m0.310s
user 0m0.310s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 274

real 0m0.275s
user 0m0.274s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 348

real 0m0.356s
user 0m0.325s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 333

real 0m0.334s
user 0m0.319s
sys 0m0.004s
Found 4816030 tickets. Elapsed time, msec: 256

real 0m0.257s
user 0m0.257s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 288

real 0m0.289s
user 0m0.289s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 249

real 0m0.251s
user 0m0.251s
sys 0m0.000s
===== end =====

===== TicketsCount := TicketsCount + 1 =====
~/development/projects/misc$ for foo in 0 1 2 3 4 5 6 7 8 9; do time
./happytickets; done;
Found 4816030 tickets. Elapsed time, msec: 381

real 0m0.383s
user 0m0.328s
sys 0m0.004s
Found 4816030 tickets. Elapsed time, msec: 301

real 0m0.302s
user 0m0.298s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 308

real 0m0.310s
user 0m0.310s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 322

real 0m0.375s
user 0m0.318s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 308

real 0m0.314s
user 0m0.309s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 325

real 0m0.327s
user 0m0.327s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 318

real 0m0.319s
user 0m0.319s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 286

real 0m0.290s
user 0m0.286s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 247

real 0m0.248s
user 0m0.248s
sys 0m0.000s
Found 4816030 tickets. Elapsed time, msec: 290

real 0m0.292s
user 0m0.290s
sys 0m0.000s
===== end =====

For the record: with a few changes in the compiler I could reduce the execution time of the example significantly . But I won't commit it probably (maybe parts of it): extensive loop unrolling and loop invariant search has normally little advantages in real world programs and increases only compilation times.

If it is easy to implement could it be optional?

Mattias

Do you think people will bother? Nobody mentioned to the original poster so far:
- that the used FPC is outdated
- that only -O2 is used instead of -O3 (or -O4 with 3.0.0)
- that even FPC 2.6.4 has a -Ooloopunroll option which is never enabled by default and which is worth a try

I do not know if the points above really effect the example, but it tells me enough not to bother either :)

Maybe documentation helps here.

Is there already a page "pimp my fpc"?

Mattias

When I change the programm to run inside a procedure (because this would be the more realistic scenario) the performance decreases about 15% - 160ms in global vs 185ms inside procedure.

program HappyTickets;
uses
  SysUtils, DateUtils;
procedure run;
  var
    n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
    TicketsCount: int64;
    d1, d2: TDateTime;
  begin
    TicketsCount := 0;
    d1 := Now;
    for n1 := 0 to 9 do
      for n2 := 0 to 9 do
        for n3 := 0 to 9 do
          for n4 := 0 to 9 do
            for n5 := 0 to 9 do
              for n6 := 0 to 9 do
                for n7 := 0 to 9 do
                  for n8 := 0 to 9 do
                    if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
                      TicketsCount := TicketsCount + 1; //
Inc(TicketsCount) may be slower in FPC
    d2 := Now;
    writeln('Found ', TicketsCount, ' tickets. Elapsed time, msec: ',
DateUtils.MilliSecondsBetween(d1, d2));
  end;
begin
    run;
end.

Hello,

thank all for assistance!

Sorry, I was not clear, the series should be ran with all tests _on the same computer_ regardless its hardware capacity and on the _same OS_. That's why I cannot compare with Delphi.

So if you have modern Delphi, FPC and maybe .NET on your Windows computer please compare them with about 5-10 runs to get average time.

Thank you for the Inc() hint, I added it to the comments, it gains about 10% for me.
However, in Delphi Inc() is faster until you turn on the checking overflow.

Another strange effect in FPC.
Only longint shows correct result. With the integer type the optimizer seems to replace type with shortint (16-bits) and I see 31902 instead of 4816030.

Regards,
Serguei

You mean something like the page Size Matters? See the post of Martin Schreiber how much such pages help.

Is there already a page "pimp my fpc"?

In this case even fpc -h would have helped :)

But actually, before bothering randomly with command line options, I
would just rewrite the inner loop. Something like
              for n7 := 0 to 9 do
                if n1 + n2 + n3 + n4 - n5 - n6 - n7 in [0..9] then
                  Inc(TicketsCount);
should be much better.

Florian Klaempfl wrote

I do not know if the points above really effect the example,

It does.

[tmp]$ fpc -O2 -Cr- test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others [tmp]$ ./test
Found 4816030 tickets. Elapsed time, msec: 184
[tmp]$ ls -l test
-rwxr-xr-x 1 graemeg wheel 908471 14 Feb 10:06 test

[tmp]$ fpc -O3 -Cr- test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others [tmp]$ ./test
Found 4816030 tickets. Elapsed time, msec: 178
[tmp]$ ls -l test
-rwxr-xr-x 1 graemeg wheel 908471 14 Feb 10:07 test

[tmp]$ fpc -O4 -Cr- test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others [tmp]$ ./test
Found 4816030 tickets. Elapsed time, msec: 178
[tmp]$ ls -l test
-rwxr-xr-x 1 graemeg wheel 908471 14 Feb 10:08 test

[tmp]$ fpc -O4 -Ooloopunroll -Cr- test.pas
Free Pascal Compiler version 3.0.0 [2015/11/16] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others [tmp]$ ./test
Found 4816030 tickets. Elapsed time, msec: 151
[tmp]$ ls -l test
-rwxr-xr-x 1 graemeg wheel 908471 14 Feb 10:08 test

The "-O4 -Ooloopunroll" options produced the fastest executable out of the above tests.

But then, I think such non-realword tests don't prove much.

Regards,
- Graeme -

just for fun: build a node.js from the nim language version which runs in 204ms (c version in 44ms). So fpc (185ms) is more close to js than to c in this case

import times

proc run() =
var TicketsCount = 0
var d1 = epochTime() * 1000.0
for n1 in 0 .. 9 :
for n2 in 0 .. 9 :
for n3 in 0 .. 9 :
for n4 in 0 .. 9 :
for n5 in 0 .. 9 :
for n6 in 0 .. 9 :
for n7 in 0 .. 9 :
for n8 in 0 .. 9 :
if n1 + n2 + n3 + n4 == n5 + n6 + n7 + n8 :
TicketsCount = TicketsCount + 1
var d2 = epochTime() * 1000.0
echo "found ", TicketsCount, " in ", d2-d1, "ms"

run()

compile and run with (remove -r to run it immediately):

nim js -d:release -d:nodejs -r happy.nim

for the c version

nim c -d:release -r happy.nim

-O4 is always useful, if your programs work with it (as it contains -Oofastmath) and if you can life with the fact that -gl is completely bogus.

Graeme Geldenhuys wrote

The "-O4 -Ooloopunroll" options produced the fastest executable out of the above tests.

And for those interested, my system is as follows:

# /sbin/sysctl hw.model
hw.model: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz

# uname -a
FreeBSD graeme-desktop 10.1-RELEASE-p16 FreeBSD 10.1-RELEASE-p16 #0: Tue Jul 28 12:04:19 UTC 2015
amd64

# /sbin/sysctl hw.physmem
hw.physmem: 34261151744 (32GB)

Regards,
- Graeme -

Florian Klaempfl wrote

and if you can life with the fact that -gl is completely bogus.

I would have thought -gl (or any debug info for that matter) is bogus with optimisation -O2 or greater. When I specify any -g debug settings I always include -O- as well. Release builds I obviously use different settings (no debug info and minimum -O2).

Regards,
- Graeme -

To back up Florian with numbers:

No in:
Found 4816030 tickets. Elapsed time, msec: 171

Using in:
Found 4816030 tickets. Elapsed time, msec: 23

Michael.

How can this happen?
As far as I remember, INC was introduced
to speed up this kind of calculation,
not to slow it down.
The compiler should be able to optimize
INC much easier than +1 within a (potentially)
complicated expression.

Il 14/02/2016 11:09, Florian Klaempfl ha scritto:

For the record:

Platform: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz OS: Linux CentOs 6

1) With FPC
Compiler: fpc 2.6.4.
Compiler flags: -O3 -Cr-

Inc(TicketsCount) replaced with TicketCounts:=TicketCounts+1

Original inner loop:

SandBox]$ ./HappyTickets Found 4816030 tickets. Elapsed time, msec: 215

(range from 215 to 225)

Florian's inner loop:

SandBox]$ ./HappyTickets_florian Found 4816030 tickets. Elapsed time, msec: 20

(range: from 17 to 26 ms)

2) With GNU C
Compiler: gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) Compiler flags: -O3

Found 4816030 tickets. Time elapsed: 80.0000 msec SandBox]$ ./happytickets

(range from 70 to 80 ms)

My conclusion:
depending on how you code, GCC wins over FPC by 3-1 or FPC wins over GCC 4-1!

Giuliano

Il 14/02/2016 11:12, Graeme Geldenhuys ha scritto:

But then, I think such non-realword tests don't prove much.

Except that the implementation of inc(something) should be given a look,
as it's always been sold as faster than something:=something+1

Giuliano

No really. It is not a matter of +1 vs. inc but how it is compiled: as add or lea. And the decision add vs. lea is not straight forward. It depends on the surrounding code and the exact core. So without a detailed analysis of the generated assembler with regard to the used core any tests about it are useless. In theory, a compiler could decide very good if add or lea is better. But this decision applies only to a certain core and not in general. So for a all-purpose compiler this makes little sense. If your application really depends on this, rewrite the hotspots in C and use the icc to compile it. It knows about these detais.

Il 14/02/2016 12:56, Florian Klaempfl ha scritto:

Good to know. Thanks a lot.

Giuliano

Il 14/02/2016 10:51, Adrian Veith ha scritto:

When I change the programm to run inside a procedure (because this would be the more realistic scenario) the performance decreases about 15% - 160ms in global vs 185ms inside procedure.

Using Florian's suggestion, performance outside and inside a procedure doesn't change that much:

Main program:

range = 16-23 - average= 19.0 ms

Inside a procedure:

range = 17-24 - average = 19.7ms - diff. = +3.68%

Giuliano

Michael Van Canneyt wrote

Using in: Found 4816030 tickets. Elapsed time, msec: 23

Wow... well spotted improvement Florian.

Regards,
- Graeme -

Does that read
(extensive loop unrolling) and (loop invariant search) or
extensive- (loop unrolling) and (loop invariant search) That is, does fpc 3.0 do some none extensive loop invariant search or not?

How would the loop invariant affect this issue?
http://bugs.freepascal.org/view.php?id=10275

I remember in the 1980ies that was one of the thinks people got taught to look out for and optimize themselves since compilers wouldnt. So back then it mattered.

In our previous episode, Florian Klaempfl said:

I took one look at the used benchmark, and skipped the whole thread. Too synthetic.

In our previous episode, Graeme Geldenhuys said:

The less optimization the better chance that the debugger can print the values of an expression in the debugger. That is also so with Delphi.

But it is not impossible. I often do initial debugging in Delphi with optimization on simply because the code is much slower otherwise.

Does FPC generate different code for Intel (like Core i7) and AMD (like Phenom or so) when taget architecture is set to x86_64, i.e. are there any CPU manufacturer specific optimizations ?  
Thanks for reply,
 
V.
______________________________________________________________

 So for a all-purpose compiler this
makes little sense. If your application really depends on this, rewrite the hotspots in C and use the icc to compile it. It knows about these detais.

Not so doesn't explain why C# with IL is significantly better than native code generated by FPC.

Regards,
Serguei

Florian Klaempfl wrote

No really. It is not a matter of +1 vs. inc but how it is compiled: as add or lea. And the decision add vs. lea is not straight forward. It depends on the surrounding code and the exact core.

After reading this (especially the comments)
http://stackoverflow.com/questions/1658294/whats-the-purpose-of-the-lea-instruction the speed also seems to be dependend on the specific processor used (even whithin the same family)
which makes such benchmarks somewhat arbitrary (if the compiler does not take it into account).

Not so good at all. It doesn't explain why C# with IL is significantly better than native code generated by FPC.

I believe the .NET runtime has optimizations that Florian, judging from his answer a few posts behind, is not willing to commit due to low real world benefit. He seems to have Prof. Wirth spirit in that compilation must be as fast as possible while generating code as optimized as it can in that available time. I don't understand though, why it can't be made another -OoXXX that's disabled by default and perhaps activated in -O3 and above only (-O2 is used to bootstrap the compiler toolchain, if you don't override it, so it won't be affected).

As the original poster was even not able to find out that -Ooloopunroll is available and even helps (at least with 3.0.0, see Graemes post) I see no point in another switch.

and perhaps activated in -O3 and above only (-O2 is used to bootstrap the compiler toolchain, if you don't override it, so it won't be affected).

Marco van de Voort wrote

simply because the code is much slower otherwise.

When debugging, speed should be irrelevant really. Most of the times I'll step through code. Can't get slower than that! ;-)

Regards,
- Graeme -

Hm,

doing the same trick in C, it goes down from:

40ms (original) to 3ms (omit the inner loop).

This is still the same distance to fpc (v 3.0.0 with -O4 -Ooloopunroll)

185ms (original) to 12ms (omit the inner loop).

C is 4 times faster here.

Well, as said before: if the speed of code like this is important for you, use C.

On Sun, Feb 14, 2016 at 4:45 AM, Mattias Gaertner <

In fact there's but.
http://wiki.freepascal.org/Improving_language_shootout_results

But the information is a bit outdated.

thanks,
Dmitry

No, the test against MIN shows only the case when the result was _minimally contaminated_ in the series. But we don't know whether the unused time was bigger or smaller than for other program. Also, it is very probably that the minimal time in series of 1000 will be better that in series of 10 and so on.

The average approach smooth the contaminated time in series for all programs.
But you could use some better approaches like the direct measure of the time used by CPU or simply remove extreme values.

I don't suppose that it changes anything in the relative comparison that is the goal of test.

Regards,
Serguei

I don't want to insist on this, but: if you measure the runtime of your program you result = runtime + error. If you measure a series against MIN you measure MIN(result) = runtime + MIN(error) which delivers the best value for runtime.

i thought about this, too... especially considering starting the test's binary from the command line each time and how disk caching may affect loading and unloading...

one might also have the program go a little further than a simple one-time execution and have it loop internally while keeping up with the minimum, maximum and average times and output them at the end in addition to the other output in the test itself... [code below]

I don't suppose that it changes anything in the relative comparison that is the goal of test.

possibly not...

===== snip =====
program HappyTickets;
uses
   SysUtils, DateUtils;
var
   loopcnt : integer;
   elapsedtime, mintime, maxtime, avgtime: int64;
   procedure runtest;
   var
     n1, n2, n3, n4, n5, n6, n7, n8: 0..9;
     TicketsCount: int64;
     d1, d2: TDateTime;
   begin
     TicketsCount := 0;
     elapsedtime := 0;
     d1 := Now;
     for n1 := 0 to 9 do
       for n2 := 0 to 9 do
         for n3 := 0 to 9 do
           for n4 := 0 to 9 do
             for n5 := 0 to 9 do
               for n6 := 0 to 9 do
                 for n7 := 0 to 9 do
                   for n8 := 0 to 9 do
                     if n1 + n2 + n3 + n4 = n5 + n6 + n7 + n8 then
//                    if n1 + n2 + n3 + n4 - n5 - n6 - n7 in [0..9] then
                       Inc(TicketsCount);
//                      TicketsCount += 1;
//                      TicketsCount := TicketsCount + 1;
     d2 := Now;
     elapsedtime := DateUtils.MilliSecondsBetween(d1, d2);
     writeln('Round ',loopcnt:4,' Found ', TicketsCount, ' tickets. Elapsed
time, msec: ',elapsedtime );
   end;
begin
   elapsedtime := 0;
   mintime := 0;
   maxtime := 0;
   avgtime := 0;
   for loopcnt := 1 to 1000 do
     begin
       runtest;
       if mintime = 0 then mintime := elapsedtime;
       if maxtime = 0 then maxtime := elapsedtime;
       if avgtime = 0 then avgtime := elapsedtime
       else avgtime := (avgtime + elapsedtime) div 2;
       if elapsedtime < mintime then mintime := elapsedtime;
       if elapsedtime > maxtime then maxtime := elapsedtime;
       writeln('Min: ',mintime:5,'   Max: ',maxtime:5,'   Avg: ',avgtime);
     end;
end.

===== snip =====

Good news.
Do you have any ideas why this kind of optimization is special?

For info, simple loop test like

   while i < 1000000000 do
     i := i + 1;

shows that the FPC code is 2 times slower than Delphi 7 and Borland C 5.5 and 4 times slower that C#.

Regards,
Serguei

If that's really all there is in your program, then the C# compiler probably replaces that with "i+=1000000000;" (gcc and clang definitely will do that, I don't know about Delph 7/Borland C 5.5). This is another kind of optimisation that is seldom useful in real world programs (normally the loop will also do something useful, in which case you can't do that).

FPC indeed does not implement many of these optimisations, because we prefer to spend our time on other things. If you, or anyone else, wants to implement transformations for such idioms, you're welcome and we'll happily apply your patches if they are implemented as generic node tree optimisation passes.

Jonas

Do you have any ideas why this kind of optimization is special?

Didn't Florian said that this kind of optimization has no benefit in real world programs and will only increase compilation time?

Just checked such a code with gcc 5.3.0, in -O2 the generated assembly is:

xorl %eax, %eax
ret

which literally does nothing. Without optimization the speed is equal.

Hello,

Some updates of tests.

I added a simple assembler code as a reference of the "minimally poor code".

GCC has a good optimizer reducing the time in two. C#/IL has about the same result.
Unfortunately, FPC (3.0.0 64 bits) is always under the "minimally poor".

In addition :
- changing types of n1-n8 variables to "longint" increases the time to 10%
- changing types to "integer" doubles the time!! In contrast, with Delphi 10 it decreases the time by 60%.

-----

Is there a reason for this, or is it a bug?

The Integer type depends on what compiler mode you are in, and what operating system. Sometimes it's 32bit and other times it's 16bit.

Jeppe Johansen-3 wrote

It was FPC 2.6.4 64 bits in FPC mode on Linux. See the sources to reproduce. Change:
TicketsCount: longint;
to
TicketsCount: integer;

Compile: fpc -O2 -Cr- HappyTickets.pas

Result: Found 31902 tickets. Elapsed time, msec: 203

I don't see any reason to use 16-bits integer in this code much less in 64-bits mode.

I don't test it yet in FPC 3.0 bit 3.0 has other problems with my test:
- changing the type of n1-n8 from 0..9 to longint increases the time by 10%
- changing the type of n1-n8 from 0..9 to integer doubles the time!

On the contrary, in Delphi 10 changing the type of n1-n8 from 0..9 to integer decreases the time by 60%

-----

Serguei TARASSOV wrote on Thu, 03 Mar 2016:

Jeppe Johansen-3 wrote >> > The Integer type depends on what compiler mode you are in, and what > operating system. Sometimes it's 32bit and other times it's 16bit.

AFAIK it only depends on the compiler mode.

The reason is, as always, compatibility. FPC mode started as an extension of the Turbo Pascal compatibility mode. In Turbo Pascal, integer is 16 bits. In Delphi, it's 32 bits, so both in Delphi and in ObjFPC modes, integer is 32 bits. Code that was written with integer = 16 bits may no longer work the same if the size of the integer type is changed to 32 bits (especially if overflow checking is off).

If you want to compare with Delphi, it's better to compile the program in Delphi mode. You should see the same 10% increase in FPC that you see when you change it to longint.

Jonas

Jonas Maebe-2 wrote

If I understood correctly, the FPC programmer in 2016 always should include {$MODE DELPHI} or {$MODE ObjFPC} to avoid TurboPascal legacy that I use in earlies 1990?
Ok, it's not so important, only a rhetorical question.

I retested in Delphi mode, the time is the same.
Changing type to integer with Delphi7 decrease the time from 215 to 155 msec in my environment. FPC shows about 189 msec and the same 155 in delphi mode with integer type.

So the default FPC mode seems to be significantly more slow than Delphi-mode and ObjFPC-mode.

-----

Serguei TARASSOV wrote on Thu, 03 Mar 2016:

If I understood correctly, the FPC programmer in 2016 always should include {$MODE DELPHI} or {$MODE ObjFPC} to avoid TurboPascal legacy that I use in earlies 1990?

FPC mode started in those same early 1990s. The first code that was written for this mode dates from that period as well.

Ok, it's not so important, only a rhetorical question.

On the contrary, it is fundamental. Changing defaults in existing language modes, or changing the default language mode that is used, would break existing code with as only reason that we wouldn't want to look bad when people use the compiler for the first time and don't realise what the default mode is/entails. We're not about projecting a particular image, we're about trying not to break things that already work as far as the language is concerned.

Look at how Inprise/CodeGear/... alienated many developers by (a.o.) breaking backwards compatibility all the time and pushing what was supposed to be the next greatest thing instead. It's just not fair to existing users, who mainly don't want their code to break (just like you with the with/property problem earlier on). Any improvements on top of that is gravy, but it's not the most important.

So the default FPC mode seems to be significantly more slow than Delphi-mode and ObjFPC-mode.

It's unrelated to the compiler mode. However, performing 16 bit integer arithmetical instructions on a processor that is very inefficient at doing so (such as 32 and 64 bit Intel x86 processors running in 32 or 64 bit mode -- I don't know about AMD) can indeed be quite slow. Ideally, the compiler would internally "upgrade" those operations to 32/64 bit where possible, but it doesn't do so. The amount of 16 bit integer code that should run as fast as possible on 32/64 bit x86 Intel processors is probably not that big either.

Jonas

Jonas Maebe-2 wrote

I agree your point but with some limitations.
IMHO, the period of 10 years as a maximum is very sufficient for migration or we stay with the old version of compiler and common libraries. On other hands, there are different breaks of compatibility. The TP mode can be applied globally by compiler switch and it solve the problem of default mode.
But adding the functions/methods/properties to existing classes of common libraries breaks the old code that should be rewritten (if the error is detected by compiler).
The second case is really important because there is no workaround.

-----