Re: [fpc-pascal] Happy tickets benchmark

[Serguei TARASSOV]

Jonas Maebe-2 wrote
> 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.

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.




-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724410.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

[Jonas Maebe]

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
___
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]

Jonas Maebe-2 wrote
> 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

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.



-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724406.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

[Jonas Maebe]

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.


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.


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



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%


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
___
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]

Jeppe Johansen-3 wrote
> On 03/02/2016 12:48 AM, vfclists . wrote:
>>
>>
>> On 14 February 2016 at 10:06, Serguei TARASSOV <

> serge@

>  
> >  serge@

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

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% 




-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724403.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

[Jeppe Johansen]

On 03/02/2016 12:48 AM, vfclists . wrote:



On 14 February 2016 at 10:06, Serguei TARASSOV > wrote:


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.



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

Re: [fpc-pascal] Happy tickets benchmark

[vfclists .]

On 14 February 2016 at 10:06, Serguei TARASSOV  wrote:

> 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.
>
>
>
Is there a reason for this, or is it a bug?


-- 
Frank Church

===
http://devblog.brahmancreations.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

[Serguei TARASSOV]

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



-
--
Regards,
Serguei
--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724379.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

[Serguei TARASSOV]

On 19/02/2016 20:20, fpc-pascal-requ...@lists.freepascal.org wrote:
Date: Fri, 19 Feb 2016 11:49:57 -0700 (MST) From: leledumbo 
 To: fpc-pascal@lists.freepascal.org 
Subject: Re: [fpc-pascal] Happy tickets benchmark

>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?
After more than 20 years in software engineering I'm avoiding to use the 
phrases like "real world program" or I put in quotes the word "real" at 
least :)



>For info, simple loop test like
>
>   while i < 10 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#.

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.

