<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Aug 31, 2017, at 5:48 PM, Pierre Habouzit via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Unlike the proposed future code the async code is not naturally parallel, in the running example the following lines from the async code are run in series, i.e. await blocks:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class=""> <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> dataResource <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> await <span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">loadWebResource</span>(<span class="gmail-pl-s" style="box-sizing:border-box;color:rgb(3,47,98)"><span class="gmail-pl-pds" style="box-sizing:border-box">"</span>dataprofile.txt<span class="gmail-pl-pds" style="box-sizing:border-box">"</span></span>)
<span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> imageResource <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> await <span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">loadWebResource</span>(<span class="gmail-pl-s" style="box-sizing:border-box;color:rgb(3,47,98)"><span class="gmail-pl-pds" style="box-sizing:border-box">"</span>imagedata.dat<span class="gmail-pl-pds" style="box-sizing:border-box">"</span></span>)
</pre></div><div class="">The equivalent lines using the proposed Future:</div><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class=""> <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> dataResource <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> <span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">loadWebResource</span>(<span class="gmail-pl-s" style="box-sizing:border-box;color:rgb(3,47,98)"><span class="gmail-pl-pds" style="box-sizing:border-box">"</span>dataprofile.txt<span class="gmail-pl-pds" style="box-sizing:border-box">"</span></span>)
<span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> imageResource <span class="gmail-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> <span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">loadWebResource</span>(<span class="gmail-pl-s" style="box-sizing:border-box;color:rgb(3,47,98)"><span class="gmail-pl-pds" style="box-sizing:border-box">"</span>imagedata.dat<span class="gmail-pl-pds" style="box-sizing:border-box">"</span></span>)
</pre></div><div class="">Run in parallel and therefore are potentially faster assuming that resources, like cores and IO, are available.</div><div class=""><br class=""></div><div class="">Therefore you would be better using a Future than an async, so why provide an async unless you can make a convincing argument that it allows you to write a better future?</div></div></div></blockquote><div class=""><br class=""></div><div class="">In practice, you would really want all resources that you load from the internet to be handled from the same execution context (whether it's a dispatch queue, a thread or a CFRunloop is absolutely not relevant), because it's very likely that you'll end up contending concurrent executions of these loads through locks and the various shared resources in use (like your NIC and the networking stack).</div></div></div></div></blockquote><div><br class=""></div></div>I completely agree with this point, and this is one of the nice things about the model as described: It allows the programmer to describe concurrent abstractions that make sense for their app, WITHOUT being bound to how the async operations themselves are implemented. I don’t expect the whole world to be reimplemented, but if it was, I’d expect that there would end up being one “network card actor” for each physical nic that is present. No matter how many concurrent requests are started by clients, they’d be serially enqueued on the actors queue, and the requests would presumably be serviced in parallel using efficient shared mutable state WITHIN the network card actor.<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><div class="">On real systems going wide concurrently is not often a win provided the thing you're doing is complex enough.</div><div class="">The reason for it is that most of these subsystems, and loadWebResource is a perfect example of this, use constrained resources that use locks and the like.</div></div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><div class=""><div class=""><br class=""></div><div class="">I agree with you if you’re talking about a single machine, but if you’re talking about distributing across a cluster of a thousand machines, then I disagree.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div></div></body></html>