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 swappe
Jamie McCracken wrote:
> The problem with GC is the lifetime of (dead) objects is significantly
> extended under GC. This means it hogs more memory for much longer.
> Memory allocation is also potentially slowed as a result of more objects
> remaining allocated on the heap so less chance of holes
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 cou
> -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
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 counting occurs wi
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.
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
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 p
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 Wi
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 too.
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');
st
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 improve
Jamie McCracken wrote:
> 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.
I'd suggest Oberon or a sim
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 Comple
> Marco van de Voort wrote:
> > The constructs are not that frequent, so typing is not limited. I do not
> > agree on
> > the "clearer" part also.
> >
> >>From low to high is more clear than IN, since that says nothing about order.
>
>
> Well for..in is not a replacement for the conventional Fo
Marco van de Voort 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 more compact (it works f
Jamie McCracken wrote:
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
l
> 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 w
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 m
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
Jamie McCracken wrote:
Florian Klaempfl wrote:
So if you look at this, you know why classes aren't ref. counted. And
there is no chance to avoid the code generated for the interface.
Yes that does look very bad but if you passed a pointer to the ref
counted object as the function arguement then
Florian Klaempfl wrote:
So if you look at this, you know why classes aren't ref. counted. And
there is no chance to avoid the code generated for the interface.
Yes that does look very bad but if you passed a pointer to the ref
counted object as the function arguement then you would not get all t
> 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
> >>TOb
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 to
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 re
> 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.
Could you define modern? Nearly all "modern" lan
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 saf
> 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 TO
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 :)
> (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
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
48 matches
Mail list logo
