On 11 May 2014 01:44, Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am 10.05.2014 15:37, schrieb Manu via Digitalmars-d:
>>
>> On 10 May 2014 19:43, Xavier Bigand via Digitalmars-d
>>
>> <digitalmars-d@puremagic.com> wrote:
>>>
>>> I don't know well WP8 models, but this one must run smoothly :
>>>
>>> http://www.nokia.com/fr-fr/mobiles/telephone-portable/lumia1320/fiche-technique/
>>>
>>> Just like Android phones, the battery is huge : 3400mAh
>>> It's the same for CPU : Qualcomm Snapdragon™ S4, dual core 1,7 GHz
>>> Only RAM seems reasonable : 1Go
>>>
>>> And it's maybe easier for Microsoft to do a GC with good performances
>>> cause
>>> they control everything on the OS. There is certainly some specifics
>>> memory
>>> management in the kernel related to the GC. When Google "just" put small
>>> pieces together based on a linux kernel.
>>
>>
>> They don't GC. MS are behind their C++/CX now, which introduced an ARC pointer type '^'.
>>
>
> .NET Applications on Windows Phone 8 make use of both (GC and COM RC).

I don't know any gamedev's who use .NET on WP8. C++/CX was a good step
forward, and addressed one of the primary inhibitors to developer
adoption of WP7.
I don't know a single developer who ever released a WP7 app. WP7 was a
ghost town compared to iOS and Android in terms of developer support.
Lots of people I know are happily supporting WP8 now thanks to C++/CX.

On 5/10/14, 6:33 AM, Manu via Digitalmars-d wrote:
> On 10 May 2014 17:08, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> 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 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.


Andrei

Am 10.05.2014 15:28, schrieb Manu via Digitalmars-d:
> On 10 May 2014 16:53, Paulo Pinto via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> Am 10.05.2014 08:27, schrieb Manu via Digitalmars-d:
>>>
>>> On 10 May 2014 07:05, Wyatt via Digitalmars-d
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> On Friday, 9 May 2014 at 16:12:00 UTC, Manu via Digitalmars-d wrote:
>>>> ...
>>>
>>> The only option I know that works is Obj-C's solution, as demonstrated
>>> by a very successful embedded RTOS, and compared to competition, runs
>>> silky smooth. Indeed iOS makes it a specific design goal that it
>>> should always feel silky smooth, never stuttery, they consider it a
>>> point of quality, and I completely agree. I don't know what other
>>> horse to back?
>>> ...
>>
>>
>> The problem when comparing iOS with Android, is that we aren't comparing ARC
>> with GC.
>>
>> We are comparing a full OS, which we don't know how much ARC is actually
>> used versus standard malloc/new with another OS, which has a
>> so-and-so VM implementation, used mostly software rendering until version
>> 4.1, and care for low end devices was only done in 4.4.
>>
>> If we add Windows Phone to the mix, then we have a .NET stack like Android
>> (WP7 - GC/JIT) or in its sucessor (WP8)  native code generation for .NET
>> (GC) with a COM model for OS APIs (ARC).
>>
>> Both versions of Windows Phone run smoother that many Android phones, even
>> the WP7 ones.
>>
>> Not saying you are not right, just that we need to look at the whole stack
>> when comparing mobile OS, not just GC vs ARC.
>
> Yes, granted. I shouldn't make that sort of comparison. What I am
> really trying to do with such comments, is to insist that it is used
> as a foundation for a very successful RTOS. To say "it's no good. ARC
> can't work. it can never be used as a foundation for a language. but,
> cycles!" and whatever, is kind of ignoring the evidence.
> It's interesting too that you bring Windows phone into the mix,
> because all the WP8 developers I know use microsoft's C++/CX, which
> has the new '^' ARC pointer type (as used intensively by the OS).
> Why did MS abandon GC? It looks like a similar sort of back-peddling
> from their commitment to GC as did Apple, when they started making a
> serious play for the embedded market.

They did not. A Windows Phone 8 application, if coded in .NET still uses a GC for the .NET world.

http://blogs.msdn.com/b/abhinaba/archive/2012/11/08/windows-phone-8-evolution-of-the-runtime-and-application-compatibility.aspx

ARC is used in C++/CX due to the COM nature of WinRT.

After all the Windows Runtime is nothing more than COM with
IInspectable as new derived interface from IUnknown.

Which was actually the original design of .NET, COM+ VOS, before they decided to go MSIL.

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-32-72-38/Ext_2D00_VOS.pdf


If anything, the native side has won the current internal politics war and they are steering the boat back to ahead of time compilation.


>
> C# implies massive GC related issues for realtime and embedded
> software. I have lots of colleagues who rant about it regularly, and
> my experience from 2 weekends back that I shared earlier in this
> thread is a scary slap in the face for me.
>

