DrDiettrich wrote:
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations tend to
cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference
peter green wrote:
one thing i have heared (i don't use garbage collected languages much so
i've never seen this myself) is that the GC gets some CPU time and starts
causing stuff to be swapped in. This slows other threads down which gives
the GC more CPU and causes more stuff to be swapped
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
Sent: 26 February 2005 03:34
To: FPC developers' list
Subject: Re: [fpc-devel] Modernising Pascal
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations
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
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
DrDiettrich wrote:
My main gripes with Delphi/pascal is its additional verbosity and
somewhat tedious coding practices which seem superfluous in some cases.
Now I dont mind typing a bit extra to make code cleaner and more legible
but I have a few ideas which would reduce needless typing and
On Thu, 24 Feb 2005, Jamie McCracken wrote:
It might be better to do this in an IDE and get it to add the try..finally
crap.
EG if I say use the @ symbol to indicate a variable should be auto created
and destroyed then I could have :
var st@, st2@ : tstringlist;
begin
st.add('some text');
On 24 feb 2005, at 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 performance wise
I do need an IDE anyhow for container based GTK2/Gnome2/Glade apps so
maybe I ought to start writing one that implements this.
Why don't you see if you can get this implemented as an add-on in
Lazarus ? You get the rest of the IDE for free.
In the short term yes (although I use delphi 5 under
Jonas Maebe wrote:
On 24 feb 2005, at 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
Marco van de Voort wrote:
The best solution I can
think for this is to reference count non-component classes. This should
be safe for TObjects but obviously not for Tcomponent descendants (cf
circular reference problem) so a protected variable could be added to
TObject to specify whether to
Jamie McCracken wrote:
Marco van de Voort wrote:
The best solution I can think for this is to reference count
non-component classes. This should be safe for TObjects but obviously
not for Tcomponent descendants (cf circular reference problem) so a
protected variable could be added to TObject
Marco van de Voort wrote:
The best solution I can
think for this is to reference count non-component classes. This should
be safe for TObjects but obviously not for Tcomponent descendants (cf
circular reference problem) so a protected variable could be added to
TObject to specify
Marco van de Voort wrote:
2. For Each. Its in Delphi 2005 and every modern language implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the local var
section. No need
On 23 feb 2005, at 14:04, Jamie McCracken wrote:
My mistake it actually avoids initialising the loop variable rather
than not declaring it:
for i in myarray do
myarray[i] := 0;
as opposed to
for i := low(myarray) to high (myarray) do
myarray[i] := 0;
I think the for..in is much clearer and
My mistake it actually avoids initialising the loop variable rather than
not declaring it:
for i in myarray do
myarray[i] := 0;
as opposed to
for i := low(myarray) to high (myarray) do
myarray[i] := 0;
I think the for..in is much clearer and more compact (it works for
On Wed, 23 Feb 2005 13:45:51 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the
local var section.
It already exists. Example:
i:=0;
Place cursor on i and press Code Completion
Hi,
Just wandering if any of you are interested in modernising Pascal which
is looking quite dated when compared to modern languages like Python. I
note free pascal supports a variety of pascal dialects but none of them
are particular modern.
My main gripes with Delphi/pascal is its additional
(note I did not use a T in front of StringList so as to distinguish it
from non-base types and also to maintain backwards compatibility with
existing code that uses TStringList conventionally)
jamie.
Are you always drunk?
___
fpc-devel
Jamie McCracken wrote:
Hi,
Just wandering if any of you are interested in modernising Pascal which
is looking quite dated when compared to modern languages like Python.
Oh, the language which is on fortran 77 level regarding formatting?
Sorry, couldn't resist :)
1. Memory management. Delphi is quite incosistent here by allowing
component classes to be auto managed (via their owner) whilst
non-component class have to be manually managed. The best solution I can
think for this is to reference count non-component classes. This should
be safe for
peter green wrote:
1. Memory management. Delphi is quite incosistent here by allowing
component classes to be auto managed (via their owner) whilst
non-component class have to be manually managed. The best solution I can
think for this is to reference count non-component classes. This should
be
37 matches
Mail list logo
