Smart pointers instead of GC?

[Adam Wilson]

On Mon, 03 Feb 2014 16:24:52 -0800, NoUseForAName <no at spam.com> wrote:

> On Monday, 3 February 2014 at 23:00:23 UTC, woh wrote:
>>  ur right I never thought of that, I bet all them game devs never  
>> thought of it either, they so dumb.  I bet they never tried to use a  
>> GC, what fools!  Endless graphs of traced objects, oh yes oh yes!  It  
>> only runs when I allocate, oh what a fool I've been, please castigate  
>> me harder!
>
> Also people should consider that Apple (unlike C++ game devs) did not  
> have a tradition of contempt for GC. In fact they tried GC *before* they  
> switched to ARC. The pro-GC camp always likes to pretend that the  
> anti-GC one is just ignorant, rejecting GC based on prejudice not  
> experience but Apple rejected GC based on experience.
>
> GCed Objective-C did not allow them to deliver the user experience they  
> wanted (on mobile), because of the related latency issues. So they  
> switched to automated ref counting. It is not in question that ref  
> counting sacrifices throughput (compared to an advanced GC) but for  
> interactive, user facing applications latency is much more important.
>

That may be the case, but StackOverflow shows that ARC hasn't been panacea  
in Apple land either. Way to many people don't understand ARC and how to  
use it, and subsequently beg for help understanding heisenleaks and weak  
references. ARC places a higher cognitive load on the programmer than a GC  
does. And Android runs just fine with GC'ed apps, but ARC guys don't want  
to talk about Google's successes there.

> You can do soft-real time with GC as long as the GC is incremental (D's  
> is not) and you heavily rely on object reuse. That is what I am doing  
> with LuaJIT right now and the frame rates are nice and constant indeed.  
> However, you pay a high price for that. Object reuse means writing  
> additional code, makes things more complex and error-prone, which is why  
> your average app developer does not do it.. and should not have to do it.
>
> Apple had to come up with a solution which does not assume that the  
> developers will be careful about allocations. The performance of the  
> apps in the iOS app store are ultimately part of the user experience so  
> ARC is the right solution because it means that your average iOS app  
> written by Joe Coder will not have latency issues or at least less  
> latency issues compared to any GC-based solution.
>
> I think it is an interesting decision for the D development team to  
> make. Do you want a language which can achieve low latency *if used  
> carefully* or one which sacrifices maximal throughput performance for  
> less latency issues in the common case.
>
> I see no obvious answer to that. I have read D has recently been used  
> for some server system at Facebook, ref counting usually degrades  
> performance in that area. It is no coincidence that Java shines on the  
> server as a high performance solution while Java is a synonym for dog  
> slow memory hog on the desktop and mighty unpopular there because of  
> that. The whole Java ecosystem from the VM to the libraries is optimized  
> for enterprise server use cases, for throughput, scalability, and  
> robustness, not for making responsive GUIs (and low latency in general)  
> or for memory use.
>

Ahem. Wrong. See: WinForms, WPF, Silverlight. All extremely successful GUI  
toolkits that are not known for GC related problems. I've been working  
with WPF since 2005, I can say the biggest performance problem with it by  
far is the naive rendering of rounded corners, the GC has NEVER caused a  
hitch.

> If D wants to be the new Java GC is the way to go, but no heap  
> allocation happy GCed language will ever challenge C/C++ on the desktop.
>

So that's why nearly every desktop app (for Windows at least, but that's  
the overwhelming majority) that started development since .NET came out is  
written C#?

> Which reminds me of another major company who paddled back on GC based  
> on experience: Microsoft. Do you remember the talk back then .NET/C#  
> were new? Microsoft totally wanted that to be the technology stack of  
> the future "managed code" everywhere, C/C++ becoming "legacy". However,  
> C# ended up being nothing more than Microsoft Java, shoveling enterprise  
> CRUD in the server room. Microsoft is hosting "Going Native" conferences  
> nowadays, declaring their present and future dedication to C++ (again)  
> and they based the new WinRT on ref counting not GC.
>

This is primarily due to Internal Microsoft Politics rather than any  
desire of the Microsoft Developer Community to jettison .NET. I won't dive  
in to those right now, there are plenty of places on the web that tell the  
story better than I could.

I remember sitting in the Build 2011 Keynotes thinking "They just cost  
themselves two years, minimum." Turns out I my estimate was low. They have  
tried in vain for over two years get devs to write WinRT apps using  
C++/CX. They've also failed miserably. I forget the exact percentage, but  
the overwhelming majority if WinRT apps are written in ... C#, most of the  
rest are VB.NET, only something like 3% of all apps in the Windows Store  
are C++/CX. Server apps are written almost universally in .NET languages,  
such that they didn't even bother making C++/CX capable of building  
servers. Microsoft recently had to do a mea culpa and reinvest in .NET  
(Build 2013).

Microsoft might be trying to get us all to move to C++ with Hats, but they  
are failing miserably in real terms, despite what the rah-rah section of  
Microsoft would have you believe.

At the end of the day, the overwhelming majority of the MS Dev Community  
it quite happy with the performance of the GC. They even gave us more  
performance tweaking options in the latest release. You'll not find any  
ARC fans in that world. And given that the MS Dev Community eclipses  
Apple's in real terms, that's important to note.



-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator