Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

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.

Am 14.02.2016 um 12:09 schrieb Michael Van Canneyt:
>
>
> On Sun, 14 Feb 2016, Florian Klaempfl wrote:
>
>> Am 14.02.2016 um 10:45 schrieb Mattias Gaertner:
>>> On Sun, 14 Feb 2016 10:35:22 +0100
>>> Florian Klaempfl  wrote:
>>>
 [...]
 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.
>>
>> 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.
>
> 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.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Graeme Geldenhuys]

On 2016-02-14 11:09, Michael Van Canneyt wrote:
> Using in:
> Found 4816030 tickets. Elapsed time, msec: 23

Wow... well spotted improvement Florian.

Regards,
  - Graeme -

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> On 2016-02-14 10:23, 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).

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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Jürgen Hestermann]

Am 14.02.2016 um 12:56 schrieb Florian Klaempfl:
> 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).


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klämpfl]

Am 14.02.2016 um 13:34 schrieb Serguei TARASSOV:
> On 14/02/2016 12:57, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Sun, 14 Feb 2016 12:09:42 +0100 (CET) From: Michael Van Canneyt 
>>  To:
>> FPC-Pascal users discussions  Subject: Re: 
>> [fpc-pascal] Happy
>> tickets benchmark On Sun, 14 Feb 2016, Florian Klaempfl wrote:
>>>
>>> >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.
>> 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.
> As I said, the goal of the test is to compare the compilers, 

The goal, yes.

> not the programmer's intelligence.
> You should remove inner loop from C and C# code to get a meaningful result.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Martin]

On 14/02/2016 12:44, Florian Klämpfl wrote:

Am 14.02.2016 um 13:34 schrieb Serguei TARASSOV:

On 14/02/2016 12:57, fpc-pascal-requ...@lists.freepascal.org wrote:

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.

To back up Florian with numbers:

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

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

As I said, the goal of the test is to compare the compilers,

The goal, yes.

Out of interest, how does the modified code compare with/without the 
"loop invariant" patch?


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

On 14/02/2016 15:01, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Sun, 14 Feb 2016 13:17:38 +0100
From: Giuliano Colla
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark

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

>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.

Good to know. Thanks a lot.

Giuliano

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


Regards,
Serguei
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klämpfl]

Am 14.02.2016 um 16:08 schrieb leledumbo:
>> 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

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).

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Martin]

On 14/02/2016 09:11, Florian Klaempfl wrote:
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.

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.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Vojtěch Čihák]

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.
__

Od: Florian Klaempfl 
Komu: "FPC-Pascal users discussions" 
Datum: 14.02.2016 12:57
Předmět: Re: [fpc-pascal] Happy tickets benchmark


Am 14.02.2016 um 12:47 schrieb Giuliano Colla:

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


 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.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[leledumbo]

> 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).



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724155.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Graeme Geldenhuys]

On 2016-02-14 12:58, 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 -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
> 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.

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.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Please someone explain this to me

[Michael Van Canneyt]

On Sun, 14 Feb 2016, Jürgen Hestermann wrote:


Am 2016-02-11 um 14:21 schrieb Sven Barth:
If they are just learning the language then they shouldn't poke around in 

the core units anyway. That's what the documentation and help is for.
Back when I started learning TP I didn't have the internet and I didn't 
have the sources of the units. I only had the help and it was definitely 
enough, so no I'm not even remotely convinced by your argument.


Strange that suddenly the documentation should be used
while in the past everybody else is telling me (and others)
to look into the code to understand it.


Nothing strange about it.

There is a difference between learning the language, which implies knowing
what routines are available to you, and understanding how a particular 
routine works in detail. The latter requires you to study the source code.

For the former, you don't need the details: the documentation is the better
alternative.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 10:23 schrieb Mattias Gaertner:
> On Sun, 14 Feb 2016 10:11:54 +0100
> Florian Klaempfl  wrote:
> 
>> [...]
>> 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?

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 :)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

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.


Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
> 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
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Florian Klaempfl]

Am 14.02.2016 um 10:45 schrieb Mattias Gaertner:
> On Sun, 14 Feb 2016 10:35:22 +0100
> Florian Klaempfl  wrote:
> 
>> [...]
>> 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.

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.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Please someone explain this to me

[Jürgen Hestermann]

Am 2016-02-11 um 14:21 schrieb Sven Barth:
> If they are just learning the language then they shouldn't poke around in the 
core units anyway. That's what the documentation and help is for.
> Back when I started learning TP I didn't have the internet and I didn't have 
the sources of the units. I only had the help and it was definitely enough, so no 
I'm not even remotely convinced by your argument.

Strange that suddenly the documentation should be used
while in the past everybody else is telling me (and others)
to look into the code to understand it.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Giuliano Colla]

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

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.


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:

[colla@probookcolla SandBox]$ ./HappyTickets
Found 4816030 tickets. Elapsed time, msec: 215

(range from 215 to 225)

Florian's inner loop:

[colla@probookcolla 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. msec
[colla@probookcolla 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

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] *** GMX Spamverdacht *** Re: Please someone explain this to me

[Jürgen Hestermann]

Am 2016-02-14 um 12:28 schrieb Michael Van Canneyt:
> There is a difference between learning the language, which implies knowing
> what routines are available to you, and understanding how a particular 
routine works in detail. The latter requires you to study the source code.
> For the former, you don't need the details: the documentation is the better
> alternative.

Here we differ:
I expect that a documentation *fully* explains
a behaviour of a certain function (or something else),
not just some part of it.

It's not neccessary to know *how* things are coded but
the underlying idea and what the programmer can rely on.
The code can even differ from the documenation in case of bugs!
So what does it help to look into the code?

If a documenation satisfies the above requirement then
there is no need to look into the code *in any case*.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Mattias Gaertner]

On Sun, 14 Feb 2016 10:11:54 +0100
Florian Klaempfl  wrote:

>[...]
> 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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Graeme Geldenhuys]

On 2016-02-14 09:35, 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 -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Jürgen Hestermann]

Am 2016-02-13 um 21:59 schrieb Paulo Costa:
> 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

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.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Mattias Gaertner]

On Sun, 14 Feb 2016 10:35:22 +0100
Florian Klaempfl  wrote:

>[...]
> 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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Adrian Veith]

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


Am 14.02.2016 um 10:51 schrieb Adrian Veith:
> 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.
>
>
> Am 13.02.2016 um 11:44 schrieb Serguei TARASSOV:
>> 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
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Michael Van Canneyt]

On Sun, 14 Feb 2016, Florian Klaempfl wrote:


Am 14.02.2016 um 10:45 schrieb Mattias Gaertner:

On Sun, 14 Feb 2016 10:35:22 +0100
Florian Klaempfl  wrote:


[...]
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.


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.


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.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal