Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sunday 17 March 2013 21:44:02 Florian Klaempfl wrote: Am 06.03.2013 14:16, schrieb Martin Schreiber: On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3 A last one, simple MSEgui demo, one form, a fancy tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo FPC 2.6.2, commandline: ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo Without the used sources it is of very little use. Because of the tone of the answers in this list I didn't expect anyone is interested in it. ;-) http://gitorious.org/mseuniverse/mseuniverse/trees/master/testcase/kylix/kylixdemo Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 06.03.2013 14:16, schrieb Martin Schreiber: On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3 A last one, simple MSEgui demo, one form, a fancy tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo FPC 2.6.2, commandline: ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo Without the used sources it is of very little use. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 09 Mar 2013, at 23:46, Vittorio Giovara wrote: Slightly off topic: http://www.utf8everywhere.org/ Seriously, drop UTF16 support NOW. No, that's very off-topic. Please don't start discussions like that here, they don't lead to any useful outcome. Jonas FPC mailing lists admin___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Van: Vittorio Giovara vittorio.giov...@gmail.com On 04/mar/2013, at 16:57, luiz americo pereira camara luiz...@oi.com.br wrote: Personally, i don't care much about compilation speed since is faster enough (at least for me). I'm more interested in better generated code. This is were i'd like to see the efforts going. Sorry for the +1 style mail but I just wanted to say that completely agree with your statement! Compilation speed is nice, but better code (size/speed) is... better! as a bonus, when the code that is output performs faster, so will the compiler itself after the recursive build. or one would think so :-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 15:02, Michael Van Canneyt mich...@freepascal.org wrote: On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. Slightly off topic: http://www.utf8everywhere.org/ Seriously, drop UTF16 support NOW. Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 16:57, luiz americo pereira camara luiz...@oi.com.br wrote: Personally, i don't care much about compilation speed since is faster enough (at least for me). I'm more interested in better generated code. This is were i'd like to see the efforts going. Luiz Sorry for the +1 style mail but I just wanted to say that completely agree with your statement! Compilation speed is nice, but better code (size/speed) is... better! Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04 Mar 2013, at 13:38, Daniël Mantione wrote: 2. Layered code generation The split of the code generation in a high-level and low-level layer, means that for every node that is processed, first the high-level virtual method is called, which in turn calls the lower level virtual method. Thus you have an addition virtual method call for evey node processed. The low level code generator, which is still mostly CPU independent, again calls virtual methods from the abstract assembler layer to generate the actual opcodes. The abstract assembler in turn, has again to worry about multiple assemblers which can emit the final object file. Note that the release compilers are compiled with WPO and those optimizations change most of those virtual calls into static calls. Not all of them, but e.g. the entire code generator (both high and low level) does get devirtualized for most platforms (except for ARM, because it contains multiple low level code generators). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Sun, 3 Mar 2013, schreef Marcos Douglas: On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Sad. Instead of fight, why not walking together? IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. Martin: I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You are only showing the Delphi/Kylix speed is extremely superior (even knowing that Delphi do not is multiplataform and do not have the complexity that FPC has, AFAIK). One more thing: try do not thinking only in MSEgui in your thoughts, in your great ideas. IMHO the MSEgui should be part of FPC, somehow, but... FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. That FPC is slower than Delphi is a result of many concious decisions: * FPC has a lot of passes through the node tree - allows more features and transformations * FPC has a more layered code generation (hlcg, cg, cpu specific overrides) - allows manu CPU architectures, JVM and more * FPC has an advanced register allocator. Allows speedy code and many CPU architectures. * FPC has external debug information. Due its nature, this debug info requires processing power. As these are concious decisions, there is no quick fix. This doesn't mean no attention has been made to the compiler speed, many efforts have been put into profiling and optimizing the algorithms. For the rest, one has to accept FPC as it is. If FPC was inferior to Delphi, we would not have had this discussion. Further, global bennchmarks of my million line program takes long to compile are not helpfull at all in diagnosing performance problems. (Or bugs, or other issues). Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Graeme Geldenhuys wrote: On 2013-03-03 23:21, Marcos Douglas wrote: Sad. Instead of fight, why not walking together? I'm not joining any fight, simply wanted to know what the 'm' stood for. I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You said it yourself... most of us know nothing about compiler coding. So how are we supposed to propose improvements! All we can do is file bug reports on things we can duplicate, or highlight issues. This is what Martin is doing here. 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. While I tend to agree in general, you would be surprised at the impact it has. I tossed an idea to the core group to speed up PPU loading, and it was immediatly torpedoed on solid technical grounds. The cross-platform argument is not easily circumvented. Could be that I disclosed another reason why Delphi remains intel-only for development :) Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 12:35 AM, Marcos Douglas m...@delfire.net wrote: On Sun, Mar 3, 2013 at 8:29 PM, Vittorio Giovara vittorio.giov...@gmail.com wrote: On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote: [cut] FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. I am no fpc dev here, but patches are welcome I guess. That's what I meant when I spoke he is making a mistake in their approach of how to present FPC's defects. What defects exactly? I just see random data dumped on the mailing list, data produced from a random project using random compiler switches... Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) jm2c Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
In our previous episode, Graeme Geldenhuys said: On 2013-03-03 19:47, Florian Kl?mpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) And if miles, what miles? In this case I would take the Scandinavian Mile, and skip next years marathon too: http://en.wikipedia.org/wiki/Scandinavian_mile ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 9:26 AM, Vittorio Giovara vittorio.giov...@gmail.com wrote: Don't use fpc if you don't like it, or send patches to improve it ;) http://programmers.stackexchange.com/questions/68740/whats-the-canonical-retort-to-its-open-source-submit-a-patch ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 09:26:53 Vittorio Giovara wrote: Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) You probably might know, I am the author of MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui/ In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete real world example. I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-) Please read the MSEide-MSEgui mailing list archive in order to check how things are handled in MSEgui. http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ With the MSEide Delphi/Kylix/FPC comparison I provide a real world testcase which the FPC team can use to improve their product. If the FPC team don't want to do so or think it is not necessary or it is no fun then I have to accept it and I will accept it. But from time to time I will repeat the comparison in order the facts will not get forgotten. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Martin Schreiber wrote: On Monday 04 March 2013 09:26:53 Vittorio Giovara wrote: Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) You probably might know, I am the author of MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui/ In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete real world example. I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-) Given your reputation, I suppose patches from you will not suffer from this problem. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Martin Schreiber: In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete real world example. I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-) Understood. What if your users submit issues that are fundamental to your UTF16-decision? For example shortstrings would be more compact and faster. I suspect you are not going to change MSEIDE to another approach. It's the same here. Compiler speed is lower than Delphi due to design decisions, that cannot be easily altered. Optimization is always possible, but the low hanging fruit is gone, because as said, extensive time has already been spent into compiler speed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 01:16, Marcos Douglas wrote: I know. I just used the last mail on this thread -- in that case, your mail. Sorry. You should know better, and to never use any of my replies for something like that. I have no patience or sense of humour. ;-) Yes, I agree... but I feel a fight between Martin and FPC Team, don't you agree? No, and I don't desire it either. I feel the same... but we can not force people who work for free to do tasks that are not important to them. Correct. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Let me name some of the stuff which might count only 10% each (some more, some less) but in total makes FPC much slower: - gcc compatible output format (*.ppu+*.o instead of one big ppu only usable with FPC) - flexible assembler output (different assemblers supported, assembler listing output) - flexible object file output (coff, elf, ...) - portable ppus (regardless of the host system, ppus are bitwise equal. this means e.g. a lot of endian conversion checks and calls) - class helpers - operator overloading - generics - architecture agnostic node tree - architecture agnostic constant handling (96 bit arithmetics) - portable code generator - support of bit packed data structures - flexible debugging info output - completely written in a high level language - architecture agnostic symtable handling - using the rtl heap manager, a non threadsafe heap manager would be probably slightly faster but do we want to maintain two full featured heap managers? - using ansistrings, one could switch to zero passed char arrays but do we really want this? - architecture agnostic handling of procedure parameter passing - code page aware reading of input files - different FPU types supported - portable optimizer - 32/64 bit assembler supporting all available instruction sets - high level code generator layer for jvm support - support of different pascal dialects - portable and flexible file handling - using classes instead of objects - ... And yes, the speed penalty of these features/properties often multiplies and is not only additive. Of course, this is all simplified but it should give you an idea where the factor 10 comes from. It is a lot of small things none of them really counting but in total it's a lot (exponential grow) and this makes it impossible to fix this without sacrifying a lot of FPC's power. FYI: FPC 1.x is several times faster than FPC 2.x FYI2: Last time somebody tried (years ago, -/+ year 2000), FPC compiled by Delphi was slower than FPC compiled by FPC. My goal regarding the speed of FPC is: let Moore win. This means faster CPUs should make FPC faster than new features in FPC make FPC slower and this works for 20 years now. So nothing to worry. You are only showing the Delphi/Kylix speed is extremely superior And Martin is just showing half the problem. The Delphi Kylix compilers also produce executables that run 10+ times faster than what FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And don't even think of mentioning that faster hardware will mask the problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high performance RAM and 450MB read speed SSD. I noticed a 10+ times difference in running executables on my hardware. Then something with your code is wrong. Or you hit some strange bottleneck, you should really profile your code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 10:25 AM, Kostas Michalopoulos badsectorac...@gmail.com wrote: On Mon, Mar 4, 2013 at 9:26 AM, Vittorio Giovara vittorio.giov...@gmail.com wrote: Don't use fpc if you don't like it, or send patches to improve it ;) http://programmers.stackexchange.com/questions/68740/whats-the-canonical-retort-to-its-open-source-submit-a-patch Nice link, but I find this more appropriate: http://lmgtfy.com/?q=how+to+benchmark+compilers Related, abeit exploited http://tvtropes.org/pmwiki/pmwiki.php/Main/Troll ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, Mar 4, 2013 at 5:26 AM, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Mon, Mar 4, 2013 at 12:35 AM, Marcos Douglas m...@delfire.net wrote: On Sun, Mar 3, 2013 at 8:29 PM, Vittorio Giovara vittorio.giov...@gmail.com wrote: On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote: [cut] FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. I am no fpc dev here, but patches are welcome I guess. That's what I meant when I spoke he is making a mistake in their approach of how to present FPC's defects. What defects exactly? I just see random data dumped on the mailing list, data produced from a random project using random compiler switches... Did you see the ...? I do not consider defects too... Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) I agree. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 13:22:11 +0100 Martin Schreiber mse00...@gmail.com wrote: [...] You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) Or it means you have 50 combinable features, so 2^50 = 1 quadrillion possibilities. ;) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 12:05, schrieb Florian Klämpfl: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Let me name some of the stuff which might count only 10% each (some more, some less) but in total makes FPC much slower: - class helpers - generics These two should not result in much slowdowns if not used. Especially for helpers I've taken care of it. Though I admit that there is room for improvement for generics (but I already have ideas for that :) ) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Martin Schreiber: On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) Some features only request procesing power if you use them. However, the features in Florian's list require continuous processing power. Two examples how features can impact overall speed: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. 2. Layered code generation The split of the code generation in a high-level and low-level layer, means that for every node that is processed, first the high-level virtual method is called, which in turn calls the lower level virtual method. Thus you have an addition virtual method call for evey node processed. The low level code generator, which is still mostly CPU independent, again calls virtual methods from the abstract assembler layer to generate the actual opcodes. The abstract assembler in turn, has again to worry about multiple assemblers which can emit the final object file. Now each layer not just has its own code, but also its own type and therefore conversion functions need to be called (for example a def has a size), which is converted into a cgsize and ultimately into an opsize. Obviously, if you just had one layer, and could output instruction directly to the object file, you can save a lot of performance. While you might develop for just one platform, the fact that many of them are supported, costs compiler performance. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 13:38, schrieb Daniël Mantione: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Sven Barth wrote: Am 04.03.2013 13:38, schrieb Daniël Mantione: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further. That seems simple enough to implement and test ? Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 13:38:50 +0100 (CET) Daniël Mantione daniel.manti...@freepascal.org wrote: [...] Some features only request procesing power if you use them. However, the features in Florian's list require continuous processing power. Two examples how features can impact overall speed: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. Can this be cached? Maybe the compiler can reuse some results? So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
In our previous episode, Mattias Gaertner said: are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. From what I understand of pascal parsing: You need the implementation highest in the scope stack. all doesn't help, and they can also be implemented in the unit (or even local?) scope. One would need to build the cache lazily (on first access in a scope), and somehow avoid rebuilding too often if the scope changes. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. Can this be cached? Maybe the compiler can reuse some results? No I think not. The context to be checked is probably too large/complex. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner: Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. Actually a cache was part of my symtable redesign years ago. It never made it into the compiler. But it was designed with a slightly different idea in mind: If you do a symtable lookup you can have many symtables to process: - With statement - Local variables - Parameters - Object symtables, one per inherited object - Unit symtables, two per loaded unit (interface implementation) The idea was to remove this lineair search through all symtables. The concept never made it in the final compiler. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 13:46, schrieb Michael Van Canneyt: On Mon, 4 Mar 2013, Sven Barth wrote: Am 04.03.2013 13:38, schrieb Daniël Mantione: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further. That seems simple enough to implement and test ? Yes, maybe I'll give it a try in the next couple days (if no one beats me :) ). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 14:28, schrieb Daniël Mantione: Op Mon, 4 Mar 2013, schreef Mattias Gaertner: Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. Actually a cache was part of my symtable redesign years ago. It never made it into the compiler. But it was designed with a slightly different idea in mind: If you do a symtable lookup you can have many symtables to process: - With statement - Local variables - Parameters - Object symtables, one per inherited object - Unit symtables, two per loaded unit (interface implementation) The idea was to remove this lineair search through all symtables. The concept never made it in the final compiler. Did you work out the concept somewhere? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner: Can this be cached? Maybe the compiler can reuse some results? No. The symtable lookups can be parsed, but the candidate selection, which I believe is actually more compute intensive, is dependend on the actual situation where the operator is called, for example the types of the left and right part, which would not yield very high hit rates. Originally the compiler was doing the candidate selection with a simple loop through the parameters that took the first suitable match. When the type conversion matters became more complex the Unable to determine overloaded procedure error became increasingle annoying. At some point I did redesign it with scoring system: Each candidate that is compatible gets assigned a score how well the overloaded procedure matches the parameters. The best match is selected. At that point, the compiler became highly intelligent in finding the correct overloaded procedure/operator, but the amount of computing power involved with overloading went up: Instead of selecting the first candidate, we need to compute the score for all candidates. This even requires floating point arithmetic. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Sven Barth: Did you work out the concept somewhere? It quite likely there is some archived copy of it in the old CVS repository, but I am sure it's better to start from scratch. The compiler was still using objects at that time, for example. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 14:18:09 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: In our previous episode, Mattias Gaertner said: are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. From what I understand of pascal parsing: You need the implementation highest in the scope stack. all doesn't help, and they can also be implemented in the unit (or even local?) scope. Yes, the compiler has to search first local and inherited scopes, which need all kind of special rules, so caching might not help here. But after searching the special scopes the compiler has to search the interface sections of all used units. And these results should be the same for the whole implementation section. So it sounds like a good candidate for caching. One would need to build the cache lazily (on first access in a scope), and somehow avoid rebuilding too often if the scope changes. Yes. Or make the cache not too specific. For example just cache the list of all operator overloads. The compiler still has to check each operator, but it does not have to search all symtables to gather all operators. Or it can cache what operator does not have any overloads at all and can simply use the default. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. Can this be cached? Maybe the compiler can reuse some results? No I think not. The context to be checked is probably too large/complex. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Martin Schreiber wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Thanks for sharing some good news as well :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 14:48, schrieb Marco van de Voort: In our previous episode, Martin Schreiber said: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Speculation on the reasons: macosall is mostly a header (declarations), while the other programs probably have a higher code % ? What does the content of MacOSAll have to do with being mostly declarations? Martin just wrote that he used differently compiled MSEides to highlight the same unit (though I wonder why the FPC Linux variant is the slowest...) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 14:57, schrieb Martin Schreiber: On Monday 04 March 2013 14:37:40 Daniël Mantione wrote: Originally the compiler was doing the candidate selection with a simple loop through the parameters that took the first suitable match. When the type conversion matters became more complex the Unable to determine overloaded procedure error became increasingle annoying. At some point I did redesign it with scoring system: Each candidate that is compatible gets assigned a score how well the overloaded procedure matches the parameters. The best match is selected. At that point, the compiler became highly intelligent in finding the correct overloaded procedure/operator, but the amount of computing power involved with overloading went up: Instead of selecting the first candidate, we need to compute the score for all candidates. This even requires floating point arithmetic. This improvement is very visible. I had big problems to make MSEide Delphi compatible because Delphi many times reported Unable to determine overloaded procedure where FPC has no problems. I think this is worth a slow down of compile time. :-) Can we have this statement printed out and signed by you, please :D Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
On Mon, 4 Mar 2013 14:37:40 +0100 (CET)
Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
Can this be cached?
Maybe the compiler can reuse some results?
No. The symtable lookups can be parsed, but the candidate selection, which
I believe is actually more compute intensive, is dependend on the actual
situation where the operator is called, for example the types of the left
and right part, which would not yield very high hit rates.
Why not?
I guess that a high percentage are only a few type,operator,type
combinations.
interface
function substring(x,y:unicodestring):cardinal;
function substring(x,y:ansistring):cardinal;
function substring(x,y:shortstring):cardinal;
implementation
{...}
var a:unicodestring;
b,c:ansistring;;
begin
a:='banana-split';
b:='banana-split';
c:='banana';
writeln(substring('banana','banana-split'));
writeln(substring(b,a));
writeln(substring(a,a));
end.
... we would have 3 cache lookups, and 3 misses. Then we have end of
scope, the symtablestack changes, and we therefore have to invalidate the
cache. In this example, a cache would therefore slowdown instead of
speed-up.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. Another source of slow-down may be file search: Windows ignores case. Linux does not - depending on what you do, you need to search 3 times more files. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, March 4, 2013 14:54, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Is the starting MSEide (as mentioned above) bit included in the measured time? That would probably imply quite some OS calls, of course... Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 15:02:34 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. MacOSAll.pas is 8-bit. On both systems MSEIDE has to convert it to UCS-2 (afair not UTF-16). Do you mean MSEIDE uses the Widestring manager functions to compare tokens? Another source of slow-down may be file search: Windows ignores case. Linux does not - depending on what you do, you need to search 3 times more files. Yes, but Windows is easily 10 times slower on file stat functions. I had to add several caches into Lazarus, because of this. Some functions were hardly measurable under Linux, but took a minute under Windows. And this is completely irrelevant for loading a single file. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
In our previous episode, Sven Barth said: widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Speculation on the reasons: macosall is mostly a header (declarations), while the other programs probably have a higher code % ? What does the content of MacOSAll have to do with being mostly declarations? Martin just wrote that he used differently compiled MSEides to highlight the same unit (though I wonder why the FPC Linux variant is the slowest...) Yes, I took it as those compilers compiling, not as compiled loading and highlighting. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
In our previous episode, Michael Van Canneyt said: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. Another source of slow-down may be file search: Windows ignores case. Linux does not - depending on what you do, you need to search 3 times more files. Or more codegenerating related, PIC costs a register? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 15:00:30 +0100 (CET)
Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
On Mon, 4 Mar 2013 14:37:40 +0100 (CET)
Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
Can this be cached?
Maybe the compiler can reuse some results?
No. The symtable lookups can be parsed, but the candidate selection, which
I believe is actually more compute intensive, is dependend on the actual
situation where the operator is called, for example the types of the left
and right part, which would not yield very high hit rates.
Why not?
I guess that a high percentage are only a few type,operator,type
combinations.
interface
function substring(x,y:unicodestring):cardinal;
function substring(x,y:ansistring):cardinal;
function substring(x,y:shortstring):cardinal;
implementation
{...}
var a:unicodestring;
b,c:ansistring;;
begin
a:='banana-split';
b:='banana-split';
c:='banana';
writeln(substring('banana','banana-split'));
writeln(substring(b,a));
writeln(substring(a,a));
end.
... we would have 3 cache lookups, and 3 misses. Then we have end of
scope, the symtablestack changes, and we therefore have to invalidate the
cache. In this example, a cache would therefore slowdown instead of
speed-up.
Yes, that's one of the reasons why I disabled the cache in codetools for
procedure overloads.
But I was talking about operator overloads. AFAIK there far less
operator overloads. And if a unit uses operator
overloads, then usually only a few, but many times.
I guess many units do not use overloaded operators at all.
Is it possible to measure how much time the compiler spends on
searching overloaded operators?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 12:44, Sven Barth wrote: that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the See, so Martin posting performance results after every FPC release does pay off. Without his post, your proposal would probably not have happened. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 15:02:34 +0100 (CET) Michael Van Canneyt mich...@freepascal.org wrote: On Mon, 4 Mar 2013, Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Codepage conversions, most likely: Martin uses UTF-16 everywhere. On Windows, FPC uses the native support for UTF-16. Not exactly sure what happens on Linux. MacOSAll.pas is 8-bit. On both systems MSEIDE has to convert it to UCS-2 (afair not UTF-16). Do you mean MSEIDE uses the Widestring manager functions to compare tokens? No idea. I am simply proposing possible causes while waiting for my testsuites to finish :-) The only way to actually know is to measure all various factors: Evidence-based acting... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 14:31, schrieb Sven Barth: Am 04.03.2013 13:46, schrieb Michael Van Canneyt: On Mon, 4 Mar 2013, Sven Barth wrote: Am 04.03.2013 13:38, schrieb Daniël Mantione: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further. That seems simple enough to implement and test ? Yes, maybe I'll give it a try in the next couple days (if no one beats me :) ). It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads. It's also interesting to see that not every unit triggers a search for operators... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 16:16, schrieb Sven Barth: Am 04.03.2013 14:31, schrieb Sven Barth: Am 04.03.2013 13:46, schrieb Michael Van Canneyt: On Mon, 4 Mar 2013, Sven Barth wrote: Am 04.03.2013 13:38, schrieb Daniël Mantione: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. Maybe we can improve this situation. For class helpers I added the possibility to add flags to symtables (so that only units are checked that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the symtable of e.g. advanced records up to the unit symtable when parsing the record's declaration). As most units don't declare operators this could result in a little speedup especially considering that the lookup is done on each operator... and then we might add some caching structures to improve this further. That seems simple enough to implement and test ? Yes, maybe I'll give it a try in the next couple days (if no one beats me :) ). It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads. It's also interesting to see that not every unit triggers a search for operators... And compiling with 2.6.0 is around 0.1 to 0.3 seconds faster. And before I forget it: Platform is i386-win32. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Sven Barth: It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads. It's also interesting to see that not every unit triggers a search for operators... So this is +/- 2%? Not bad. This fits perfectly into what Florian did explain: Each of the features adds just a bit of compile time. There is no quick solution to make FPC much faster. But each optimization can help a bit. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 15:33, schrieb Mattias Gaertner: But I was talking about operator overloads. AFAIK there far less operator overloads. And if a unit uses operator overloads, then usually only a few, but many times. I guess many units do not use overloaded operators at all. Is it possible to measure how much time the compiler spends on searching overloaded operators? Probably little but this is exactly my point: there are a dozens of such small slow downs. None of them really significant, overall they add up and most can be improved only with some bug and error prone hacks not worth the effort compared with other stuff on the todo lists. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 15:40, schrieb Graeme Geldenhuys: On 2013-03-04 12:44, Sven Barth wrote: that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the See, so Martin posting performance results after every FPC release does pay off. Without his post, your proposal would probably not have happened. ;-) You can see it the other way round: Sven might now spend a significant amount of time in a bug prone micro optimization of the compiler shaving off maybe 1% compilation time while he could do something else where a lot more users benefit like improving the register allocator or fixing unicode string issues. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 16:38, schrieb Daniël Mantione: Op Mon, 4 Mar 2013, schreef Sven Barth: It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads. It's also interesting to see that not every unit triggers a search for operators... So this is +/- 2%? Not bad. This fits perfectly into what Florian did explain: Each of the features adds just a bit of compile time. There is no quick solution to make FPC much faster. But each optimization can help a bit. Then I'll commit my changes :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 16:51, schrieb Florian Klämpfl: Am 04.03.2013 15:40, schrieb Graeme Geldenhuys: On 2013-03-04 12:44, Sven Barth wrote: that really contain class helpers). Maybe we can add an additional has_operators flag and ignore all units when searching for overloads that don't have this flag set (the flag would propagate from the See, so Martin posting performance results after every FPC release does pay off. Without his post, your proposal would probably not have happened. ;-) You can see it the other way round: Sven might now spend a significant amount of time in a bug prone micro optimization of the compiler shaving off maybe 1% compilation time while he could do something else where a lot more users benefit like improving the register allocator or fixing unicode string issues. It's a bit different: Sven spent a small amount of time with a working micro optimization of the compiler shaving of maybe 2% compilation time while he could have done boring work on a manual :P And I'll leave unicode string issues to others while playing around with the register allocator sounds interesting. But before that I'd want to fix that annoying compilation aborted bug when recompiling the compiler without -B... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
2013/3/4 Martin Schreiber mse00...@gmail.com: On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote: Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! Please note that Delphi/Kylix produce both smaller and faster code than FPC in the testcase, they do full optimisation by default. Quality of the produced code is another goal of the comparisons. While the discussion is geared mostly towards compilation speed (it was already pointed why is slower than delphi and why cannot be improved easily improved), i'd like to point the produced code quality. Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower? If the generated code is not optimal yet, the devs already know the areas that can be improved? Personally, i don't care much about compilation speed since is faster enough (at least for me). I'm more interested in better generated code. This is were i'd like to see the efforts going. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef luiz americo pereira camara: Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower? There are again multiple reasons. One is indeed that the code is multiple-platform and therefore some abstraction exist in the RTL. For example, widestring and threat managers mean more code, but make things more flexible. Further: FPC tries to implement every Delphi feature, but also has unique features. Some of these unique features require runtime overhead and thus cause a bigger RTL. Assembler implementations can reduce the size of the RTL, but FPC tries to focus on portability and has therefore relatively less assembler in the RTL. Code generation quality is another factor. While FPC has in absolute terms more optimization power than Delphi, it misses a few crucial optimizations. For example, we don't have loop induction, which allows Delphi to beat FPC in code that stresses this. Further, especially regarding Lazarus, the design of the LCL simply means that a lot of code is pulled into the executable. The Delphi VCL offers more possibilities for smart linking away unneeded code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-04 15:53, Sven Barth wrote: Then I'll commit my changes :) Thanks for your efforts Sven. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 15:19:56 Tomas Hajny wrote: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Is the starting MSEide (as mentioned above) bit included in the measured time? That would probably imply quite some OS calls, of course... Yes. The time is from pressing enter with mseide respective mseidefp on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
2013/3/4 Daniël Mantione daniel.manti...@freepascal.org: Op Mon, 4 Mar 2013, schreef luiz americo pereira camara: Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower? [..] Code generation quality is another factor. While FPC has in absolute terms more optimization power than Delphi, it misses a few crucial optimizations. For example, we don't have loop induction, which allows Delphi to beat FPC in code that stresses this. Further, especially regarding Lazarus, the design of the LCL simply means that a lot of code is pulled into the executable. The Delphi VCL offers more possibilities for smart linking away unneeded code. Thanks for the response. It clarified me. Just a note. The Martin test, and my question in general, is not affected by LCL so the LCL size overhead is not relevant here Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Mon, 4 Mar 2013 17:34:37 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 15:19:56 Tomas Hajny wrote: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Is the starting MSEide (as mentioned above) bit included in the measured time? That would probably imply quite some OS calls, of course... Yes. The time is from pressing enter with mseide respective mseidefp on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle. And how much time is spent on the highlighting on Linux and Windows? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 18:16:03 Mattias Gaertner wrote: Yes. The time is from pressing enter with mseide respective mseidefp on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle. And how much time is spent on the highlighting on Linux and Windows? About 2/3 on booth. I need to instrument the code in order to get more precise numbers. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 14:54:01 Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? I don't know. I often find Windows 2000 faster than Linux. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
I am not so sure about this. === Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus broad ways for improvements reworks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 20:35, schrieb Ivanko B: I am not so sure about this. === Hmm - 20 (!) times (!!) difference. Usually it means design flaws thus broad ways for improvements reworks. Awaiting your patches. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 04.03.2013 13:22, schrieb Martin Schreiber: On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. Did you actually read my complete mail? Some do, some do not, other might have a higher impact than only 10%. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) No, because Moore is still with us. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sun, 3 Mar 2013, Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3, Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3): http://gitorious.org/mseide-msegui Impressive. Now that we've clearly established that FPC is slower than Delphi, and that you consider this a serious problem (which we, in fact, know since some time): When can we expect to see some constructive proposals on how to improve the situation? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote: On Sun, 3 Mar 2013, Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3, Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3): http://gitorious.org/mseide-msegui Impressive. Now that we've clearly established that FPC is slower than Delphi, and that you consider this a serious problem (which we, in fact, know since some time): When can we expect to see some constructive proposals on how to improve the situation? I supplied the benchmark, more than 10 man years of development time. A good start, no? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Am 03.03.2013 20:40, schrieb Martin Schreiber: On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote: On Sun, 3 Mar 2013, Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3, Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3): http://gitorious.org/mseide-msegui Impressive. Now that we've clearly established that FPC is slower than Delphi, and that you consider this a serious problem (which we, in fact, know since some time): When can we expect to see some constructive proposals on how to improve the situation? I supplied the benchmark, more than 10 man years of development time. A good start, no? ;-) First 10 m of a marathon done. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Sad. Instead of fight, why not walking together? IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. Martin: I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You are only showing the Delphi/Kylix speed is extremely superior (even knowing that Delphi do not is multiplataform and do not have the complexity that FPC has, AFAIK). One more thing: try do not thinking only in MSEgui in your thoughts, in your great ideas. IMHO the MSEgui should be part of FPC, somehow, but... FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. Best regards, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote: On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Sad. Instead of fight, why not walking together? IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. I am not so sure about this... I know nothing of dcc switches but he is comparing the compiler speed with a different set of features, it is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all optimization flags and it is expected that optimizing code takes time. Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. I am no fpc dev here, but patches are welcome I guess. Jm2c Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sun, Mar 3, 2013 at 8:29 PM, Vittorio Giovara vittorio.giov...@gmail.com wrote: On 04/mar/2013, at 00:21, Marcos Douglas m...@delfire.net wrote: [cut] FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. I am no fpc dev here, but patches are welcome I guess. That's what I meant when I spoke he is making a mistake in their approach of how to present FPC's defects. Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On 2013-03-03 23:21, Marcos Douglas wrote: Sad. Instead of fight, why not walking together? I'm not joining any fight, simply wanted to know what the 'm' stood for. I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You said it yourself... most of us know nothing about compiler coding. So how are we supposed to propose improvements! All we can do is file bug reports on things we can duplicate, or highlight issues. This is what Martin is doing here. 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. But let me repeat what you said earlier. Some of use know nothing about compilers coding, so not much we can do about it. The task falls squarely on the select few, but they have no interest in that. Optimization is boring work, compared to implementing the latest CPU target or language feature. I understand that fully. A great pity. You are only showing the Delphi/Kylix speed is extremely superior And Martin is just showing half the problem. The Delphi Kylix compilers also produce executables that run 10+ times faster than what FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And don't even think of mentioning that faster hardware will mask the problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high performance RAM and 450MB read speed SSD. I noticed a 10+ times difference in running executables on my hardware. And comments from Florian like expect FPC to get even slower by the next release doesn't help much. Nobody expects FPC to beat Delphi or Kylix performance, but FPC degrading its speed (compile time and executable run time) year-on-year is not a good sign for the long run. Anyway, this is nothing new. I mentioned this long ago, and made my peace with it. I have to cherish the fact that FPC is luckily still faster that C/C++ compilers. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sun, Mar 3, 2013 at 9:00 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-03-03 23:21, Marcos Douglas wrote: Sad. Instead of fight, why not walking together? I'm not joining any fight, simply wanted to know what the 'm' stood for. I know. I just used the last mail on this thread -- in that case, your mail. Sorry. I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You said it yourself... most of us know nothing about compiler coding. So how are we supposed to propose improvements! All we can do is file bug reports on things we can duplicate, or highlight issues. This is what Martin is doing here. Yes, I agree... but I feel a fight between Martin and FPC Team, don't you agree? 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. But let me repeat what you said earlier. Some of use know nothing about compilers coding, so not much we can do about it. The task falls squarely on the select few, but they have no interest in that. Optimization is boring work, compared to implementing the latest CPU target or language feature. I understand that fully. A great pity. I feel the same... but we can not force people who work for free to do tasks that are not important to them. You are only showing the Delphi/Kylix speed is extremely superior And Martin is just showing half the problem. The Delphi Kylix compilers also produce executables that run 10+ times faster than what FPC 2.6.0 can produce. Even on the more optimized 32-bit compiler. And don't even think of mentioning that faster hardware will mask the problem - it doesn't. I have a i7-2660K running at 3.6Ghz with high performance RAM and 450MB read speed SSD. I noticed a 10+ times difference in running executables on my hardware. Again I repeat: I agree with you. The Pascal is known because it is simple, elegant, [,,,] and FAST. And comments from Florian like expect FPC to get even slower by the next release doesn't help much. Yeah... very sad. Nobody expects FPC to beat Delphi or Kylix performance, but FPC degrading its speed (compile time and executable run time) year-on-year is not a good sign for the long run. Many many improvements trying to following Delphi, Java, whatever. Anyway, this is nothing new. I mentioned this long ago, and made my peace with it. I have to cherish the fact that FPC is luckily still faster that C/C++ compilers. For the time being... :) Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote: IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. I am not so sure about this... I know nothing of dcc switches but he is comparing the compiler speed with a different set of features, it is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all optimization flags and it is expected that optimizing code takes time. Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! Please note that Delphi/Kylix produce both smaller and faster code than FPC in the testcase, they do full optimisation by default. Quality of the produced code is another goal of the comparisons. MSEide sizes Delphi 7: 5'062'144 FPC 2.6.2 Windows with smart linking: 6'026'259 Kylix 3:5'092'836 FPC 2.6.2 Linux without smart linking 7'463'712 (it can't smartlink with 1MB ram only) Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
