LLVM is getting actual coroutine support, do you think it is going to help Swift started in this direction?
Sent from my iPhone > On 11 Aug 2016, at 22:17, Slava Pestov <spes...@apple.com> wrote: > > >> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Thanks for the concise and clear review of green threads :). I can >> understand the concerns of runtime implementation when the runtime of the >> language is replacing the kernel scheduler. >> >> Sent from my iPhone > > One interesting thing that you can do to get around the limitations is to run > blocking system calls in their own special thread pool off to the side. This > is how node.js deals with blocking I/O I believe. However this seems like it > would add a lot of overhead, and it’s probably not a direction we want to go > in with Swift. Of course nothing prevents users from developing their own > thread pool libraries, if they so choose. Even coroutines would not be too > difficult to do with Swift, since we don’t do anything funny with the > callstack. So the usual tricks should work. > > Slava > >> >>> On 11 Aug 2016, at 19:09, Kevin Ballard <ke...@sb.org> wrote: >>> >>> AIUI, fibers are basically coroutines. Even the Naughty Dog presentation >>> says that fibers are run on threads, and you have to make an explicit call >>> to switch between fibers. Looking at Ruby's Fiber type, that's also an >>> explicit coroutine, where you actually yield up a value when you yield your >>> fiber (which is exactly what coroutines do). >>> >>> So basically, green threading is preemptive multithreading where the >>> preempting is done in user-space by the runtime (so it only happens at >>> specific points where your code calls back into the runtime, but it can >>> happen at any of those points), and multiple green threads get scheduled >>> onto the same OS thread, whereas fibers is cooperative multithreading where >>> your code explicitly yields back to the runtime to switch fibers. >>> >>> Of course I could be wrong, but that's the impression I got after reading a >>> few different things about Fibers. >>> >>> -Kevin >>> >>>> On Thu, Aug 11, 2016, at 10:54 AM, Goffredo Marocchi 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 <ke...@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@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/0000-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@swift.org >>>>> > > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
