On 5/10/14, 10:03 AM, Manu via Digitalmars-d wrote:
On 11 May 2014 02:15, Andrei Alexandrescu via Digitalmars-d
<[email protected]> wrote:
On 5/10/14, 6:33 AM, Manu via Digitalmars-d wrote:
On 10 May 2014 17:08, Andrei Alexandrescu via Digitalmars-d
<[email protected]> wrote:
On 5/9/14, 11:27 PM, Manu via Digitalmars-d wrote:
ARC overhead would have no meaningful impact on performance, GC may
potentially freeze execution. I am certain I would never notice ARC
overhead on a profiler, and if I did, there are very simple methods to
shift it elsewhere in the few specific circumstances it emerges.
This is very, very, very wrong. -- Andrei
Is there any evidence to support that assertion?
Of course, and I've shown it numerous times, only for it to be blissfully
ignored. Probably the most recent and influential work on it is
http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf
of which FIRST sentence is "Despite some clear advantages and recent
advances, reference counting remains a poor cousin to high-performance
tracing garbage collectors." The paper reviews previous work on the matter,
ALL of which shows that RC is behind GC in speed, and presents (for the
first time in 2013) new work that brings about parity of RC with GC.
I saw that paper before.
Then the right thing is to integrate it within one's worldview. It is
difficult to reconcile your assertions and questions with the claim that
you have read and internalized existing work on the topic.
And I thought, if anything, it supported my
argument in the context of D.
It doesn't seem that way to me. Your arguments so far seem to come from
a staunch niche position that ignores factual realities and has no
concern for the larger environment. Some of such arguments are factually
incorrect, and just the minimal amends and qualifications are not
sufficient.
The next sentence goes on to list the advantages of RC (issues we have
wrestled with, like destructors), and then goes on to say the recent
awesome RC is within 10% of "the fastest tracing collectors".
Are you suggesting that D's GC is among 'the fastest tracing
collectors'? Is such a GC possible in D?
I believe it is.
Has anyone compared D's GC against 'the fastest tracing collectors'?
What is the difference? Does D fall within 10%?
In all likelihood, no.
If not, then chances are, according to this paper, RC would be
superior to the existing GC in terms of performance,
I disagree.
as well as
reliability/predictability/functionality (destructors that work, not
incompatible with embedded software).
I partially agree, but this is getting rather difficult to assess. Let's
say I'd agree it's a valid viewpoint.
If an awesome RC is implementable in D, but an awesome GC is not, then
I can't see that even any performance argument can remain in the
debate. They are talking specifically about a GC-backed-RC too, to
handle cycles, so their implementation does not come at any cost to
safety or added complexity for users, and has the key advantage that
people like me may have the option to disable the cycle collector and
take manual responsibility if desired.
I have many colleagues who work on phones. The patterns I see are that
the iOS guys who use Obj-C never complain about it, and the GC guys
are often struggling with it.
The bias in gamedev is strongly towards iOS too, so that should be a
more populous group to draw samples from.
As competent engineers we can't afford to be ignorant of the existing
research and practice showing a much more complex tradeoff space than a
black/white distinction. We also can't do the capital mistake of engineering
- the beauty of the part at the expense of the beauty of the whole.
There is a black/white distinction though.
It you can't make the freezing go away, it is _incompatible_ with
certain classes of software.
I don't care what the performance difference is when this is the case.
If one option is incompatible and the other is not, then there is no
tradeoff.
Of course it would be nice to have better support for reference
counting. My understanding is that you advocate that reference counting
would be compulsive, which would preclude the GC option.
Andrei
