[fpc-devel] Modernising Pascal

[Jamie McCracken]

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 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.


Ocaml is a functional lanaguge. Procedural languages tend to not work as 
efficiently with GCs from what I have seen.

> 
> 
> 
>>GC gets a lot slower with the more objects you create.
>>
> 
> 
> No worse that normal memory allocation, if GC is implemented properly.

Show me one that works "properly" with procedural lanaguages (java, C#, 
pascal etc) otherwise it just appears hypothetical. I dont doubt some 
languages are more suitable for this like LISP.


> 
> 
> 
>>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...

not a compacting one then - 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 (without the aid of H2pas!)

> 
> 
>>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.

Okay maybe its not so clear cut but Im fairly sure that to implement 
things correctly we would have to GC everything and the overall overhead 
might cost more than a partial ref counting of some Tobjects.

However if your confident you can write a modern GC that would work very 
efficiently with FPC then by all means be my guest - I would be very 
interested to see it. Im not opposed to GC ing pascal if the 
performance/memory usuage is reasonably good.


jamie.