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