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
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 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
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
> 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
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:
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
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 Klaemp
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
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
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
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
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,
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
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
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
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
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
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
__
Am 2016-02-14 um 12:28 schrieb Michael Van Canneyt:
> There is a difference between learning the language, which implies knowing
> what routines are available to you, and understanding how a particular
routine works in detail. The latter requires you to study the source code.
> For the former, yo
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
On Sun, 14 Feb 2016, Jürgen Hestermann wrote:
Am 2016-02-11 um 14:21 schrieb Sven Barth:
If they are just learning the language then they shouldn't poke around in
the core units anyway. That's what the documentation and help is for.
Back when I started learning TP I didn't have the internet
Am 2016-02-11 um 14:21 schrieb Sven Barth:
> If they are just learning the language then they shouldn't poke around in the
core units anyway. That's what the documentation and help is for.
> Back when I started learning TP I didn't have the internet and I didn't have
the sources of the units. I
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:
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
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
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
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
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
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.
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
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
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..
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
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
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
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
37 matches
Mail list logo
