[fpc-devel] Modernising Pascal

[Sebastian Kaliszewski]

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 performance wise too.

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%),
2. Look for Ocaml -- it's a heavyly GC-ed compiled language, and it's fast.


>
> GC gets a lot slower with the more objects you create.
>

No worse that normal memory allocation, if GC is implemented properly.


> Mixing unmanaged with managed code cause severe performance issues
> (marshalling penalties calling ummanaged c functions)
>
> Interoperability with C gets increasingly difficult. Writing bindings
> becomes much more complicated and time consuming.


I did wrote GC in C++ itself. So it binds rather well...

>
> GC is therefore a poor choice for a high performance language IMHO.

There are live examples to the contrary. If anything, then refcounting is a 
poor choice for such language -- it's really slow, and when multithreading 
avareness is needed then is terribly slow. Once I compared multithreading 
aware and surely well optimised boost++ refcounter with my primitive GC, 
the very samy app using unoptimised GC was 2 times faster.


In case of FPC main advantage of GC for autotatically managed stuff would be 
avoiding of putting the unwinding code by the compiler (those implicit try 
.. finally thigs). Main disadvantage is that moment of resource freeing is 
indefinite, and this would break exiting code (hence it's unacceptable).
 
rgds
-- 
Sebastian Kaliszewski