> > 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 linked-lists memory managers), while theoretically-
> best-case-GC still isn't constant time (and practical ones are more
> like O(n?)), GC memory allocation and heap compaction patterns are quite
> cache unfriendly and will require partial or total freezes while they happen.
In the stories about old software that is updated or reimplemented with
GC/.NET/Java there are typical several caveats:
- the working set with boehm GC's is typically at least twice as large(good
rule of thumb) as manual allocation. Using non GCed types, explicit GC
calls at timed points and setting refs to NIL can improve this slightly, but
this is tuning, not a fair comparison.
- Startup time is also nearly always affected severely, even if normal
program execution is bearable
- 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.
- Older applications are often not CPU limited, but have a bottleneck
somewhere else. So there is a hidden CPU performanceloss in the
comparison, since the managed app _is_ CPU limited apparently.
- (rare) HT/SMP usage.
Same with GC faqs.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