It shows that gcc do the same kind of optimization as MSVC (hence I 
didn't include it), but other don't.

See my answer to Jonas for more details.

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

[Serguei TARASSOV]

On 19/02/2016 20:20, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Fri, 19 Feb 2016 14:01:16 +0100
From: Jonas Maebe
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark

Serguei TARASSOV wrote:

>For info, simple loop test like
>
>while i < 10 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#.

If that's really all there is in your program, then the C# compiler
probably replaces that with "i+=10;" (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).
MSVC does (hence I didn't include it) but all previously listed 
compilers don't remove the loop.

The time ratio is about
FPC - 100, Delphi 7, Borland C - 50, C# - 25, MSVC - 0.

So my doubts was about extra-code generation for the loops.

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

[leledumbo]

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

> For info, simple loop test like 
>
>   while i < 10 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#.

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.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724197.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

[Jonas Maebe]

Serguei TARASSOV wrote:

For info, simple loop test like

   while i < 10 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#.


If that's really all there is in your program, then the C# compiler 
probably replaces that with "i+=10;" (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
___
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 17/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Tue, 16 Feb 2016 12:48:31 +0100 (CET)
From: Michael Van Canneyt
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark


I have asked Florian to integrate his patch anyway, he has agreed,
so I imagine it will result in a new -OoNNN switch.

Michael.

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

For info, simple loop test like

  while i < 10 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

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

Re: [fpc-pascal] Happy tickets benchmark [OT]

[Lukasz Sokol]

On 18/02/16 11:15, Serguei TARASSOV wrote:
> On 18/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Wed, 17 Feb 2016 18:55:29 +0100
>> From: Adrian Veith
>> To: FPC-Pascal users discussions
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> 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.
> Not at all, any series against MIN delivers the best value for MIN(result) 
> not for runtime!
> 
Std deviation also matters:
> Ex.
> Prog 1
> Run 1: 130 = 100 + 30
> Run 2: 160 = 100 + 60
> Run 3: 170 = 100 + 70

> Min = 130, Avg = 153
> 
std dev = 17

> Prog 2
> Run 1: 120 = 110 + 10
> Run 2: 150 = 110 + 40
> Run 3: 200 = 110 + 90
> Min = 120, Avg = 157

std dev = 33 

> MIN shows that Prog 2 is faster that is wrong.
> AVG shows that Prog 1 is faster.
> 
Std dev shows that runs of Prog2 have more error 
so its measurements can't be trusted /more/ than Prog1.

The sample also is too small for meaningful statistics ;)

> Regards,
> Serguei

-L.


___
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 18/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Wed, 17 Feb 2016 18:55:29 +0100
From: Adrian Veith
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark

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.
Not at all, any series against MIN delivers the best value for 
MIN(result) not for runtime!


Ex.
Prog 1
Run 1: 130 = 100 + 30
Run 2: 160 = 100 + 60
Run 3: 170 = 100 + 70
Min = 130, Avg = 153

Prog 2
Run 1: 120 = 110 + 10
Run 2: 150 = 110 + 40
Run 3: 200 = 110 + 90
Min = 120, Avg = 157

MIN shows that Prog 2 is faster that is wrong.
AVG shows that Prog 1 is faster.

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]

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.

Am 17.02.2016 um 12:28 schrieb Serguei TARASSOV:
> On 17/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Tue, 16 Feb 2016 14:44:42 +0100
>> From: Adrian Veith
>> To: FPC-Pascal users discussions
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> small remark for your testing series:
>> AVG makes no sense, you should test against MIN  - why ? the measured
>> results are contaminated by other activities on your system, so the
>> fastest result is the most accurate, because there is no way to make a
>> program to run faster, but many ways to make it run slower.
> 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
> ___
> 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

[wkitty42]

On 02/17/2016 06:28 AM, Serguei TARASSOV wrote:

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

small remark for your testing series: AVG makes no sense, you should test
against MIN  - why ? the measured results are contaminated by other
activities on your system, so the fastest result is the most accurate,
because there is no way to make a program to run faster, but many ways to
make it run slower.

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.


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



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.


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 =

--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
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 17/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:

Date: Tue, 16 Feb 2016 14:44:42 +0100
From: Adrian Veith
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark

small remark for your testing series:
AVG makes no sense, you should test against MIN  - why ? the measured
results are contaminated by other activities on your system, so the
fastest result is the most accurate, because there is no way to make a
program to run faster, but many ways to make it run slower.
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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Happy tickets benchmark

[Paulo Costa]

On 16-Feb-16 18:53, Mark Morgan Lloyd wrote:

Serguei TARASSOV wrote:

...

Sounds like the real-life programs don't use inner loops or don't
solve NP-complete problems  :)
For info, my real-life examples are the application server and the DSL
script engine.
So any improvement of quality of FPC's generated code are welcome.


Anybody using a high-level language for real work would be advised to
understand the problem a bit better so that they didn't have to use your
sort of brute-force approach. And at that point, having something that
expresses higher-level algorithms and coding practices (threads, dynamic
arrays) becomes at least as important as brute force efficiency.


I think that the original example should be treated as the code that is 
used to trigger a bug. It must be the simplest possible so the bug can 
be identified and corrected.



... At which
point, pointing out that FPC doesn't have a STEP or BY clause in the FOR
statement would be far more useful criticism.


Depending on the problems that we want to solve, different language 
capabilities become more or less important...


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

Re: [fpc-pascal] Happy tickets benchmark

[Mark Morgan Lloyd]

Serguei TARASSOV wrote:

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

>>use C.

>It's a wrong choice.
>As we can see and reproduce, at least C# or other Pascal-like 
environments

>(Oxygene) are significantly faster.
>http://www.arbinada.com/main/en/node/1532
>
What Florian means is that this is very artificial code, and that - 
although

he has been able to apply the necessary patches to make FPC faster - the
necessary optimizations are not likely to help in real-life programs.

Michael.


Sounds like the real-life programs don't use inner loops or don't solve 
NP-complete problems  :)
For info, my real-life examples are the application server and the DSL 
script engine.

So any improvement of quality of FPC's generated code are welcome.


Anybody using a high-level language for real work would be advised to 
understand the problem a bit better so that they didn't have to use your 
sort of brute-force approach. And at that point, having something that 
expresses higher-level algorithms and coding practices (threads, dynamic 
arrays) becomes at least as important as brute force efficiency.


