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

[Paulo Faria via swift-evolution]

Just so you know, it’s already possible to use coroutines in Swift with Venice.

https://github.com/VeniceX/Venice 


> On Aug 11, 2016, at 7:36 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> Guys, as I have already mentioned a couple of times in this thread, let’s 
> please not turn this into a explicit discussion about how Swift could do 
> concurrency.  That discussion is at least a few more months out, especially 
> with memory ownership ala Rust/Cyclone being explored for Swift 4.  I 
> intended this thread to be about general language & runtime design theory 
> above all else, and I’m sure the team is already quite weary of folks jumping 
> the gun and posting their pitches.
> 
> Dan
> 
>> On Aug 11, 2016, at 3:24 PM, Goffredo Marocchi via swift-evolution 
>> > wrote:
>> 
>> 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 > > wrote:
>> 
>>> 
 On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
 > 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 > 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 > > 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 

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

[Dan Stenmark via swift-evolution]

Guys, as I have already mentioned a couple of times in this thread, let’s 
please not turn this into a explicit discussion about how Swift could do 
concurrency.  That discussion is at least a few more months out, especially 
with memory ownership ala Rust/Cyclone being explored for Swift 4.  I intended 
this thread to be about general language & runtime design theory above all 
else, and I’m sure the team is already quite weary of folks jumping the gun and 
posting their pitches.

Dan

> On Aug 11, 2016, at 3:24 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 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  > wrote:
> 
>> 
>>> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>>> > 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 >> > 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  > 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 
>> > 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 
>> 
>> 

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

[Goffredo Marocchi via swift-evolution]

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  wrote:
> 
> 
>> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>>  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  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  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 
>  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/-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 

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

[Slava Pestov via swift-evolution]

> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
>  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 > 
> 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 >> > 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 
 > 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/-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, 

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

[Goffredo Marocchi via swift-evolution]

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

> On 11 Aug 2016, at 19:09, Kevin Ballard  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  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 
>>>  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/-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 

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

[Kevin Ballard via swift-evolution]

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  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
>>>  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/-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 

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

[Goffredo Marocchi via swift-evolution]

+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 
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  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/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 

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

[Kevin Ballard via swift-evolution]

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  evolut...@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/-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
___

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

[Goffredo Marocchi via swift-evolution]

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/-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

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

[Kevin Ballard via swift-evolution]

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/-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

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

[Dan Stenmark via swift-evolution]

> On Aug 10, 2016, at 10:24 PM, Chris Lattner  wrote:
> 
> Hi Dan,
> 
> There are many folks interested in concurrency topics related to this, but we 
> need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 
> 1 goals.  As that work is cresting, we’ll start discussions of concurrency, 
> and may even be so bold as to start a new mailing list dedicated to the 
> topic, since it is such a wide reaching topic.
> 
> Until we get to that point, please resist the urge to jump ahead :-)
> 
> -Chris

Chris, many apologies if this came across the wrong way!  As I attempted to 
explain in the opening email, I'm inquiring for purely academic reasons and to 
better my understanding of concurrency as part of language design in general, 
not to pitch anything for Swift.  In retrospect, perhaps -users would've been a 
better fit for this question rather than -evolution.


> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  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.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).

This right here is what I was looking for.  Thanks, guys!

Dan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On 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?

Hi Dan,

There are many folks interested in concurrency topics related to this, but we 
need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 1 
goals.  As that work is cresting, we’ll start discussions of concurrency, and 
may even be so bold as to start a new mailing list dedicated to the topic, 
since it is such a wide reaching topic.

Until we get to that point, please resist the urge to jump ahead :-)

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dmitri Gribenko via swift-evolution]

On Wed, Aug 10, 2016 at 3:50 PM, David Sweeris via swift-evolution
 wrote:
> For example, maybe you really do need to interpret a 64-bit chunk of data as 
> an Int64, even though the compiler is convinced it’s a Double. We can do that 
> in Swift through the various “unsafe” functions, which is where they belong 
> because 99.99% of the time that’s a bad idea.

