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
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 a lot
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
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
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
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
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
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
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 fashioned
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
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 of
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
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:
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
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 managers
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
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
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
18 matches
Mail list logo
