220 21759 <1a88f228-d760-4034-b915-ebdaa6826ec3@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: is await an extension of the do-notation? (was Re: Re: Resumable expressions p0114r0 vs async/await P0057R0) Date: Wed, 14 Oct 2015 06:37:50 -0700 (PDT) Lines: 318 Approved: news@gmane.org Message-ID: <1a88f228-d760-4034-b915-ebdaa6826ec3@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <56114953.4030701@wanadoo.fr> <561B403D.4030403@gmail.com> <561C07D1.3080304@gmail.com> <561C213F.1060009@gmail.com> <561C3875.2050701@gmail.com> <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1556_1021943582.1444829870177" X-Trace: ger.gmane.org 1444829883 10184 80.91.229.3 (14 Oct 2015 13:38:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 13:38:03 +0000 (UTC) Cc: thorsten.ottosen@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBLVV7GYAKGQETVLJOPA@isocpp.org Wed Oct 14 15:37:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmMFd-00081a-B0 for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 15:37:54 +0200 Original-Received: by vkex70 with SMTP id x70sf49185175vke.3 for ; Wed, 14 Oct 2015 06:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=qZ+g4XweDTyqfi79oteN1JCim3sp/aF6ZM3STGWqZDY=; b=uWOL0VMOhh2OYOB4uw0iJX6b2vgGzX0eqgsRFdSSJ4icEzpevdLaZ2avwbNTJKl8Z7 IOYC5AdaIwFqkGB0l8KalAuN4FuH844mv/7OVDPD6JrVRvUrvz/XSF4/iwIb4BnzU4FW mZUp18X5A2HrqOh4oUK6FZHfFwwDhFK7GMr319yVi1v2Qllyv1ABhxOdKQqiiN5OSFq9 3LW9rXmZ767JGSsM2bpcCDYES81TyRMKucvah5/8670WM6Vrqem7dCKC57ZBQ8E0Nhlp vDn22AAI3bmSpebt1Vlqafp/9zokeVAbW12MITEBFlyATM4n6Q/q5g6Wtz3NMKeOwgzv 6bpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qZ+g4XweDTyqfi79oteN1JCim3sp/aF6ZM3STGWqZDY=; b=DsesZg5z/x99pL9+38sumWJ+2pXTt6lw/8mbceXByzQu2NAAaaB1hzXttK83h0q3oo XWnQzCHJxHFVzeWmzbqHRDBDAO0Y75dWYbChc0ZLW7f6jBDg8Y+G44XBYAml7VRoaJxo 4IQBPgdvmaLc/19FWs2gXCPCqrQZC/tkwvM9KLhMidm3jDsYxW5DScKaVCPXzq/hGxdA SYU4ulAcIv0kRqsEOqa0frDIFf3dlNaseW659bxp2i+2fBHXVhzrQvCjbtptRoNowyQa 90vCLsludKd0PEbixNS3eJq/+EiqlUj3K5GGsW2M+Z4KcE/3B/Pcp3o4WyMuRDgaJSSh MMCQ== X-Gm-Message-State: ALoCoQlMRlsrWIOIbeKHvGx+UTlJ7TuLL+FT2AhTlpYnDJnu4ah7s1T8M9agIoBAFd7PlEbeZMYQ X-Received: by 10.31.149.200 with SMTP id x191mr2610672vkd.14.1444829872258; Wed, 14 Oct 2015 06:37:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.152.67 with SMTP id a64ls176260ioe.64.gmail; Wed, 14 Oct 2015 06:37:50 -0700 (PDT) X-Received: by 10.50.142.9 with SMTP id rs9mr53473igb.6.1444829870719; Wed, 14 Oct 2015 06:37:50 -0700 (PDT) In-Reply-To: X-Original-Sender: GorNishanov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21759 Archived-At: ------=_Part_1556_1021943582.1444829870177 Content-Type: multipart/alternative; boundary="----=_Part_1557_71016232.1444829870177" ------=_Part_1557_71016232.1444829870177 Content-Type: text/plain; charset=UTF-8 On Wednesday, October 14, 2015 at 4:50:33 AM UTC-7, thorsten...@gmail.com wrote: > > 3) What is an abstraction penalty, how many instructions need to get >> executed to get from, say, await Read(buf, len) to an low-level >> API/hardware, say WSARecv >> >> My statement is that P0057 is as good or better on all 3 criteria than >> any other proposal I've seen. If you want to accept the challenge, write up >> an equivalent to TcpReader described in one of these two presentations: >> > > That is a good way forward. I think the abstraction penalty should be the > same, > I really hoped that one of the proponents will do the exercise and reach the same conclusion as I did. Namely that P0114 has significantly higher overhead measured in hundreds more instructions, memory barriers, type erasure and memory allocations. If you look at http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0055r0.html, it shows how you can automate creation of awaitables for template based libraries dealing with async I/O that gets you code equivalent to hand written assembly. ResultType r = await async_xyz(p); becomes async_xyz`Awaiter __tmp{p}; $promise.resume_addr = &__resume_label; // save the resumption point of the coroutine __tmp.resume = $RBP; // inlined await_suspend os_xyz(p,&OsContextBase::Invoke, &__tmp); // inlined await_suspend jmp Epilogue; // suspends the coroutine __resume_label: // will be resumed at this point once the operation is finished R r = move(__tmp.result); // inlined await_resume which is pretty much what you would have written by hand if you would write your coroutine in assembly. Compare that to "can do it in a library" approach. First, look at heavy-weight await emulation machinery described in 12.5 of P0114R0 starting on page 21. But, let's say, await is not a natural pattern for P0114, that is why it is heavy weight. Let's look at what could be more natural pattern, shown in: https://github.com/chriskohlhoff/resumable-expressions/blob/master/examples/await4.cpp .. Same situtation, not as bad as with await emulation, but, still bad. Though, I think that this is fixable. P0114RX can get syntactic sugar equivalent of await and yield, it would not need to do as much work in the library. So it will become as efficient P0057. What remains are various inconveniences of how coroutines are presented to the user. You need to do manual type erasure, like in this example (await4.cpp): resumable void echo(tcp::socket socket); resumable void listen(tcp::acceptor acceptor) { ... spawn([s = std::move(socket)]() mutable { echo(std::move(s)); }); When I say manual type erasure, I mean that instead of just calling echo, you need to wrap it in a lambda and give to type-erasing library helper spawn that does wrapping and allocation for you. Another limitation is that you have to put everything in one file to the code above to work, since in order for listen to be able to use echo in resumable expression, it needs to see the body of the echo, thus, it needs to be defined in the same TU. If you want to put them in different files you need to create little type erasing wrappers, as in: echo.h: void echo(tcp::socket socket); echo.cpp: resumable echo_impl(tcp::socket socket) { ... } void echo(tcp::socket socket) { spawn([s = std::move(socket)]() mutable { echo_impl(std::move(s)); }); } I am not so much critisizing Chris, as critisizing myself. I went through this design already when exploring lambda* nearly two years ago. I reached a conclusion that for the problems I tried to apply it to, it did not offer anything to compensate for the complexity compared to boring C# like await syntax. Hence, I no longer pursue this approach. It does not mean that for *some* problems, some incarnation of lambda* *might* be better than P0057. That is wonderful. When this happen, let's add it in, in addition to P0057 and P0099 (modestly called "A low-level API for stackful context switching"). -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_1557_71016232.1444829870177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wednesday, October 14, 2015 at 4:50:33 AM UTC-7= , thorsten...@gmail.com wrote:
=
3) What is an= abstraction penalty, how many instructions need to get executed to get fro= m, say, await Read(buf, len) to an low-level API/hardware, say WSARecv

