On Wednesday, 2 January 2013 at 12:32:01 UTC, deadalnix wrote:
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).
And the problem is that D uses GC as a sledgehammer. A GC
shouldn't be used for everything. If it is used for stuff it
works well at and not for anything and everything, then it
becomes useful.
Because the GC is used for everything in D it gets clogged up
with stuff like simple object allocation(which, of course, there
is a way to get around, but not easily) which effects it's
performance.
For example, suppose the GC was used only for closures and
nothing else. In this case, since closures are not used that much
compared to other things, the GC would have minimal impact on
performance. It could probably be ran once a month and not have
memory issues.
But since the GC does everything, you have to run it much more
often, which means the amortization is much higher regardless if
we even use closures.
Ultimately the best option is control. If we were not "forced" to
use the GC for everything but could enable it for different
things, then we could tweak it for best performance.
And why does Phobos/runtime require the GC in so many cases when
it could just use an internal buffer? So much effort has been put
in to make the GC work that it simply has neglected all those
that can't use it as it is.
Basically doing the exact opposite by making the GC more
ubiquitous in D. Makes people that have no problem with the GC
happy but those that do have problems just get more and more
frustrated.
What has happened is the GC has made the library writers lazy. It
doesn't belong in 99% of Phobos.
