Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2016-02

Re: Happy tickets benchmark

5 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Serguei TARASSOV
Show quoted text 29 lines
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, 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: >> >> >> >>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

Reply by email

Michael Van Canneyt
to Serguei TARASSOV
Serguei TARASSOV wrote 16 lines
>> 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.

Reply by email

Adrian Veith
to Serguei TARASSOV: Sounds like the real-life programs don't use inner loops or don't solve NP-complete…

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.

Serguei TARASSOV wrote 46 lines
On 16/02/2016 12:00, 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, 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: >>> >> >>> >>> >>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 - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply by email

Mark Morgan Lloyd
to Serguei TARASSOV: Sounds like the real-life programs don't use inner loops or don't solve NP-complete…
Serguei TARASSOV wrote 21 lines
>>> >>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]

Reply by email

Paulo Costa
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote
Serguei TARASSOV wrote:

...

Show quoted text 11 lines
> 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

Reply by email