In the past I've come across people trying to solve recreational 
problems asking (stupid) questions like "would Python be faster than 
FORTRAN", and then having somebody respond that their approach is so 
naive that language choice makes no real difference.


So in the case of your chosen problem: you know whether the left-hand 
sum is even or odd, so a trivial optimisation would be only looking at 
half of the possible values of the final (right-hand) digit. At which 
point, pointing out that FPC doesn't have a STEP or BY clause in the FOR 
statement would be far more useful criticism.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
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]

small remark for your testing series:
AVG makes no sense, you should test against MIN  - why ? the measured
results are contaminated by other activities on your system, so the
fastest result is the most accurate, because there is no way to make a
program to run faster, but many ways to make it run slower.

Am 16.02.2016 um 12:19 schrieb Serguei TARASSOV:
> On 16/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
>> Date: Mon, 15 Feb 2016 13:02:48 +0100 (CET)
>> From: Michael Van Canneyt
>> To: FPC-Pascal users discussions
>> Subject: Re: [fpc-pascal] Happy tickets benchmark
>>
>> On Mon, 15 Feb 2016, Serguei TARASSOV wrote:
>>
>>> >On 15/02/2016 12:00,fpc-pascal-requ...@lists.freepascal.org  wrote:
>>>> >>Date: Mon, 15 Feb 2016 07:55:55 +0100
>>>> >>From: Florian Kl?mpfl
>>>> >>To:, "FPC-Pascal users discussions"
>>>> >>, Adrian Veith
>>>> >>Subject: Re: [fpc-pascal] Happy tickets benchmark
>>>> >>Message-ID:
>>>> >>   
>>>> <152e3b6cc90.27ef.940694a44bcba3a3e493262cc9dc5...@freepascal.org>
>>>> >>Content-Type: text/plain; charset="iso-8859-1"
>>>> >>
>>>> >>Well, as said before: if the speed of code like this is important
>>>> for you,
>>>> >>use C.
>>> >It's a wrong choice.
>>> >As we can see and reproduce, at least C# or other Pascal-like
>>> environments
>>> >(Oxygene) are significantly faster.
>>> >http://www.arbinada.com/main/en/node/1532
>>> >
>> What Florian means is that this is very artificial code, and that -
>> although
>> he has been able to apply the necessary patches to make FPC faster - the
>> necessary optimizations are not likely to help in real-life programs.
>>
>> Michael.
>
> Sounds like the real-life programs don't use inner loops or don't
> solve NP-complete problems  :)
> For info, my real-life examples are the application server and the DSL
> script engine.
> So any improvement of quality of FPC's generated code 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

[Michael Van Canneyt]

On Tue, 16 Feb 2016, Serguei TARASSOV wrote:


environments
>(Oxygene) are significantly faster.
>http://www.arbinada.com/main/en/node/1532
>
What Florian means is that this is very artificial code, and that - 
although

he has been able to apply the necessary patches to make FPC faster - the
necessary optimizations are not likely to help in real-life programs.

Michael.


Sounds like the real-life programs don't use inner loops or don't solve 
NP-complete problems  :)
For info, my real-life examples are the application server and the DSL script 
engine.

So any improvement of quality of FPC's generated code are welcome.


I have asked Florian to integrate his patch anyway, he has agreed, 
so I imagine it will result in a new -OoNNN switch.


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

[Serguei TARASSOV]

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

Date: Mon, 15 Feb 2016 13:02:48 +0100 (CET)
From: Michael Van Canneyt
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] Happy tickets benchmark

On Mon, 15 Feb 2016, Serguei TARASSOV wrote:


>On 15/02/2016 12:00,fpc-pascal-requ...@lists.freepascal.org  wrote:

>>Date: Mon, 15 Feb 2016 07:55:55 +0100
>>From: Florian Kl?mpfl
>>To:, "FPC-Pascal users discussions"
>>        , Adrian Veith
>>Subject: Re: [fpc-pascal] Happy tickets benchmark
>>Message-ID:
>><152e3b6cc90.27ef.940694a44bcba3a3e493262cc9dc5...@freepascal.org>
>>Content-Type: text/plain; charset="iso-8859-1"
>>
>>Well, as said before: if the speed of code like this is important for you,
>>use C.

