Am 26.12.2012 13:17, schrieb Martin Schreiber:
> 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
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 b
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 n
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 hop
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? T
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 (
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 t
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)
> >
Am 25.12.2012 19:39, schrieb Mattias Gaertner:
On Tue, 25 Dec 2012 18:01:50 +0100
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 slow
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 compi
On Tue, 25 Dec 2012 18:01:50 +0100
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)
>
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 10
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 the
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:17, schrieb Yury Sidorov:
From: "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-
From: "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 still much better than
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 still
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,
Pa
Am 25.12.2012 14:59, schrieb Yury Sidorov:
From: "Yury Sidorov"
From: "Florian Klaempfl"
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
> 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: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
From: "Yury Sidorov"
From: "Florian Klaempfl"
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
cl
> 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 is not needed to handle memory releases during obje
> 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 handle aloocation from the pool...
>
Agre
From: "Florian Klaempfl"
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 nod
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 handl
From: "Marco van de Voort"
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 t
On 25.12.2012 12:55, Marco van de Voort wrote:
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
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 ph
29 matches
Mail list logo
