Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 01.03.2013 22:40, schrieb Martin Schreiber: > On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: >> Am 01.03.2013 18:33, schrieb Martin Schreiber: >>> Hi, >>> >>> In order to have a good benchmark for FPC >> >> Expect the next release to be even slower. >> > Will it produce better code instead? > What means better? Faster? Less buggy? Smaller? I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Fri, 1 Mar 2013, Martin Schreiber wrote: Am 01.03.2013 20:52, schrieb Michael Van Canneyt: For a correct test, you should not enable debug information in FPC. Or enable generation of turbo debug information and the corresponding linker map in Delphi. Otherwise you are comparing apples with pears, as -D+ in delphi does not do nearly the same thing as -g in FPC. From an end user point of view comparison of compiletime with debug info is correct IMHO because one needs debug info for development. Absolutely. I am not arguing with that. But Delphi does not generate any real debug info with $D+. You need the actual units (dcu) to be able to debug. You cannot debug anything with an external debugger unless you enable turbo debugging info. With FPC you can use (well must) an external debugger. So FPC creates info readable by an external debugger. If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Therefor to compare what is actually comparable, and by this I mean that both compilers perform the same tasks, you must enable generation of turbo debugging and the linker map info in delphi. This means additional work for the Delphi compiler and therefor will slow down Delphi too. (in fact quite a lot, if I recall my work with AQTime). Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > > Anyway, what seems obvious from your numbers is that it is the linking > stage that needs speedup. This does not really come as a surprise. > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote: > Am 01.03.2013 22:40, schrieb Martin Schreiber: > > On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: > >> Am 01.03.2013 18:33, schrieb Martin Schreiber: > >>> Hi, > >>> > >>> In order to have a good benchmark for FPC > >> > >> Expect the next release to be even slower. > > > > Will it produce better code instead? > > What means better? Faster? Less buggy? Smaller? > It means faster and smaller, Delphi 7 produced code is smaller and faster than FPC 2.6.2 code. A compiler must be bug free anyway. ;-) > I did a quick test on win32, it seems to be a little bit smaller than > 2.6.2: > > 02.03.2013 10:09 5.774.848 mseide.exe Compiled with which FPC version? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:16, schrieb Martin Schreiber: > On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote: >> Am 01.03.2013 22:40, schrieb Martin Schreiber: >>> On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: Am 01.03.2013 18:33, schrieb Martin Schreiber: > Hi, > > In order to have a good benchmark for FPC Expect the next release to be even slower. >>> >>> Will it produce better code instead? >> >> What means better? Faster? Less buggy? Smaller? >> > It means faster and smaller, Delphi 7 produced code is smaller and faster > than > FPC 2.6.2 code. For i386-win32 maybe. A compiler must be bug free anyway. ;-) > >> I did a quick test on win32, it seems to be a little bit smaller than >> 2.6.2: >> >> 02.03.2013 10:09 5.774.848 mseide.exe > > Compiled with which FPC version? trunk. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: > > >> I did a quick test on win32, it seems to be a little bit smaller than > >> 2.6.2: > >> > >> 02.03.2013 10:09 5.774.848 mseide.exe > > > > Compiled with which FPC version? > > trunk. ??? MSEgui compiles with trunk? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:15 schrieb "Martin Schreiber" : > > On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: > > > > >> I did a quick test on win32, it seems to be a little bit smaller than > > >> 2.6.2: > > >> > > >> 02.03.2013 10:09 5.774.848 mseide.exe > > > > > > Compiled with which FPC version? > > > > trunk. > > ??? MSEgui compiles with trunk? Surprise! :P We don't try to respect backwards compatibility for nothing. ;) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f It will allow me to see what IO the Delphi/Kylix compiler does. We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. (for example renaming all files to .pp takes off +/- 1 second here) Nevertheless, I'd be interested in seeing the strace. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:21, schrieb Martin Schreiber: > On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: >> I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe >>> >>> Compiled with which FPC version? >> >> trunk. > > ??? MSEgui compiles with trunk? Compiled with WPO and -O4 it starts and I can edit text and forms. Nothing more tested. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:28, schrieb Michael Van Canneyt: > > > On Sat, 2 Mar 2013, Martin Schreiber wrote: > >> On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: >>> >>> Anyway, what seems obvious from your numbers is that it is the linking >>> stage that needs speedup. This does not really come as a surprise. >>> >> On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll >> check it >> later, currently I try to make MSEide+MSEgui Kylix3 compatible so we >> have a >> benchmark on Linux too. > > When you do, please send me the output of a strace -f > > It will allow me to see what IO the Delphi/Kylix compiler does. > > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. > > (for example renaming all files to .pp takes off +/- 1 second here) > > Nevertheless, I'd be interested in seeing the strace. Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Kl?mpfl said: > > (for example renaming all files to .pp takes off +/- 1 second here) > > > > Nevertheless, I'd be interested in seeing the strace. > > Better parallize the building using some build units. Then it will be > probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
> Am 01.03.2013 18:33, schrieb Martin Schreiber: >> Hi, >> >> In order to have a good benchmark for FPC Afaik Delphi 7 is closed source, so inherently worse than any version of FPC. Cheers, Vittorio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Martin Schreiber said: > > > > > > Compiled with which FPC version? > > > > trunk. > > ??? MSEgui compiles with trunk? It is mostly unicodestring centric, so that shouldn't be such a surprise? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote: > In our previous episode, Martin Schreiber said: > > > > Compiled with which FPC version? > > > > > > trunk. > > > > ??? MSEgui compiles with trunk? > > It is mostly unicodestring centric, so that shouldn't be such a surprise? MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Compiled with which FPC version? trunk. ??? MSEgui compiles with trunk? It is mostly unicodestring centric, so that shouldn't be such a surprise? MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore... Clearly, you have not been watching SVN, because Paul Ishenin is currently integrating the native Object Pascal unicode string manager in trunk. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: > If you hire 2 painters to paint the whole of your house, > and one doesn't paint the inside, "because you don't see it from the > outside", of course he will be finished faster; he didn't perform the same > work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls. -- Craig Peterson Scooter Software ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 13:24, schrieb Marco van de Voort: In our previous episode, Florian Kl?mpfl said: (for example renaming all files to .pp takes off +/- 1 second here) Nevertheless, I'd be interested in seeing the strace. Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 15:15, schrieb Craig Peterson: On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. A more apt comparison would be that we hired the painters to paint the outside of the house and one of them did the inside too because his tools require him to paint both sides of the walls. While the other one can paint only in one color and only buildings with one floor ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Klaempfl said: > >> Better parallize the building using some build units. Then it will be > >> probably compiled in less than 10 sec on a modern CPU. > > > > Better paralellize the compiler :-) > > In theory yes but I still fear that the threadvars and synchronization > eats much of the advantage in this case. I don't see why there would be more synchronization overhead than make? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 16:23, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: Better parallize the building using some build units. Then it will be probably compiled in less than 10 sec on a modern CPU. Better paralellize the compiler :-) In theory yes but I still fear that the threadvars and synchronization eats much of the advantage in this case. I don't see why there would be more synchronization overhead than make? In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data corruption. With make, the different units can be seperated much better by a human than the compiler can do. Not to mention the huge effort it would be to get the compiler parallelized internally. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, Mar 02, 2013 at 04:23:32PM +0100, Marco van de Voort wrote: > In our previous episode, Florian Klaempfl said: > > >> Better parallize the building using some build units. Then it will be > > >> probably compiled in less than 10 sec on a modern CPU. > > > > > > Better paralellize the compiler :-) > > > > In theory yes but I still fear that the threadvars and synchronization > > eats much of the advantage in this case. > > I don't see why there would be more synchronization overhead than make? So why not keep it simple and let the build system handle parallel jobs? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Craig Peterson wrote: On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt wrote: If you hire 2 painters to paint the whole of your house, and one doesn't paint the inside, "because you don't see it from the outside", of course he will be finished faster; he didn't perform the same work. Delphi is generating enough information that you can debug using it. The fact that its debugger is built in and FPC requires an external debugger that can't read the .ppus is an implementation detail. You cannot ignore the implementation details. Making abstraction of these details means ignoring the benefits that follow from these details: It is exactly these details that allow FPC to support so many platforms, and why Delphi is stuck with Windows and remote compiling/debugging for MaCOS. Delphi does not even run on these platforms ! FPC does. If you are - like Martin, I suspect - not interested in weird and exotic platforms then of course FPC's implementation choice and the attached consequences present you with a disadvantage because of these 'implementation details'. But if you are interested in ARM, raspberry PI, MIPS and whatever there is out there, it is these implementation details that make FPC the only possible choice. All this said: You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as possible. So, proposals for improvement are most welcome. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Florian Klaempfl said: > > I don't see why there would be more synchronization overhead than make? > > In a parallelized compiler symtables etc. might be shared and this might > require a lot of synchronization to prevent data corruption. > With make, the different units can be seperated much better by a human > than the compiler can do. Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-) > Not to mention the huge effort it would be to get the compiler > parallelized internally. As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. The rest more or less runs as is, and the linker remains single threaded after all compile threads have finished? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
In our previous episode, Henry Vermaak said: > > I don't see why there would be more synchronization overhead than make? > > So why not keep it simple and let the build system handle parallel jobs? I like autobuilding. IMHO that is a core attraction of unit based (modular) languages. Manually maintaining dependencies between compilation units is stone-age. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 17:24, schrieb Marco van de Voort: In our previous episode, Florian Klaempfl said: I don't see why there would be more synchronization overhead than make? In a parallelized compiler symtables etc. might be shared and this might require a lot of synchronization to prevent data corruption. With make, the different units can be seperated much better by a human than the compiler can do. Only if you want to avoid multiply used units to be only once in memory. IMHO if you are afraid of that, then don't do that :-) Forking compilers on a by unit level instead of some meta level is typically slower because reading ppus takes a lot of time. Not to mention the huge effort it would be to get the compiler parallelized internally. As said the first step can be relatively simple. Get rid of globals some more, and then only the parts before compile() needs to be changed. In theory, yes. In practice this is a huge effort. Just one example: inlining requires that the node tree of a procedure is copied. However, during copying the tree is annotated for proper copying. Bottom line: even if the compiler finished to compile a unit, the generated info is not read only. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 16:49, schrieb Michael Van Canneyt: All this said: You will not hear me claiming that there is no room for improvement in FPC. I'm sure there is. However, I do not think we'll be able to match Delphi's speed without sacrificing the main goal of FPC: to support as much platforms as possible. Well, not to mention the goal of maintainability. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Delphi anonymous methods
Hi, I want to implement support of Delphi anonymous methods for fpc. As I know I should create good proposal. Fortunately Delphi already made half of my work. Proposal: all behaviour described in http://docwiki.embarcadero.com/RADStudio/XE3/en/Anonymous_Methods_in_Delphi should be implemented. Anonymous methods are like closures in other languages. Main features of anonymous methods and closures are - access to local variables - extend lifetime of used local variables. Difference between anonymous methods in Delphi and closures in most other languages is that you can not create many instances of same anonymous methods during work of it's declaring function. I don't know how to say better, but example can help: =begin example type TProc = reference to Procedure; var i: Integer; arr: array[1..5] of TProc; begin for i := 1 to 5 do arr[i] := procedure begin end; for i := 1 to 4 do Write(arr[i] = arr[i+1], ' '); end. =end example Someone who thinks that first cycle creates different anonymous methods is wrong. All values in arr will be equal after cycle execution. Here more complicated example of same feature: https://gist.github.com/vkevroletin/5069653 I investigated behaviour and implementation(slightly) of anonymous methods in Delphi. Results are in document below. It have little introduction which is not very useful for advanced developers but may be helpful in wiki to describe some aspects of compiler. Both links point to same document in different formats. plain text: https://raw.github.com/vkevroletin/Diploma/master/anonym_method_delphi.org pdf: https://github.com/vkevroletin/Diploma/blob/master/anonym_method_delphi.pdf Implementation of anonymous methods was started in the branch. Author didn't submit anything last year and forgot commit one added file. But changes from branch can be useful, AFAIU parsing of anonymous functions without capturing of local variables was implemented. Does someone know is author available? Does he plan to continue work, or I can work on implementation without collaboration with him ? Or at least can he send missed file ? It's hard to properly split this complex task into subtasks. I can propose 2 steps: 1. Parsing and generation of anonymous function. Capturing of variables is forbidden. 2. Capturing of variables is implemented. A question for fpc team: do you agree that support of Delphi-compatible anonymous methods should be implemented? Also there are open questions which require brainstorm: 1. Does Pascal needs other implementation of closures which is different from anonymous methods implementation? 2. Does Pascal needs short syntax for closures? I if someone want to discuss these questions it will be better to create in separate threads. Link to closures branch: http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/blaise/closures/ Vasiliy K. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 02.03.2013 20:03, vrt277 wrote:
Implementation of anonymous methods was started in the branch. Author
didn't submit anything last year and forgot commit one added file. But
changes from branch can be useful, AFAIU parsing of anonymous functions
without capturing of local variables was implemented.
Does someone know is author available? Does he plan to continue work, or
I can work on implementation without collaboration with him ? Or at
least can he send missed file ?
I have already written the author some time ago. He has said that he
plans to at least commit the missing files. If you would continue his
work (in a new branch please with a complete copy of trunk...) then he
might be relieved as well.
It's hard to properly split this complex task into subtasks. I can
propose 2 steps:
1. Parsing and generation of anonymous function. Capturing of
variables is forbidden.
2. Capturing of variables is implemented.
A question for fpc team: do you agree that support of Delphi-compatible
anonymous methods should be implemented?
At least I do, yes.
Also there are open questions which require brainstorm:
1. Does Pascal needs other implementation of closures which is different
from anonymous methods implementation?
I would say no. After all the method implementation itself stays the
same, but the captured variables should be different. Or what does this
print:
=== example begin ===
var
arr: array[0..5] of reference to procedure;
i: LongInt;
begin
for i := Low(arr) to High(arr) do
arr[i] := procedure
begin
Writeln(i);
end;
Writeln('Output: '); // just to ensure that the optimizer doesn't
combine the two loops
for i := Low(arr) to High(arr) do
arr[i]();
end;
=== example end ===
2. Does Pascal needs short syntax for closures?
I would say yes, but this can be done in a seperate step
I if someone want to discuss these questions it will be better to create
in separate threads.
Two personal things I'd like to note as I have already planned to
continue working on anonymous functions myself:
- add support to pass nested functions to "reference to" procvars; this
will allow users who don't want to use the anonymous syntax to use the
"closure" feature as well; please note that this must be done in a way
that passing nested functions to "is nested" procvars is not broken
- (in context with the above point) couple the support for the anonymous
functions to a new modeswitch (enabled by default in mode delphi), but
allow "reference to" procvars in non-Delphi modes (this way you'd only
be able to use nested functions, but later on the shorter syntax should
be used there as well)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 2013-03-02 21:55, Sven Barth wrote: - (in context with the above point) couple the support for the anonymous functions to a new modeswitch (enabled by default in mode delphi), but allow "reference to" procvars in non-Delphi modes (this way you'd only be able to use nested functions, but later on the shorter syntax should be used there as well) This paragraph went way over my head. But, it sort of reminded me to ask about something else: Are anonymous methods (going to be) compatible with event methods? i.e. are they 'procedure of object' (or 'function of object') kind of constructs. The reason I am asking this is: There have been times when I could kill to be able to assign (temporarily) a local procedure/function an object's event (say, OnClick) so that I could capture the event's outcome right in there wthin the body of the active routine. Would this be possible? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 02.03.2013 21:25, ListMember wrote: On 2013-03-02 21:55, Sven Barth wrote: - (in context with the above point) couple the support for the anonymous functions to a new modeswitch (enabled by default in mode delphi), but allow "reference to" procvars in non-Delphi modes (this way you'd only be able to use nested functions, but later on the shorter syntax should be used there as well) This paragraph went way over my head. But, it sort of reminded me to ask about something else: Are anonymous methods (going to be) compatible with event methods? i.e. are they 'procedure of object' (or 'function of object') kind of constructs. The reason I am asking this is: There have been times when I could kill to be able to assign (temporarily) a local procedure/function an object's event (say, OnClick) so that I could capture the event's outcome right in there wthin the body of the active routine. Would this be possible? In theory one could extend the "reference to" procvars to handle normal methods as well. But then the event handler would need to be defined as a "reference to" procvar as well instead of an "of object" one. An "of object" procvar on the other hand is too fixed. Only the new procvar type introduced together with anonymous functions would be flexible enough so that it could be used as a replacement for all other procvars (if implemented correctly in the compiler). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] arm-embedded apps crash in exception handler initialization because heapmanager is not initialized
I am not sure if I have hit work in progress code here
my arm-embedded app crashes during initialization, the reason is that
now exceptions are part of the rtl but there is no properly initialized
heapmanager:
Procedure InitExceptions;
{
Must install uncaught exception handler (ExceptProc)
and install exceptions for system exceptions or signals.
(e.g: SIGSEGV -> ESegFault or so.)
}
begin
ExceptionClass := Exception;
ExceptProc:=@CatchUnhandledException;
// Create objects that may have problems when there is no memory.
//CRASH BOOM BANG in the following line
OutOfMemory:=EOutOfMemory.Create(SOutOfMemory);
Creating the object fails because the MemoryManager is not properly
initialized yet.
When I put heapmgr unit before sysutils im my program (this should not
be necesary, right???) I can debug a little deeper in object
initialization but still the root cause exists that there has never been
a call to RegisterHeapBlock so objects cannot be initiated because
there's no memory block defined that heapmgr can draw memory from.
I can hack the RegisterHeapBlock call into the initialization code of
the unit heapmgr but this is more a hack than a proper solution -->
seems a bad idea to me.
How can this be properly solved?
Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
On 02.03.2013 20:55, Sven Barth wrote:
Also there are open questions which require brainstorm:
1. Does Pascal needs other implementation of closures which is different
from anonymous methods implementation?
I would say no. After all the method implementation itself stays the
same, but the captured variables should be different. Or what does this
print:
I've now read through your PDF and somehow I'd like to have a better
implementation in FPC. Let's consider the following code (Note: I've
never used anonymous methods yet, so this is what I naively would expect):
=== code begin ===
var
i: LongInt;
SomeProc1, SomeProc2: reference to procedure;
begin
i := 42;
SomeProc1 := procedure
begin
Writeln('Proc1: ' + i);
end;
i := 21;
SomeProc2 := procedure
begin
Writeln('Proc2: ' + i);
end;
SomeProc1;
SomeProc2;
end;
=== code end ===
The output I'd expect here is the following:
=== output begin ===
42
21
=== output end ===
But if I've understood you correctly I'll get the following instead:
=== output begin ===
21
21
=== output end ===
I don't like this -.-
You also wrote that local variables seem to be located on the
FrameObject. So how is it with multi threading? E.g.
=== example begin ===
for i := 0 to 5 do
TThread.CreateAnonymousThread(
procedure
var
x: LongInt;
begin
x := Random;
Writeln('Before ', TThread.CurrentThread.ThreadID, ': ', x);
Sleep(x);
Writeln('After ', TThread.CurrentThread.ThreadID, ': ', x);
end).Start;
=== example end ===
If the "x" is really located in the FrameObject and that object exists
only once then it is rather likely that the output of 'Before 123: ' is
different from the output of 'After 123: ', right? Again I think this is
a bad thing...
So in my opinion an implementation with a stricter division between the
single instances of an anonymous function would be the better choice.
Also local variables should reside on the stack of the anonymous
function... as we generate the code of nested procedures/functions only
after the complete outer function was parsed (and AFAIK also had its
code generated) we should be able to "easily" add the generation of
anonymous function bodies as well. So we should have multiple smaller
objects storage objects that only contain those variables of the outer
function and those nested functions that are really used instead of one
big FrameObject. It might be quite a bit harder to implement in a
correct and good (and maybe also performant) way, but we would - at
least in my opinion - gain a more logical and straight implementation of
closures.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Status of SEH in FPC
Hello, what's the current state of the SEH in FPC trunk? IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was in the 2.7 roadmap, but I can't find any related brach, or commit, or post. Also AFAIU would have some gains in both executable size and speed, correct? -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 2013-03-02 10:28, Michael Van Canneyt wrote: > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source? 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] Comparison FPC 2.6.2 - Delphi 7
On Sat, 2 Mar 2013, Graeme Geldenhuys wrote: On 2013-03-02 10:28, Michael Van Canneyt wrote: We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. Second time I hear this this week. Can we (in our own copies of FPC) change this to search .pas first? If so, where in the source? Search for sourceext and pasext. fppu.pas: Found:=UnitExists(sourceext,hs); fppu.pas: Message1(unit_t_unitsearch,ChangeFileExt(sourcefn,sourceext)); fppu.pas: fnd:=FindFile(ChangeFileExt(sourcefn,sourceext),'',true,hs); globals.pas: sourceext = '.pp'; options.pas: if FileExists(inputfilepath+ChangeFileExt(inputfilename,sourceext)) then options.pas:inputfilename:=ChangeFileExt(inputfilename,sourceext) scanner.pas: found:=findincludefile(path,ChangeFileExt(name,sourceext),foundfile); Be careful when changing this, because the compiler will then also search for rtl/fcl/package source files with different names, which may result in nasty surprises. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
=== output end ===
But if I've understood you correctly I'll get the following instead:
=== output begin ===
21
21
=== output end ===
Right
You want to capture variable by value. For example lambdas in c++ have
special syntax to choose how to capture. By reference or by value.
Capturing by value is useful to make parametrized anonymous functions.
Capturing by reference is useful to change local variables. In other
c-like languages if you have capturing by reference you can simply
simulate capturing by value. You can wrap anonymous function into a
block and declare local variable in this block.
Example:
=== begin perl ===
for my $i (0 .. 9)
{
my $copy = $i;
$f[$i] = sub {
printf($copy);
};
}
$f[0]->(); #0
$f[9]->(); #9
=== end perl ===
Javascript is more like Delphi. Scope of variable in javascript
restricted by entire declaring function not by declaring block. So you
should do something like this:
=== begin javascript ===
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0]();
f[9]();
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0](); // 0
f[9](); // 9
=== end javascript ===
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0]();
f[9]();
You also wrote that local variables seem to be located on the
FrameObject. So how is it with multi threading? E.g.
I missed test with multithreading and made wrong assumption.
Sven's test:
=== test begin ===
for i := 0 to 1 do
TThread.CreateAnonymousThread(
procedure
var
x: LongInt;
begin
Writeln('Address ', TThread.CurrentThread.ThreadID, ': 0x',
IntToHex(Integer(@x), 8));
x := Round(Random*100);
Writeln('Before ', TThread.CurrentThread.ThreadID, ': ', x);
Sleep(5000);
Writeln('After ', TThread.CurrentThread.ThreadID, ': ', x);
end).Start;
=== test end ===
=== output begin ===
Address 2028: 0x00F3FF68
Before 2028: 0
Address 2176: 0x0103FF68
Before 2176: 3
After 2028: 0
After 2176: 3
=== output end
There are different local variables in different threads. But in one
thread local variables are same.
=== test begin ===
for i := 0 to 1 do
f[i] := procedure
var x: Integer;
begin
Writeln('Address ', TThread.CurrentThread.ThreadID, ': 0x',
IntToHex(Integer(@x), 8));
end;
Writeln(' ');
for i := 0 to 1 do
f[i]();
=== test end ===
=== output begin ===
Address 3364: 0x0012FF98
Address 3364: 0x0012FF98
=== output end ===
Do you have any ideas how and why such behaviour implemented ?
Vasiliy K.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
> === output end ===
>
> But if I've understood you correctly I'll get the following instead:
>
> === output begin ===
>
> 21
> 21
>
> === output end ===
>
Right
You want to capture variable by value. For example lambdas in c++ have
special syntax to choose how to capture. By reference or by value.
Capturing by value is useful to make parametrized anonymous functions.
Capturing by reference is useful to change local variables. In other
c-like languages if you have capturing by reference you can simply
simulate capturing by value. You can wrap anonymous function into a
block and declare local variable in this block.
Example:
=== begin perl ===
for my $i (0 .. 9)
{
my $copy = $i;
$f[$i] = sub {
printf($copy);
};
}
$f[0]->(); #0
$f[9]->(); #9
=== end perl ===
Javascript is more like Delphi. Scope of variable in javascript
restricted by entire declaring function not by declaring block. So you
should do something like this:
=== begin javascript ===
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0]();
f[9]();
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0](); // 0
f[9](); // 9
=== end javascript ===
for (i = 0; i < 10; ++i)
{
(function () {
var copy = i;
f[i] = function () {
alert(copy);
}
})()
}
f[0]();
f[9]();
>
> You also wrote that local variables seem to be located on the
FrameObject. So how is it with multi threading? E.g.
I missed test with multithreading and made wrong assumption.
Sven's test:
=== test begin ===
for i := 0 to 1 do
TThread.CreateAnonymousThread(
procedure
var
x: LongInt;
begin
Writeln('Address ', TThread.CurrentThread.ThreadID, ': 0x',
IntToHex(Integer(@x), 8));
x := Round(Random*100);
Writeln('Before ', TThread.CurrentThread.ThreadID, ': ', x);
Sleep(5000);
Writeln('After ', TThread.CurrentThread.ThreadID, ': ', x);
end).Start;
=== test end ===
=== output begin ===
Address 2028: 0x00F3FF68
Before 2028: 0
Address 2176: 0x0103FF68
Before 2176: 3
After 2028: 0
After 2176: 3
=== output end
There are different local variables in different threads. But in one
thread local variables are same.
=== test begin ===
for i := 0 to 1 do
f[i] := procedure
var x: Integer;
begin
Writeln('Address ', TThread.CurrentThread.ThreadID, ': 0x',
IntToHex(Integer(@x), 8));
end;
Writeln(' ');
for i := 0 to 1 do
f[i]();
=== test end ===
=== output begin ===
Address 3364: 0x0012FF98
Address 3364: 0x0012FF98
=== output end ===
Do you have any ideas how and why such behaviour implemented ?
Vasiliy K.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of SEH in FPC
03.03.2013 2:53, Flávio Etrusco пишет: Hello, what's the current state of the SEH in FPC trunk? IIRC - and according to wikipedia ;-) - SEH, at least for Windows, was in the 2.7 roadmap, but I can't find any related brach, or commit, or post. Also AFAIU would have some gains in both executable size and speed, correct? By now SEH is fully implemented for Win64 target, but you need to cycle the compiler with OPT=-dTEST_WIN64_SEH to enable it. The most of it was committed in revision 20098. The effect of SEH is two-fold: it gives some performance gain when running without exceptions, but big penalty when exceptions occur. It somewhat reduces code size but at the same time adds some data, so executable size may not reduce. The main advantage of SEH is the conformance with OS exception handing scheme. Without it, it was almost impossible to use DLLs that raise exceptions. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Do you have any ideas how and why such behaviour implemented ?
Now I can answer my question myself. *Local variables of anonymous
method are located on stack*.
This assumption is based on 2 points:
1.
assignment to local variable of anonymous function
x := 10;
will become this
mov [ebp - $04], $a
=== full example ===
begin
Call( procedure
var x: Integer;
begin
x := 10; { mov [ebp - $04], $a }
Writeln(x);
end );
end.
===
2. example
https://gist.github.com/vkevroletin/5069653
output for example is in first comment after code.
Vasiliy
P.S.
In last email I pasted one javascript example 3 times accidentally.
I was writing from vrt...@gmail.com before because emails from my main
mailbox wasn't delivered to mail list.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
Hi Vasiliy, Just some additional info in case you are not aware. Delphi implements the anonymous methods as interfaces, and that is how it keeps them alive. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Vasiliy Kevroletin Sent: Saturday, March 02, 2013 9:08 PM To: FPC developers' list Subject: Re: [fpc-devel] Delphi anonymous methods Now I can answer my question myself. *Local variables of anonymous method are located on stack*. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: > On Sat, 2 Mar 2013, Martin Schreiber wrote: > > On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > >> Anyway, what seems obvious from your numbers is that it is the linking > >> stage that needs speedup. This does not really come as a surprise. > > > > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll > > check it later, currently I try to make MSEide+MSEgui Kylix3 compatible > > so we have a benchmark on Linux too. > > When you do, please send me the output of a strace -f > I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. > It will allow me to see what IO the Delphi/Kylix compiler does. > > We can say for sure that the fact you use .pas as filename extension > will cause FPC to do twice the number of stat() calls, because .pp is > searched first...Logical therefore that the IO is slower. > AFAIK "*.pas" is Delphi compatible? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
If the "x" is really located in the FrameObject and that object exists only once then it is rather likely that the output of 'Before 123: ' is different from the output of 'After 123: ', right? Again I think this is a bad thing... I was wrong. Local variables of anonymous function located where they should be: on stack. So in my opinion an implementation with a stricter division between the single instances of an anonymous function would be the better choice Am I understand correctly that loop for i := 1 to 5 do procArr[i] := procedure begin DoSmth(); end; should create 5 separate instances? It is as I thought about closures before. But this is useless without capturing of variables by value. During creation of anonymous method you *can not bind any values* to it. Anonymous method have only references to captured variables. Pascal don't allows to create static variables inside function like in c-like languages. So you also not able to create unique static variable which available only to one instance of same anonymous method. Even if implementation will create many separate objects for one anonymous function then all instances will be equivalent. Because all instances will refer to same data. Capturing variables by value will allow simple creation of parametrised closures. Now you also can do parametrised anonymous method but you should wrap generation of such method into other anonymous function. For example like this: === example for i := 1 to 5 do procArr[i] := Call( function: TProc var stored: Integer; begin stored := i; Result := procedure begin Writeln(stored); end; end ); === This can be simplified by support of capturing by value (please don't make many attention to syntax, it's not main part of my proposal). === example for i := 1 to 5 do procArr[i] := procedure capture i: byValue; begin Writeln(i); end; end ); === What do you think about extension which will allow to specify how to capture. Either by value or by reference? Vasiliy K. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote: > On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: > > On Sat, 2 Mar 2013, Martin Schreiber wrote: > > > On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: > > >> Anyway, what seems obvious from your numbers is that it is the linking > > >> stage that needs speedup. This does not really come as a surprise. > > > > > > On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll > > > check it later, currently I try to make MSEide+MSEgui Kylix3 compatible > > > so we have a benchmark on Linux too. > > > > When you do, please send me the output of a strace -f > > I will take a while because it is much work to make the code both FPC and > Delphi/Kylix compatible. > BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
