Jan Ruzicka wrote:
Is there some wiki[1] where we can collect mentioned ideas?
http://www.freepascal.org/wiki
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Jan Ruzicka wrote / napísal (a):
Enough guys
each camp can make distinct implementation.
Use this forum to discuss an interface.
Let the results speak for themselves.
Lets discuss test code.
Lets discuss benchmark code.
Instead of discussing bunch of what-ifs
let's see how the implementation does.
Enough guys
each camp can make distinct implementation.
Use this forum to discuss an interface.
Let the results speak for themselves.
Lets discuss test code.
Lets discuss benchmark code.
Instead of discussing bunch of what-ifs
let's see how the implementation does.
Is there some wiki[1] where we ca
On Friday 25 February 2005 17:29, Eric Grange wrote:
> > 1. This is not "entirely true" (the cost is at best logarithmic on the
> > number of objects or your allocator has terrible fragmentation)
>
> Not really, you can use a memory map and achieve much lower
> fragmentation than classic memory man
1. This is not "entirely true" (the cost is at best logarithmic on the
number of objects or your allocator has terrible fragmentation)
Not really, you can use a memory map and achieve much lower
fragmentation than classic memory managers (cf. "FastMM" submissions
in the FastCode project in the b.
Certain Delphi constructs are not yet supported by the FreePascal
preprocessor. Therefore, I have written a patch to implement this
functionality, so the package Technetium can compile on FreePascal again.
The attached patch closes both these bugs:
http://www.freepascal.org/bugs/showrec.php3?ID
Marco van de Voort wrote:
On 25 feb 2005, at 15:49, Marco van de Voort wrote:
- Critical parts are often handoptimized by using a lot of non GCed
types
(like int), this is not a typical programming method for these
languages, but outright expert tuning.
Critical paths are also optimized in our
Marco van de Voort wrote:
The argument is not about whether or not we should make Pascal entirely
GC'd, but about whether reference counting is better/worse than other
garbage collection techniques if you have a significant amount of GC'd
objects.
The Quake II benchmark was used to "prove" that f
On Friday 25 February 2005 15:18, Eric Grange wrote:
> > No worse that normal memory allocation, if GC is implemented properly.
>
> Actually, that's incorrect, manual memory allocation has a constant
> complexity cost if done properly (each alloc/free has a constant CPU
> cost, whatever the amount
> On 25 feb 2005, at 15:49, Marco van de Voort wrote:
>
> > - Critical parts are often handoptimized by using a lot of non GCed
> > types
> > (like int), this is not a typical programming method for these
> > languages, but outright expert tuning.
>
> Critical paths are also optimized in
On 25 feb 2005, at 15:49, Marco van de Voort wrote:
- Critical parts are often handoptimized by using a lot of non GCed
types
(like int), this is not a typical programming method for these
languages, but outright expert tuning.
Critical paths are also optimized in our compiler to not use
ansist
> > This is simply not true.
> > If you don't belive then check the following:
> > 1. Look with google for Quake rewrittiend into .Net (i.e. GC stuff) --
> > surprise surprise -- difference is neglibile (<20%),
> cost, whatever the amount of objects allocated or their size, just don't
> use old fa
Jamie McCracken wrote:
I did wrote GC in C++ itself. So it binds rather well...
not a compacting one then -
Ref. counting isn't compacting either?
if we use compacting then you lose pointers
and Pchars ergo all the existing bindings would be useless and would
need to be rewritten manually (with
Florian Klaempfl wrote:
Jamie McCracken wrote:
I did wrote GC in C++ itself. So it binds rather well...
not a compacting one then -
Ref. counting isn't compacting either?
Not an issue cause memory allocation is conventional when ref counting.
GCs allocate memory from a managed heap which fragmen
This is simply not true.
If you don't belive then check the following:
1. Look with google for Quake rewrittiend into .Net (i.e. GC stuff) --
surprise surprise -- difference is neglibile (<20%),
Though if you study more what they compare, you'll find that their
.Net version is actually running at
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 13:51, Jamie McCracken wrote:
IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
well.
GC is very inefficient with memory and current implementations te
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 14:57, Jamie McCracken wrote:
It's *much* faster than reference counting everything. Reference
counting is more or less the slowest garbage collection technique there
is (except if only very few objects have to garbage collected). It also
ca
El Viernes, 25 de Febrero de 2005 01:36, Sebastian Kaliszewski escribió:
> You could do partial GC as well. No one forces yo to do GC on everything.
Free Pascal object model is very flexible. If I'm not mistaken, it's
compatible with Delphi so it has the same construction mechanism so it's
possi
On Thursday 24 February 2005 13:51, Jamie McCracken wrote:
> > IMO the best solution for (almost) all of your problems were garbage
> > collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
> > well.
>
> GC is very inefficient with memory and current implementations tend to
> cost
On Thursday 24 February 2005 14:57, Jamie McCracken wrote:
> > It's *much* faster than reference counting everything. Reference
> > counting is more or less the slowest garbage collection technique there
> > is (except if only very few objects have to garbage collected). It also
> > can't deal with
20 matches
Mail list logo
