Am 26.12.2012 05:42, schrieb Martin Schreiber:
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
On 26.12.2012 05:42, Martin Schreiber wrote:
Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.
AFAIK Delphi 7 does not need such an approach so I hope there is room for
optimizations in FPC.
Did you even read what we wrote?
On Wednesday 26 December 2012 12:41:42 Sven Barth wrote:
On 26.12.2012 05:42, Martin Schreiber wrote:
Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.
AFAIK Delphi 7 does not need such an approach so I hope there is
On Wed, 26 Dec 2012, Martin Schreiber wrote:
On Wednesday 26 December 2012 12:41:42 Sven Barth wrote:
On 26.12.2012 05:42, Martin Schreiber wrote:
Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.
AFAIK Delphi 7 does not
Mark Morgan Lloyd schrieb:
I've got machines which are older than that, but they've almost all got
multiple processors. I can't remember the exact timing, but a Sun
machine with 16x 80MHz chips would build the Linux kernel in a minute or
so, so parallelisation at the make -j level can be a
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
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
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
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
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: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
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: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: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 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
25 matches
Mail list logo