My statement is that P0057 is as good or better on all= 3 criteria than any other proposal I've seen. If you want to accept th= e challenge, write up an equivalent to TcpReader described in one of these = two presentations:

That is a good way forw= ard. I think the abstraction penalty should be the same,

I really hoped that one of the proponents will do the = exercise and reach the same conclusion as I did. Namely that P0114 has sign= ificantly higher overhead measured in hundreds more instructions, memory ba= rriers, type erasure and memory allocations.

If yo= u look at http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0055r0.html,= it shows how you can automate creation of awaitables for template based li= braries dealing with async I/O that gets you code equivalent to hand writte= n assembly.

     ResultType r =3D await async_xyz(=
p);

becomes

     async_xyz`Awaiter __tmp{p};=20
     $promise.resume_addr =3D &__resume_label;   // save the resumption=
 point of the coroutine
     __tmp.resume =3D $RBP;                      // inlined await_suspend
     os_xyz(p,&OsContextBase::Invoke, &__tmp); // inlined await_sus=
pend
     jmp Epilogue; // suspends the coroutine
__resume_label:    // will be resumed at this point once the operation is f=
inished
     R r =3D move(__tmp.result); // inlined await_resume
=

which is pretty much what you would have written by han= d if you would write your coroutine in assembly.
Compare that to = "can do it in a library" approach.

First= , look at heavy-weight await emulation machinery described in 12.5 of P0114= R0 starting on page 21.

But, let's say, await is not a na= tural pattern for P0114, that is why it is heavy weight. Let's look at = what could be more natural pattern, shown in:
https://github.com/= chriskohlhoff/resumable-expressions/blob/master/examples/await4.cpp . Same = situtation, not as bad as with await emulation, but, still bad.

Though, I think that this is fixable. P0114RX can get syn= tactic sugar equivalent of await and yield, it would not need to do as much= work in the library. So it will become as efficient P0057.=C2=A0

What remains are various inconveniences of how coroutines a= re presented to the user.
You need to do manual type erasure, lik= e in this example (await4.cpp):

resumable void e= cho(tcp::socket socket);

resumable void listen(tcp::acceptor acceptor) {=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 spawn([s =3D std::move<= span style=3D"color: #660;" class=3D"styled-by-prettify">(socket)]() mutable { echo(std::move(s)); });

When I say manual type erasu= re, I mean that instead of just calling echo, you need to wrap it in a lamb= da and give to type-erasing library helper spawn that does wrapping and all= ocation for you.

Another limitation is that you ha= ve to put everything in one file to the code above to work, since in order = for listen to be able to use echo in resumable expression, it needs to see = the body of the echo, thus, it needs to be defined in the same TU. If you w= ant to put them in different files you need to create little type erasing w= rappers, as in:

echo<= span style=3D"color: #660;" class=3D"styled-by-prettify">.h:
void echo(tcp::<= /span>socket sock= et);

echo.cpp:

resumable echo_impl(tcp::socket socket= ) { ... }

void e= cho(tcp::socket socket) {
=C2=A0 =C2=A0 spawn([s =3D std::move= (socket)]() mutable { echo_impl(std::move(s)); });
}

I am not so m= uch critisizing Chris, as critisizing myself. I went through this design al= ready when exploring lambda* nearly two years ago. I reached a conclusion t= hat for the problems I tried to apply it to, it did not offer anything to c= ompensate for the complexity compared to boring C# like await syntax. Hence= , I no longer pursue this approach.

It does not me= an that for some problems, some incarnation of lambda* might = be better than P0057. That is wonderful. When this happen, let's add it= in, in addition to P0057 and P0099 (modestly called "A low-level API = for stackful context switching").

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1557_71016232.1444829870177-- ------=_Part_1556_1021943582.1444829870177-- .