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
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,
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
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
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
Am 02.03.2013 11:15 schrieb Martin Schreiber mse00...@gmail.com:
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
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
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
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
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
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
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 -
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
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
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt mich...@freepascal.org 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.
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
Am 02.03.2013 15:15, schrieb Craig Peterson:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt
mich...@freepascal.org 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
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
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
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
On Sat, 2 Mar 2013, Craig Peterson wrote:
On Mar 2, 2013, at 3:52 AM, Michael Van Canneyt mich...@freepascal.org 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
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
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
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
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
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
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
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 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
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
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
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
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
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.
=== 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
=== 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.
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
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
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
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
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
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
42 matches
Mail list logo
