[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Goffredo Marocchi]

+Swift Evolution


By the way, I was genuine when I said thank you because reading how Rust
evolved in those two aspects is very insightful.

On Thu, Aug 11, 2016 at 6:54 PM, Goffredo Marocchi <panajev at gmail.com>
wrote:

> Hello Kevin,
>
> I may be wrong in my equating support for fibers to green threads (and the
> runtime cost of supporting them), but I do have seen and linked to a
> presentation of the use and more than trivial benefits to Naughty Dog's
> engine in utilising the 8 Jaguar x86 cores in the PlayStation 4 CPU.
> Although like you said, it did not come for free or without evident pain
> points for them.
>
> On Thu, Aug 11, 2016 at 6:50 PM, Kevin Ballard <kevin at sb.org> wrote:
>
>> I'm confused by your email. Rust is all about performance, and embedded
>> devices are one of the targets for Rust. And I can't think of any language
>> that uses green threading that is appropriate for constrained devices (e.g.
>> Go definitely isn't appropriate for that). One of the arguments for getting
>> rid of green threading in Rust is that the extra runtime complexity imposed
>> a performance cost.
>>
>> -Kevin
>>
>> On Thu, Aug 11, 2016, at 10:36 AM, Goffredo Marocchi wrote:
>>
>> Thanks Kevin, I think they have accepted that they do not need to enter
>> every segment of computing so the extra performance they could get on some
>> devices is not worth the risk and the complexity it brings. Not everyone is
>> trying to cram complex 3D experiences at 60-90+ FPS on a console like
>> constrained devices and I guess Rust is not targeting that right now :).
>>
>> On Thu, Aug 11, 2016 at 6:12 PM, Kevin Ballard via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> For anyone interested in reading more about Rust's decisions, here's two
>> links:
>>
>> The email about abandoning segmented stacks:
>> https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html
>>
>> The RFC to remove green threading, with motivation:
>> https://github.com/aturon/rfcs/blob/remove-runtime/active/00
>> 00-remove-runtime.md
>>
>> -Kevin Ballard
>>
>>
>> On Tue, Aug 9, 2016, at 01:28 PM, Kevin Ballard wrote:
>> > The Rust language used to use a green thread model like Go (actually it
>> exposed a configurable threading interface so you could choose green
>> threads or OS threads). It also used segmented stacks like Go did. Over
>> time, Rust ended up dropping the segmented stacks because it significantly
>> complicated FFI without providing much, if any, benefit (and IIRC Go
>> followed suite and dropped segmented stacks somewhere around version 1.5),
>> and then a little while later Rust dropped green threads entirely. If you
>> can find them, there are lots of discussions of the pros and cons that were
>> documented during this process (on mailing lists, in IRC, possibly on
>> Discourse, there's probably at least one post about it in the Rust
>> subreddit, etc). But ultimately, it was determined that keeping this
>> ability significantly complicated the Rust runtime and it provided almost
>> no benefit. The OS is already really good at scheduling threads, and
>> there's no memory savings without segmented stacks (though the OS will map
>> virtual pages for the stack and only allocate the backing physical pages as
>> the memory is touched, so even if you have a 2MB stack, a new thread will
>> only actually allocate something like 8kb). And there are some pretty big
>> downsides to green threads, such as the fact that it significantly
>> complicates the runtime since all I/O everywhere has to be nonblocking and
>> it has to be transparent to the code, and FFI ends up as a major problem
>> (even without segmented stacks), because you have no idea if an FFI call
>> will block. Green threading libraries end up having to allocate extra OS
>> threads just to continue servicing the green threads when the existing
>> threads are potentially blocked in FFI.
>> >
>> > So ultimately, green threads really only make sense when you control
>> the entire ecosystem, so you can ensure the whole stack is compatible with
>> green threads and won't ever issue blocking calls, and even there there's
>> not much benefit and there's a lot of complexity involved.
>> >
>> > -Kevin Ballard
>> >
>> > On Tue, Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution
>> wrote:
>> > > I'd like to inquire as to what the Swift team thoughts on Go's
>> concurrency model are?  I'm not referring to convenience of the 'go'
>> keyword and nor am I referring to how the language handles Channels, both
>> of which being what most folks associate with it.  Rather, I'd like to ask
>> about the language's use of Green Threads and how the runtime handles the
>> heavy lifting of multiplexing and scheduling them.  What are some of the
>> strengths and weaknesses the Swift team sees to Go's approach?
>> > >
>> > > Dan
>> > >
>> > > (DISCLAIMER: I'm posting this for academic reasons, not as a pitch.
>> While the Swift team's responses may inform opinions on the matter, I do
>> not want this to turn into a 'this is how I think Swift should do
>> concurrency' debate.  That discussion will come when it comes.)
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution at swift.org
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> 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/20160811/0bf2c8b0/attachment.html>