"42.0.bitPattern".  Why do you think this conversion is unsafe?

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j*/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Aug 10, 2016, at 5:36 PM, Slava Pestov  wrote:
> 
> 
>> On Aug 10, 2016, at 3:34 PM, Christopher Kornher  wrote:
>> 
>> Would this prevent an object from being “known" to multiple threads? 
>> …multiple queues? If so, it would be overly restrictive for a 
>> general-purpose language. I assume that the plan includes a way to allow 
>> “unsafe” behavior to support other concurrency models.
>> 
> 
> To be clear I'm not presenting any ideas for Swift here, just critiquing Go's 
> model.
> 
> Yes, I'm just talking about 'safe' language features for passing immutable 
> data between threads. This would not preclude other forms of concurrency from 
> existing in the language, such as locks, atomics, etc. But I think if a user 
> writes code with only message passing, the language should ensure that the 
> result is free from data races. Go does not do that, which is unfortunate.
> 
Oh, *that* I’ll agree with… I was just talking about situations where there is 
no “safe” way to do it (for whatever your language’s/compiler’s idea of “safe” 
is). For example, maybe you really do need to interpret a 64-bit chunk of data 
as an Int64, even though the compiler is convinced it’s a Double. We can do 
that in Swift through the various “unsafe” functions, which is where they 
belong because 99.99% of the time that’s a bad idea. That 0.01% though…

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Aug 10, 2016, at 3:34 PM, Christopher Kornher  wrote:
> 
> Would this prevent an object from being “known" to multiple threads? 
> …multiple queues? If so, it would be overly restrictive for a general-purpose 
> language. I assume that the plan includes a way to allow “unsafe” behavior to 
> support other concurrency models.
> 

To be clear I'm not presenting any ideas for Swift here, just critiquing Go's 
model.

Yes, I'm just talking about 'safe' language features for passing immutable data 
between threads. This would not preclude other forms of concurrency from 
existing in the language, such as locks, atomics, etc. But I think if a user 
writes code with only message passing, the language should ensure that the 
result is free from data races. Go does not do that, which is unfortunate.

Slava

> 
>> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
>>> 
 On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
  wrote:
 
 As I understand it, a big weakness of Go's model is that it does not 
 actually prevent data races. There's nothing preventing you from sharing 
 pointers to mutable values between tasks, but I could be wrong about this.
>>> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
>>> long as you know what you’re doing, why should the language get in the way? 
>>> Now, if said code really does have performance advantages over the “safer” 
>>> methods, and it really is safe because for whatever reason the race 
>>> condition can’t actually happen, the language (or library) ought to have a 
>>> way to express that without having to write “unsafe” code. In the meantime, 
>>> though, you’ve gotta ship something that runs and meets performance 
>>> requirements.
>> 
>> Well, ideally, the type system would be able to enforce that values passed 
>> across thread boundaries are immutable. Rust's model allows this, I believe.
>> 
>> The possibility of mutating shared state in an unprincipled manner is "bad" 
>> in the same sense that being able to call free() in C is "bad" -- it's an 
>> abstraction violation if you get it wrong. Compared to languages with 
>> automatic memory management, there are advantages (control over memory 
>> management) and disadvantages (fewer static guarantees).
>> 
>> 
>>> 
>>> - Dave Sweeris
>> 
>> ___
>> 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

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

[Christopher Kornher via swift-evolution]

Would this prevent an object from being “known" to multiple threads? …multiple 
queues? If so, it would be overly restrictive for a general-purpose language. I 
assume that the plan includes a way to allow “unsafe” behavior to support other 
concurrency models.