Where those experiences with Unity/Mono or proper .NET?

Unity still uses Mono 2.6 from 2009, when Mono was under SuSE control. Entity to whom Unity has an agreement.

http://unity3d.com/unity/faq#section-1828
==> What version of Mono is used for 4.x? Can I use all .NET features?

A new generational garbage collector was introduced in Mono with version 2.8 (2010) and improved in consequent releases.

http://www.mono-project.com/Release_Notes_Mono_2.8

It became the default GC in the latest version, currently 3.2.

--
Paulo

On 11 May 2014 02:15, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/10/14, 6:33 AM, Manu via Digitalmars-d wrote:
>>
>> On 10 May 2014 17:08, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> 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. And I thought, if anything, it supported my
argument in the context of D.
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?

Has anyone compared D's GC against 'the fastest tracing collectors'?
What is the difference? Does D fall within 10%?
If not, then chances are, according to this paper, RC would be
superior to the existing GC in terms of performance, as well as
reliability/predictability/functionality (destructors that work, not
incompatible with embedded software).

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.

There are also technical advantages to RC too, like destructors that work, which I find very compelling.

On 5/10/14, 10:03 AM, Manu via Digitalmars-d wrote:
> On 11 May 2014 02:15, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 5/10/14, 6:33 AM, Manu via Digitalmars-d wrote:
>>>
>>> On 10 May 2014 17:08, Andrei Alexandrescu via Digitalmars-d
>>> <digitalmars-d@puremagic.com> 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

Le 10/05/2014 17:58, Manu via Digitalmars-d a écrit :
> On 11 May 2014 01:44, Paulo Pinto via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> Am 10.05.2014 15:37, schrieb Manu via Digitalmars-d:
>>>
>>> On 10 May 2014 19:43, Xavier Bigand via Digitalmars-d
>>>
>>> <digitalmars-d@puremagic.com> wrote:
>>>>
>>>> I don't know well WP8 models, but this one must run smoothly :
>>>>
>>>> http://www.nokia.com/fr-fr/mobiles/telephone-portable/lumia1320/fiche-technique/
>>>>
>>>> Just like Android phones, the battery is huge : 3400mAh
>>>> It's the same for CPU : Qualcomm Snapdragon™ S4, dual core 1,7 GHz
>>>> Only RAM seems reasonable : 1Go
>>>>
>>>> And it's maybe easier for Microsoft to do a GC with good performances
>>>> cause
>>>> they control everything on the OS. There is certainly some specifics
>>>> memory
>>>> management in the kernel related to the GC. When Google "just" put small
>>>> pieces together based on a linux kernel.
>>>
>>>
>>> They don't GC. MS are behind their C++/CX now, which introduced an ARC
>>> pointer type '^'.
>>>
>>
>> .NET Applications on Windows Phone 8 make use of both (GC and COM RC).
>
> I don't know any gamedev's who use .NET on WP8. C++/CX was a good step
> forward, and addressed one of the primary inhibitors to developer
> adoption of WP7.
> I don't know a single developer who ever released a WP7 app. WP7 was a
> ghost town compared to iOS and Android in terms of developer support.
> Lots of people I know are happily supporting WP8 now thanks to C++/CX.
>
+1
WP7 force all gamedev using c++ to rewrite everything, it's completely infeasible. I heard Microsoft propose to paid some studios to port their products, but a lot refuse this offer.

On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote:
> I can't think of many situations where that wouldn't be the case. What
> sort of software is it not an issue to experience intermittent
> freezing?

Batch programs, for example a compiler.

Essentially any program that is not interactive and does not have hard realtime requirements, which is (possibly) most programs.

> Recall too that D has significant opportunity to
> improve on ARC as implemented by other languages,

Compiler improvements to improve on ARC are the same technology as used to improve GC.

You're essentially arguing that one is easy pickings and the other is impractically difficult, but they're actually about the same level.

On 11 May 2014 08:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote:
>>
>> I can't think of many situations where that wouldn't be the case. What sort of software is it not an issue to experience intermittent freezing?
>
>
> Batch programs, for example a compiler.

Indeed, that was the only one that came to my mind. GC might be better
for shell apps because it is unlikely that a collect will ever occur,
it'll usually terminate before it gets to it, but there's certainly no
hard-dependency on GC in this use case.
This is truly a niche usage case though, and yet, it also has no
particular incompatibility with any choice of technology, only a
slight preference towards GC for the reason that you never bother
freeing memory in DMD.

If you're prepared to label the largest entertainment industry on the planet a niche, then this sort of work is a hyper-niche... and regardless, not actually incompatible with any particular option.

