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.
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
