Michael Van Canneyt wrote:
On Mon, 24 Dec 2012, Martin Schreiber wrote:
- Produce at least as good code as Delphi 7.
- Compile at least as fast as Delphi 7.
You know that sacrifices need to be made to make a compiler cross
platform and easily portable. You can't have it all.
We will
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From what I remember, the problems you (and everyone else) experience
with smartlinking
On Tue, 25 Dec 2012, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From what I remember, the problems you (and
On Tue, 25 Dec 2012, Sven Barth wrote:
On 25.12.2012 12:13, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From
In our previous episode, Sven Barth said:
and linked about 10 times as fast as FPC.
AFAIK Delphi's command line compiler does not allow you to skip the
assembling and linking phase, so the fairest comparison would be to
compare the compilation of a single unit as there the linking phase
On 25.12.2012 12:40, Michael Van Canneyt wrote:
On Tue, 25 Dec 2012, Sven Barth wrote:
On 25.12.2012 12:13, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself
Sven Barth wrote:
On 25.12.2012 11:32, Mark Morgan Lloyd wrote:
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
They aren't compiled anyway, so they don't affect the compiler's
performance negatively.
So it does
From: Marco van de Voort mar...@stack.nl
In our previous episode, Sven Barth said:
and linked about 10 times as fast as FPC.
AFAIK Delphi's command line compiler does not allow you to skip the
assembling and linking phase, so the fairest comparison would be to
compare the compilation of a
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
Agreed.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 25.12.2012 12:38, schrieb Michael Van Canneyt:
On Tue, 25 Dec 2012, Martin Schreiber wrote:
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly calls to heap
manager and avoid zero filling of small memory chunks. A base class for
various FPC nodes should be modified to
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 25.12.2012 11:32, Mark Morgan Lloyd wrote:
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
They aren't compiled anyway, so they don't affect the
From: Florian Klaempfl flor...@freepascal.org
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for
nodes
from some zero pre-filled memory pool to avoid costly calls to heap
manager and avoid zero filling of small memory chunks. A base class
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Is this close i386 intermediate code similar to IR LLVM generation ?
if so, this may become a good option for a new strategy ?
From: Yury Sidorov j...@cp-lab.com
From: Florian Klaempfl flor...@freepascal.org
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for
nodes
from some zero pre-filled memory pool to avoid costly calls to
heap
manager and avoid zero filling
Am 25.12.2012 14:53, schrieb Jy V:
Although FPC heap manager is good, but custom pool memory allocation
will be much faster, since it will be very simple:
Result:=CurPoolPtr;
Inc(CurPoolPtr, BlockSize);
if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool();
It
The total time FPC spend in memory manangement is 20% iirc. So I don't see
much optimization potential here.
OK.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 25.12.2012 14:44, schrieb Jy V:
The only approach I see to speed it up is to kick the whole back end
and generate directly some close to i386 intermediate code directly
in the parser.
Is this close i386 intermediate code similar to IR LLVM generation ?
No. It must be much
Is this close i386 intermediate code similar to IR LLVM generation ?
No. It must be much closer to i386 else there is no speed advantage over
the current approach.
OK, understood.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 25.12.2012 14:15, Florian Klaempfl wrote:
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Ewww... please not...
Regards,
Sven
___
fpc-devel
Am 25.12.2012 15:04, schrieb Sven Barth:
On 25.12.2012 14:15, Florian Klaempfl wrote:
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Ewww... please not...
No, we would be back in pre 1.0
Am 25.12.2012 14:59, schrieb Yury Sidorov:
From: Yury Sidorov j...@cp-lab.com
From: Florian Klaempfl flor...@freepascal.org
Am 25.12.2012 13:39, schrieb Yury Sidorov:
It is possible to seed-up compilation by allocating memory for nodes
from some zero pre-filled memory pool to avoid costly
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(
10-20% is still much better than nothing.
Best regards,
Am 25.12.2012 15:11, schrieb Paul Ishenin:
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as 10-20% :(
10-20% is
From: Paul Ishenin paul.ishe...@gmail.com
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that
such
pooling will not speed up the compiler too much. Only minor
improvement
such as 10-20% :(
10-20% is
Am 25.12.2012 15:17, schrieb Yury Sidorov:
From: Paul Ishenin paul.ishe...@gmail.com
25.12.12, 21:59, Yury Sidorov пишет:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking) are
the numbers I have in mind too. IMHO denial without tests is unfair.
Maybe the parallelization could be improved? This would
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking) are
the numbers I have in mind too. IMHO denial without tests is unfair.
Maybe
Florian Klaempfl wrote:
Am 25.12.2012 15:11, schrieb Paul Ishenin:
25.12.12, 21:59, Yury Sidorov ?:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that such
pooling will not speed up the compiler too much. Only minor improvement
such as
Sven Barth wrote:
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be
in compiler/attic
In our previous episode, Mark Morgan Lloyd said:
interest to implement such a CPU... *cough* m68k *cough* ;)
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic,
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
Aan: FPC developers' list fpc-devel@lists.freepascal.org
Verzonden: Dinsdag 25 december 2012 14:15:24
Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
I see no way to speed up the 2.x FPC
On Tue, 25 Dec 2012 18:01:50 +0100
Florian Klaempfl flor...@freepascal.org wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without
On 25.12.2012 18:12, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic,
On 25.12.2012 18:10, Mark Morgan Lloyd wrote:
Florian Klaempfl wrote:
Am 25.12.2012 15:11, schrieb Paul Ishenin:
25.12.12, 21:59, Yury Sidorov ?:
Hmm, Seems to be a false alarm :(
I've made some tests just now with memory allocation and found that
such
pooling will not speed up the
Am 25.12.2012 19:30, schrieb Dimitri Smits:
I'm guessing that is NOT on a Windows platform? Every full build (it
has been a while) I've ever done of the compiler on windows was at
least a few minutes.
It is windows: self compilation. No rtl building or whatever.
The only approach I see to
Am 25.12.2012 19:39, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 18:01:50 +0100
Florian Klaempfl flor...@freepascal.org wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names
On 25.12.2012 19:30, Dimitri Smits wrote:
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
Aan: FPC developers' list fpc-devel@lists.freepascal.org
Verzonden: Dinsdag 25 december 2012 14:15:24
Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
I see
On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without linking)
are the
Florian Klaempfl wrote:
Am 25.12.2012 15:28, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (up till 10 times slower, even without
linking) are
the numbers I have in mind too. IMHO denial without
The IR changes syntax often, so using that will most likely cause version
problems. The other option is to use C++ classes directly which apparently is
more stable.
I know i386, x86_64 and ARM works pretty good. I don't know about the few
others.
Compiling speed is very, very slow :) (when
41 matches
Mail list logo