>It's a wrong choice.
>As we can see and reproduce, at least C# or other Pascal-like environments
>(Oxygene) are significantly faster.
>http://www.arbinada.com/main/en/node/1532
>

What Florian means is that this is very artificial code, and that - although
he has been able to apply the necessary patches to make FPC faster - the
necessary optimizations are not likely to help in real-life programs.

Michael.


Sounds like the real-life programs don't use inner loops or don't solve 
NP-complete problems  :)
For info, my real-life examples are the application server and the DSL 
script engine.

So any improvement of quality of FPC's generated code are welcome.

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

[Dmitry Boyarintsev]

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

> Maybe documentation helps here.
>
> Is there already a page "pimp my fpc"?
>

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

But the information is a bit outdated.

thanks,
Dmitry
___
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 Mon, 15 Feb 2016, Serguei TARASSOV wrote:


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

Date: Mon, 15 Feb 2016 07:55:55 +0100
From: Florian Kl?mpfl
To:, "FPC-Pascal users discussions"
, Adrian Veith
Subject: Re: [fpc-pascal] Happy tickets benchmark
Message-ID:
<152e3b6cc90.27ef.940694a44bcba3a3e493262cc9dc5...@freepascal.org>
Content-Type: text/plain; charset="iso-8859-1"

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

It's a wrong choice.
As we can see and reproduce, at least C# or other Pascal-like environments 
(Oxygene) are significantly faster.

http://www.arbinada.com/main/en/node/1532



What Florian means is that this is very artificial code, and that - although
he has been able to apply the necessary patches to make FPC faster - the
necessary optimizations are not likely to help in real-life programs.

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

[Serguei TARASSOV]

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

Date: Mon, 15 Feb 2016 07:55:55 +0100
From: Florian Kl?mpfl
To:, "FPC-Pascal users discussions"
, Adrian Veith
Subject: Re: [fpc-pascal] Happy tickets benchmark
Message-ID:
<152e3b6cc90.27ef.940694a44bcba3a3e493262cc9dc5...@freepascal.org>
Content-Type: text/plain; charset="iso-8859-1"

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

It's a wrong choice.
As we can see and reproduce, at least C# or other Pascal-like 
environments (Oxygene) are significantly faster.

http://www.arbinada.com/main/en/node/1532

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]

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


Am 15. Februar 2016 7:24:29 vorm. schrieb 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
>


___
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]

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