> On Aug 10, 2016, at 4:24 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
>> 
>>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> As I understand it, a big weakness of Go's model is that it does not 
>>> actually prevent data races. There's nothing preventing you from sharing 
>>> pointers to mutable values between tasks, but I could be wrong about this.
>> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
>> long as you know what you’re doing, why should the language get in the way? 
>> Now, if said code really does have performance advantages over the “safer” 
>> methods, and it really is safe because for whatever reason the race 
>> condition can’t actually happen, the language (or library) ought to have a 
>> way to express that without having to write “unsafe” code. In the meantime, 
>> though, you’ve gotta ship something that runs and meets performance 
>> requirements.
> 
> Well, ideally, the type system would be able to enforce that values passed 
> across thread boundaries are immutable. Rust's model allows this, I believe.
> 
> The possibility of mutating shared state in an unprincipled manner is "bad" 
> in the same sense that being able to call free() in C is "bad" -- it's an 
> abstraction violation if you get it wrong. Compared to languages with 
> automatic memory management, there are advantages (control over memory 
> management) and disadvantages (fewer static guarantees).
> 
> 
>> 
>> - Dave Sweeris
> 
> ___
> 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

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

[Slava Pestov via swift-evolution]

> On Aug 10, 2016, at 3:22 PM, David Sweeris  wrote:
> 
>> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> As I understand it, a big weakness of Go's model is that it does not 
>> actually prevent data races. There's nothing preventing you from sharing 
>> pointers to mutable values between tasks, but I could be wrong about this.
> Is that bad? Sharing pointers seems like a cheap way to share data, and as 
> long as you know what you’re doing, why should the language get in the way? 
> Now, if said code really does have performance advantages over the “safer” 
> methods, and it really is safe because for whatever reason the race condition 
> can’t actually happen, the language (or library) ought to have a way to 
> express that without having to write “unsafe” code. In the meantime, though, 
> you’ve gotta ship something that runs and meets performance requirements.

Well, ideally, the type system would be able to enforce that values passed 
across thread boundaries are immutable. Rust's model allows this, I believe.

The possibility of mutating shared state in an unprincipled manner is "bad" in 
the same sense that being able to call free() in C is "bad" -- it's an 
abstraction violation if you get it wrong. Compared to languages with automatic 
memory management, there are advantages (control over memory management) and 
disadvantages (fewer static guarantees).


> 
> - Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> As I understand it, a big weakness of Go's model is that it does not actually 
> prevent data races. There's nothing preventing you from sharing pointers to 
> mutable values between tasks, but I could be wrong about this.
Is that bad? Sharing pointers seems like a cheap way to share data, and as long 
as you know what you’re doing, why should the language get in the way? Now, if 
said code really does have performance advantages over the “safer” methods, and 
it really is safe because for whatever reason the race condition can’t actually 
happen, the language (or library) ought to have a way to express that without 
having to write “unsafe” code. In the meantime, though, you’ve gotta ship 
something that runs and meets performance requirements.

- Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  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.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).

Even buffered file I/O via read(2) and write(2) is blocking on most *nix 
platforms. AFAIK there's some work being done on non-blocking buffered reads on 
Linux, but it appears to be a completely new API distinct from the existing 
epoll for sockets or aio_* for direct file I/O, and of course Darwin doesn't 
have an equivalent.

Slava

> 
> -Joe
> ___
> 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

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

[Charlie Monroe via swift-evolution]

According to http://c9x.me/art/gthreads/intro.html 
 I would guess so - pretty much userland 
threads - swapping context without kernel.


> On Aug 9, 2016, at 11:07 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Talking about green threads, are they similar to fibers? 
> http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine 
> 
> 
> Sent from my iPhone
> 
> On 9 Aug 2016, at 21:59, Joe Groff via swift-evolution 
> > wrote:
> 
>> 
>>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>> > 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.
>> 
>> In addition to FFI, there's also no way for memory-mapped IO to be 
>> non-blocking (a page fault can only be handled by the kernel, after all).
>> 
>> -Joe
>> ___
>> 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

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

[Goffredo Marocchi via swift-evolution]

Talking about green threads, are they similar to fibers? 
http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine

Sent from my iPhone

> On 9 Aug 2016, at 21:59, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  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.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).
> 
> -Joe
> ___
> 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

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

[Joe Groff via swift-evolution]

> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>  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.

In addition to FFI, there's also no way for memory-mapped IO to be non-blocking 
(a page fault can only be handled by the kernel, after all).

-Joe
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Ballard via swift-evolution]

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] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

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