Happy tickets benchmark

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Graeme Geldenhuys-6
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Adrian Veith-2
In reply to this post by Adrian Veith-2
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  -  [hidden email]
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Florian Klämpfl
In reply to this post by Graeme Geldenhuys-6
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Graeme Geldenhuys-6
In reply to this post by Graeme Geldenhuys-6
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
[hidden email]:/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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Graeme Geldenhuys-6
In reply to this post by Florian Klämpfl
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Michael Van Canneyt
In reply to this post by Florian Klämpfl


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 <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Jürgen Hestermann
In reply to this post by Paulo Costa-2
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Giuliano Colla
In reply to this post by Florian Klämpfl
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.0000 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Giuliano Colla
In reply to this post by Graeme Geldenhuys-6
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Florian Klämpfl
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Giuliano Colla
In reply to this post by Adrian Veith-2
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Serguei TARASSOV
In reply to this post by Serguei TARASSOV
On 14/02/2016 12:57, [hidden email] wrote:

> Date: Sun, 14 Feb 2016 12:09:42 +0100 (CET) From: Michael Van Canneyt
> <[hidden email]> To: FPC-Pascal users discussions
> <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Graeme Geldenhuys-6
In reply to this post by Michael Van Canneyt
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Florian Klämpfl
In reply to this post by Serguei TARASSOV
Am 14.02.2016 um 13:34 schrieb Serguei TARASSOV:

> On 14/02/2016 12:57, [hidden email] wrote:
>> Date: Sun, 14 Feb 2016 12:09:42 +0100 (CET) From: Michael Van Canneyt <[hidden email]> To:
>> FPC-Pascal users discussions <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Martin Friebe
In reply to this post by Florian Klämpfl
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Martin Friebe
In reply to this post by Florian Klämpfl
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, [hidden email] 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Marco van de Voort
In reply to this post by Florian Klämpfl
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

Marco van de Voort
In reply to this post by Graeme Geldenhuys-6
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Happy tickets benchmark

vojtech.cihak
In reply to this post by Florian Klämpfl

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 <[hidden email]>
> Komu: "FPC-Pascal users discussions" <[hidden email]>
> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234