On Wednesday, 2 January 2013 at 11:41:33 UTC,
DythroposTheImposter wrote:
I'm interested in how the new LuaJIT GC ends up performing.
But overall I can't say I have much hope for GC right now.
GC/D = Generally Faster allocation. Has a cost associated with
every living object.
True, however, GC + immutability allow new idoms that are plain
impossible in a non GC world, and that are really efficients at
reducing copies and allocations (and used in many high perf D
libs).
The comparison you present here fail to take this into account.
C++ = Generally Slower allocation, but while it is alive there
is no cost.
Counting reference have a cost. Plus, when the heap grow, the
object that dies together tend to grow as well, which cause
pauses.
Latency contrived programs, like video games, tends to avoid
allocation altogether because of this. This obviously work both
with GC and reference counting.
So as the heap grows, the GC language falls behind.
That is more subtle than that. Reconsider what I wrote above, for
instance that GC + immutability can be used to reduce allocations
(so live heap size). You'll also have to consider that GC can be
concurrent, when reference counting usually cannot (or loose some
of its benefit compared to GC).
This seems to be the case in every language I've looked at
this uses a GC.
Most GC language lack proper memory management, and sometime have
design choice that are a nightmare for the GC (java have no value
type for instance). You are comparing here way more than simply
GC vs other memory management.
Considering the pro and cons of each, an hybrid approach seems
like the most reasonable thing to do in any high performance
program. Which is possible in D because of GC.free .
