[swift-evolution] What about garbage collection?

Tue Feb 9 11:26:39 CST 2016

For the server side it depends on scale.  

When you talk about large scale deployments like Facebook and Google - the cost savings from an energy efficient datacenter is actually quite substantial (50%).  [and of course the savings on racks and racks of hardware]

Of course it usually does not become an issue or to the forefront UNTIL they become hugely successful and then it is a little late in the cycle.

Being able to say your green - priceless.  

For a banking / J2EE application - they probably won’t care or worry about it. (especially when you cannot do anything in regards to something that will likely take a majority of the performance requirements - Oracle / DB2).

The thing is that IF performance, energy efficient is not an issue - they would not move to a language closer to the metal and just have it run on a JVM language anyway.

IF performance is an issue or energy efficient then using ARC / Swift is potentially a viable solution.  [of course not if they use Oracle or DB2 databases right now since driver support would be spotty].

There are bigger issues at play though for Swift to be considered a server programming language.  An abend to the system does not affect one user it potentially brings a business to it’s knees…. so language features that mitigate the likelihood of programmer faults causing that situation would be more of an issue.

For server development my preferred development environment would be an LLVM language that provides better support for the functional paradigm/concepts, is very type safe, has proper database driver support for large commercial databases…. but I don’t see any options on the horizon….  The lack of GC would not be a deal breaker.

> On 2016-02-10, at 0:04:36, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Since GC is getting a lot of hate on this thread, I’ll throw it a little love — though ultimately I agree that it’s probably not right for Swift.
> 
> There’s no denying that GC eases programmer burden. Having to explicitly break every cycle takes effort, and sometimes undermines abstraction. There’s a tradeoff here: more deterministic / consistent performance in exchange for developer time. ARC keeps that effort pretty low, but it’s nonzero.
> 
> As Jean-Denis noted:
> 
>> On Feb 9, 2016, at 8:35 AM, Jean-Denis Muys via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I find it interesting that the commonly accepted wisdom is that GC is the right thing to do. To quote but one blog post I’ve read:
>> 
>>> It’s a long since resolved dispute, and GC won. I don’t want Steve Jobs to reach out from the grave and drag us back to the 70s. There’s nothing special about mobile phones: they are more powerful than the computers that GC won on in the first place.
> 
> …GC has indeed pretty much won on the server side. That makes sense, because — at least as I understand it — the downsides of GC are much less severe there:
> 
> Quadrupling physical RAM is far less of a concern on a server than it is on a mobile device.
> Most servers (1) are not CPU bound and (2) experience bursty load, and thus can absorb GC expense while blocking on I/O and/or in the quite microseconds between requests.
> When servers do become CPU or RAM bound, one can always add more nodes — and for most companies, that’s cheaper than paying for more developer effort.
> Servers tend to have a pool of long-lived, relatively static allocations, plus a rapid stream of short-lived allocations that last only as long as single requests. This duality maps neatly to generational garbage collection.
> Furthermore, a server wants to get a response out the door as fast as possible when a request comes in, and it thus makes sense to defer ref counting and deallocation costs for those short-lived allocations — exactly as GC does — until after the response goes out, even if that comes at the cost of RAM and greater total CPU usage.
> This high turnover also mitigates (though does not eliminate) the problem of cache thrash. The objects in the short-term pool tied to request lifecycle that GC needs to traverse frequently aren’t going to live long anyway, so there’s less value in keeping them cached.
> 
> Yes, maybe our data centers would be greener if we all ditched GC entirely, but the bottom line is that right now, the developer productivity advantages of GC clearly outweigh the costs … on the server. As long as our time remains expensive and servers and electricity remain cheap, this will remain true.
> 
> That whole equation changes on mobile devices.
> 
> Jean-Denis mentioned “our Apple island” where GC is frowned upon. It’s not just Apple. That island has other inhabitants: video game developers. That’s illuminating, and in ways that extend beyond memory management. One of the original brilliances of the iPhone was that it realized mobile apps have more in common with video games than with the enterprisey fill-in-the-text-field apps that are the home base of most UI stacks. This insight pervades the platform, and is a lot of what makes the iOS devices feel as polished as they do.
> 
> GC is probably not right for iOS devices, or for Swift. Swift made a mindful tradeoff here, and it was probably the right tradeoff. However, we should remember that there was a tradeoff, and keep an eye on what we gave up.
> 
> • • •
> 
> That said, I was a little surprised to hear Chris Lattner rule out any form of cycle detection for Swift. I figured that it might eventually arrive in some form, albeit limited.
> 
> No time for it at the moment, but I have some thoughts about places where the lack of GC gets in the way of clean code and good abstraction. Closure captures are one such pain point.
> 
> It would be nice examine those problems and tackle them in the Swift spirit of “look like high level, compiles like low level” abstractions.
> 
> • • •
> 
>> On Feb 9, 2016, at 9:32 AM, Ondrej Barina via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> GC does not have performance problems on server side??
>> Please tell that to my colleges who are spending 50% of their time
>> analysing and tweaking GC in java after every release of new versions.
> 
> Radek did not say “does not have performance problems.” His words were:
> 
>>> much less of an issue for server side stuff
> 
> …and he was correct. Ondrej, it sounds like you’re in one of the rare situation where CPU and RAM really are the bottlenecks in the server farm. That’s not typical in my experience.
> 
> Cheers,
> 
> Paul
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160210/da2ddcd8/attachment.html>