Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 th

Re: [fpc-pascal] Happy tickets benchmark

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 int

Re: [fpc-pascal] Happy tickets benchmark

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 Li

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 capaci

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

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? > For info, simple loop test like > > while i < 10 do > i := i + 1; > > shows that t

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

Re: [fpc-pascal] Happy tickets benchmark

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

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

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 >

Re: [fpc-pascal] Happy tickets benchmark

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 progra

Re: [fpc-pascal] Happy tickets benchmark

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: &g

Re: [fpc-pascal] Happy tickets benchmark

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 fast

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 ne

Re: [fpc-pascal] Happy tickets benchmark

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,

Re: [fpc-pascal] Happy tickets benchmark

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

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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:

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 commi

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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:

Re: [fpc-pascal] Happy tickets benchmark

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 co

Re: [fpc-pascal] Happy tickets benchmark

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.

Re: [fpc-pascal] Happy tickets benchmark

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 de

Re: [fpc-pascal] Happy tickets benchmark

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 en

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 pr

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 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:=somet

Re: [fpc-pascal] Happy tickets benchmark

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 __

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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:

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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.

Re: [fpc-pascal] Happy tickets benchmark

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 wi

Re: [fpc-pascal] Happy tickets benchmark

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 p

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 Window

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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

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

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 wit

Re: [fpc-pascal] Happy tickets benchmark

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

Re: [fpc-pascal] Happy tickets benchmark

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 t

Re: [fpc-pascal] Happy tickets benchmark

] Happy tickets benchmark Hello, Here is my little brute-force test for FPC, C and C# compilers. http://arbinada.com/main/en/node/1532 <http://arbinada.com/main/en/node/1532> The results are not so good with FPC but I cannot use Delphi to compare on Linux. Could anyone make the ser

Re: [fpc-pascal] Happy tickets benchmark

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 4816

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