I'd like to consider this form of software for a moment though.
Assuming the GC was a library offered beside the language, DDMD for
instance would be able to make particularly easy and convenient use of
it.
Shell apps by comparison _are_ generally small and self-contained.
It's far more reasonable to suggest that a shell app can adopt
specific and custom allocation patterns when the code is relatively
small, function is specific, the life is short, the probability of
running into incompatible 3rd party libraries is almost zero by
comparison.
How many libs does DMD link?

This thought has actually left me slightly concerned, that as much as Andrei is accusing me of unreasonably arguing my "staunch niche position that ignores factual realities" (a somewhat offensive and dismissive notion), that there might be some silent, but significant (perhaps even unconscious) element of the same in reverse.


> Essentially any program that is not interactive and does not have hard realtime requirements, which is (possibly) most programs.

I'm hard pressed to think of any software I see people using every day which isn't realtime in some sense. The majority of relevant software today is on embedded devices, and visceral touch-based UI is key to their impression of quality.


>> Recall too that D has significant opportunity to
>> improve on ARC as implemented by other languages,
>
>
> Compiler improvements to improve on ARC are the same technology as used to improve GC.
>
> You're essentially arguing that one is easy pickings and the other is impractically difficult, but they're actually about the same level.

Are they? This is the first I've heard such a claim. If that's the
case, then that why is there an argument? That work just needs to be
done, and we can experiment with both targets...
I can fairly easily visualise the path to ARC, but by all prior
reports I've heard, awesome GC is practically incompatible with D for
various reasons. There were discussions about different advanced
options by the experts at dconf last year, which seemed to hit various
impasses.
And I'm still not even sure if 'awesome GC' will solve my problems?
Will it? No matter how awesome it is, it seems conceptually
incompatible with my environment.
I keep saying, I'm more than happy to be proved wrong (really!), but
until someone can, then it's unfair to dismiss my arguments so
easily... and I just don't think it's that unreasonable. ARC is an
extremely successful technology, particularly in the
compiled/native/systems language space (OC, C++/CX, Rust). Is there
actually any evidence of significant GC success in this space?
Successes all seem to be controlled VM based languages like Java and
C#; isolated languages with no intention to interact with existing
native worlds. There must be good reason for that apparent separation
in trends?

On 11 May 2014 03:54, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/10/14, 10:03 AM, Manu via Digitalmars-d wrote:
>>
>> 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.

As I've said many times, I'm really not married to ARC... it just
makes sense. In the years I've been hanging around here, I'm yet to
see anyone present a realistic path for D towards an acceptable GC
solution.
If anybody can do that, I'll reconsider my position. But it seems it's
becoming less and less likely to me.

What I know is that there is a solution which has a proven and extremely successful track record in native languages and embedded/realtime systems, and even solves ancillary problems like destructors while at it. But most importantly, it doesn't exclude any classes of software by nature.

If ARC were a foundation for D, I wonder if there's opportunity for programs that may elect to disable the RC and leave the work exclusively to the backing cycle collector, in the same way that I might disable the cycle collector and take manual responsibility for weak references...?

I may argue from a biased perspective, but placing more weight on some
particular negative qualities of a technology is not unreasonable when
they represent a showstopper. Which part of my issue with the GC is
factually incorrect? All it would take is for anyone competent to tell
me how a magic GC (which is compatible with D) will stop freezing in
the low/no-memory environment, and I'll shut up.
Even controlling it... I was initially wishing for something like an
incremental garbage collector, which I could allocate a maximum
periodic time-slice (1ms or less) on a regular basis. Not only was it
agreed that this is basically impossible (a bunch of collection
ground-work would need to be repeated at the start of each
micro-collect, probably representing more time than the total
time-slice... iirc), but it almost certainly loses any raw performance
advantage over ARC in such a case anyway, and it becomes moot.

On 11 May 2014 08:40, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/10/2014 8:54 AM, Manu via Digitalmars-d wrote:
>
>> Recall too that D has significant opportunity to
>> improve on ARC as implemented by other languages,
>
> You're essentially arguing that one is easy pickings and the other is impractically difficult, but they're actually about the same level.

That's not actually what I was arguing at all. I was arguing that D's ARC offering would likely be superior to any that have come before, due to inherent advantages in the language, and by all reports, D is incapable of having the worlds best GC implemented successfully for various reasons.

If it is possible to implement the worlds best GC in D, it's still not
a done deal though. We still need to consider; does the worlds best GC
remain incompatible with my workload at a fundamental level? What do
we do about destructors? If ARC is within 10% of the worlds best GC,
and both are equally attainable in D's context, is 10% a fair price to
pay for a more inclusive technology?
Who is it that will declare that 10% difference a deal-breaker?
(they're obviously not here now, since D's existing GC is not in that
ballpark)
With them in mind, and upon an ARC platform, can we offer those users
the GC as a library? Or perhaps a mechanism to disable RC code
generation in their local code and falling back upon the
cycle-collecting GC already in place to pick up the task?