[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

[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

[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

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

[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

[Marco van de Voort]

In our previous episode, Florian Klaempfl said:
> 
> 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 :)

I took one look at the used benchmark, and skipped the whole thread. Too
synthetic.
___
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

[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

[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

[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

[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, not the 
programmer's intelligence.

You should remove inner loop from C and C# code to get a meaningful result.

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

[Giuliano Colla]

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:
[colla@probookcolla SandBox]$ for foo in 0 1 2 3 4 5 6 7 8 9; do 
./HappyTickets_florian; done;

Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 19
Found 4816030 tickets. Elapsed time, msec: 23
Found 4816030 tickets. Elapsed time, msec: 17
Found 4816030 tickets. Elapsed time, msec: 18
Found 4816030 tickets. Elapsed time, msec: 17
Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 16
Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 20

range = 16-23 - average= 19.0 ms

Inside a procedure:
[colla@probookcolla SandBox]$ for foo in 0 1 2 3 4 5 6 7 8 9; do 
./HappyTickets_florian; done;

Found 4816030 tickets. Elapsed time, msec: 24
Found 4816030 tickets. Elapsed time, msec: 21
Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 19
Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 18
Found 4816030 tickets. Elapsed time, msec: 17
Found 4816030 tickets. Elapsed time, msec: 19
Found 4816030 tickets. Elapsed time, msec: 20
Found 4816030 tickets. Elapsed time, msec: 19

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

Giuliano

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

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

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.

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


___
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] 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

[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

Re: [fpc-pascal] Happy tickets benchmark

[Graeme Geldenhuys]

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


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

[Graeme Geldenhuys]

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

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

root@graeme-desktop:/tmp # uname -a
FreeBSD graeme-desktop 10.1-RELEASE-p16 FreeBSD 10.1-RELEASE-p16 #0: Tue
Jul 28 12:04:19 UTC 2015
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root@graeme-desktop:/tmp # /sbin/sysctl hw.physmem
hw.physmem: 34261151744  (32GB)


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 14.02.2016 um 11:12 schrieb Graeme Geldenhuys:
> 
> 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.

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

___
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

[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

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

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

[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

[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

[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

[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] Happy tickets benchmark

[wkitty42]

On 02/13/2016 04:21 PM, 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

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

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

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

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

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

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

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

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

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

real0m0.298s
user0m0.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

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

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

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

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

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

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

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

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

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

real0m0.251s
user0m0.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

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

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

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

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

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

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

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

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

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

real0m0.292s
user0m0.290s
sys 0m0.000s
= end =


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.
___
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]

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);
0046DB18 4883c001                 add    $0x1,%rax
unit1.pas:36                              TicketsCount+=1;
0046DB1C 488d4001                 lea    0x1(%rax),%rax
unit1.pas:37                              TicketsCount:=TicketsCount+1;
0046DB20 488d5801                 lea    0x1(%rax),%rbx
__

Od: Paulo Costa 
Komu: 
Datum: 13.02.2016 22:00
Předmět: Re: [fpc-pascal] Happy tickets benchmark


On 13-Feb-16 10:44, 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
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 
<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

[Paulo Costa]

On 13-Feb-16 10:44, 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
___
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]

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

Od: leledumbo 
Komu: 
Datum: 13.02.2016 18:43
Předmět: Re: [fpc-pascal] Happy tickets benchmark


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.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724116.html
 
<http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724116.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 
<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]

Damn, nabble doesn't like the double file extension :(
Reuploaded:
FPC:  test.pas_s
  
GCC:  test.gcc_s
  
Clang:  test.clang_s
  




--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724117.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

[leledumbo]

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

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

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

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

real0m0.267s
user0m0.260s
sys 0m0.003s

Below is the produced assembly from fpc, gcc and clang (no idea how to get
one for mono):
test.s
  
test.s
  
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.



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724116.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

[leledumbo]

> Stripped binary size: 
> MSElang5.5KB 
> FPC 3.0   21.6KB 
> gcc 4.8.1  5.5KB

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



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Happy-tickets-benchmark-tp5724109p5724115.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

[Michael Van Canneyt]

On Sat, 13 Feb 2016, Martin Schreiber wrote:


time ./testgcc.bin
Found 4816030 tickets.
real0m1.649s
user0m1.645s
sys 0m0.002s
"
Stripped binary size:
MSElang5.5KB
FPC 3.0   21.6KB
gcc 4.8.1  5.5KB

Linux x86, AMD Athlon 4000+ 1GHz


No surprises there, you are comparing FPC with llvm.

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

[Martin Schreiber]

On Saturday 13 February 2016 11:44:27 Serguei TARASSOV wrote:
> Hello,
>
> Here is my little brute-force test for FPC, C and C# compilers.
> http://arbinada.com/main/en/node/1532
>

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

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

real0m5.576s
user0m5.572s
sys 0m0.002s
"
gcc 4.8.1 -O3:
"
time ./testgcc.bin
Found 4816030 tickets.
real0m1.649s
user0m1.645s
sys 0m0.002s
"
Stripped binary size:
MSElang5.5KB
FPC 3.0   21.6KB
gcc 4.8.1  5.5KB

Linux x86, AMD Athlon 4000+ 1GHz

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

Re: [fpc-pascal] Happy tickets benchmark

[silvioprog]

On Sat, Feb 13, 2016 at 8:36 AM, Vojtěch Čihák 
wrote:

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

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

-- 
Silvio Clécio
___
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]

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

Od: Serguei TARASSOV 
Komu: 
Datum: 13.02.2016 11:44
Předmět: [fpc-pascal] Happy tickets benchmark


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

[silvioprog]

On Sat, Feb 13, 2016 at 7:44 AM, Serguei TARASSOV 
wrote:

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

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


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


Delphi on Linux, how? o_O

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