220 21864 article Path: news.gmane.org!not-for-mail From: Evgeny Panasyuk 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: Sat, 17 Oct 2015 23:51:09 -0700 (PDT) Lines: 475 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@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> <561D79A7.8080007@gmail.com> <894616d6-9609-4038-b2bc-d2c62df21e0f@isocpp.org> <99bdb3ae-9214-4440-8572-4c47a61eda46@isocpp.org> <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> <561DC957.8080603@gmail.com> <510ce172-976a-4e3a-ae68-31fdb40af4d7@isocpp.org> <9dd3f28c-4ffb-4e08-9955-242c46e14527@isocpp.org> <31d5f64f-8db9-4ba3-aca7-872114b9776d@isocpp.org> <561DE488.3040103@gmail.com> <5587a3fd-499c-42b3-bf05-fd5cdc2d9118@isocpp.org> <561EF19E.6010405@gmail.com> <7560dfa8-c77f-41ec-9c0d-c88fe65e20b5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_927_1213310975.1445151069825" X-Trace: ger.gmane.org 1445151075 1202 80.91.229.3 (18 Oct 2015 06:51:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 06:51:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC54TLGKR4LBBYECRWYQKGQER4EZDSY@isocpp.org Sun Oct 18 08:51:15 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f70.google.com ([209.85.218.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnhoI-0003Rt-1M for gclcip-std-proposals@m.gmane.org; Sun, 18 Oct 2015 08:51:14 +0200 Original-Received: by oibl204 with SMTP id l204sf75644096oib.2 for ; Sat, 17 Oct 2015 23:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=SPZCvUW/EBGwr/3xV0XHU0ic00v34cDUP+vqSVSZHHo=; b=uNQ2xFhvwzuhPL6DRNTZ1ltiZIXFQMFu9sVra5CbYbk85ok2ed8+iM37TMfYktApnX vSO6DPoH5r4QAZM54HWmkJdlXKUrEotJ0+LGy7do7Exc9Ul+D7VwJXJvPZ81XNPRD6Pc 3VZ/S0MRxvuW+QoJ1o2W296FvANvNOme2eDGcG4VtQG2U1AzVTmtQ8I2hSiNIdS7cCPR pRfsmBuqB0fFkacUYfUrxvWuxSGy7cxY2i6VN+w9w+/giGMD80idxNeBFcM7N1VZM65u sB6WSfpfeni23pRskb+vPyKb1D1cW1SMaaMEyxs4oIKQdG0P3ltBgZD+DjshDg4F8AWf 9yQA== 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: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=SPZCvUW/EBGwr/3xV0XHU0ic00v34cDUP+vqSVSZHHo=; b=MmRLoT0AS3ZOJ/I48ay2AlwB1jsb5qFd6zeUu98Eq4j+0l1eZZQqiBPAlgQhFRqYfC SqS8643hDJLpX5hIjLUo+OQpCbU4kKJ2yKXcr/BpWetipshNacn4342JMmfu0/rb0bGQ RZAKnZG7tx9etBMKnRwvH8D4XHzG4WnjRzMOqFP594trgp3UNGj4lHdDAXfGvW+7dVaJ mZrwZA6djvTcMqkpe462p8qCm7vj12pkfzOmRim/H1LDxXr5h5CWQYz+QsGFmXCmXOuX lobm71yO9U08JvqH6vIdVOE3POd75EUOYvLVSzq+GIKow3vVoFn0MhwvNVMWXt2Wk4eg XnRw== X-Gm-Message-State: ALoCoQm2tnS7/9596uYayqqCoNh2lG5SzSv+OacCnlanuiWIDrG741FlmffPIHfW+Y476eXFno4A X-Received: by 10.50.85.4 with SMTP id d4mr1737704igz.3.1445151072820; Sat, 17 Oct 2015 23:51:12 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.137.103 with SMTP id l100ls83959iod.22.gmail; Sat, 17 Oct 2015 23:51:12 -0700 (PDT) X-Received: by 10.50.131.162 with SMTP id on2mr264606igb.4.1445151071946; Sat, 17 Oct 2015 23:51:11 -0700 (PDT) In-Reply-To: X-Original-Sender: Evgeny.Panasyuk@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:21864 Archived-At: ------=_Part_927_1213310975.1445151069825 Content-Type: multipart/alternative; boundary="----=_Part_928_1211755242.1445151069826" ------=_Part_928_1211755242.1445151069826 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 17 October 2015 =D0=B3., 20:07:12 UTC+3 Nicol Bolas: > > On Saturday, October 17, 2015 at 11:43:32 AM UTC-4, Evgeny Panasyuk wrote= : >> >> 17 October 2015 =D0=B3., 16:31:25 UTC+3 Nicol Bolas: >> >>> P0057 is the result of numerous revisions of an idea, across several=20 >>> years, as well as with lots of implementation experience. Why should we= =20 >>> impair such a design just because you think that, one day, someone=20 >>> *might* propose a better one?=20 >>> >> >> Yes, better design is possible. >> But that is not the only issue - if there will be big overhead, it would= =20 >> have limited usability. As Giovanni mentioned above, if performance is n= ot=20 >> an issue - stackful coroutines would cover most of use cases of slow=20 >> stackless coroutines. >> > > I don't understand you rhetoric here. On the one hand, you claim that=20 > there is "big overhead" and that P0057 are "slow stackless coroutines." Y= et=20 > later, you specifically state that "Again, I should prepare detailed repo= rt=20 > (in order for it to have real effect)". Which means that you, as of yet,= =20 > have no actual evidence that overhead is "big" or that P0057 is "slow". > No. this is wrong conclusion. "need to make detailed report" !=3D "I don't= =20 have any evidence". =20 > You have repeatedly made the positive claims that P0057 is "slow", that i= t=20 > has "big overhead". It's time to put up or shut up: present your evidence= =20 > for these claims, or we should consider your statements to be at best=20 > conjecture. > > Note: "evidence" means actual evidence. Not "well, if you do this, the=20 > optimizer might not work" or whatever. Actual, good-faith evidence. > > There is apparently an implementation of P0114. And there is an=20 > implementation of await. Use them to provide us with evidence of your=20 > claims. > Here is an example: auto numbers(int n) { for (int i =3D 0; i !=3D n; ++i) yield i; } int main() { unsigned res =3D 0; auto &&xs =3D numbers(1 << 30); { boost::progress_timer t; for (auto x : xs) res +=3D x; } cout << res << endl; } I made two variants. One is P0057 yield/generator, another one is similar= =20 code based on Boost.Asio stackless coroutine macros. I used VS2015 x64 for both cases. P0057 version has allocation, i.e. even for this simple case elision=20 trickery is not implemented. But I do not measure allocation, I just=20 measure inner loop. Macro version is 4.57x faster. And note, macro version= =20 is far from being optimal in a sense that with compiler support it is=20 possible to get even better result. =20 > =20 > >> >>> You said that you do not want to change mechanics of function signature= .. >> > > No, what I didn't want was for a function signature to *lie*. Where it=20 > magically is transformed into a struct, or the return type gets replaced = by=20 > something else or some such. > What about case with "auto" return type, where it is generated via=20 specialization of coroutine_traits? If in this case you still would say that "it is replaced by something else"= =20 - then how it differs from P0057: auto foo(int x) { yield x; } Here return type is not int. =20 > And that part is what keeps tripping you up. Because if you insist on=20 > being able to return a compiler-generated type (whether it's directly or= =20 > stored in the return object), there is no way to specify such a thing in= =20 > C++. And therefore, there is going to have to be some place where you=20 > *cheat*. > Why returning generator in P0057 (when it's "result type" is auto) is not= =20 cheating? And why returning traits::type is cheating? What= =20 is the principal difference? =20 > =20 > >> And no, your approach is not "closer" to P0057. It's farther. The return= =20 >>> type is a coroutine now, not a future, or generator, or other user-defi= ned=20 >>> type. It's an actual coroutine. >>> >> >> No, I mean that actual return type would be specified by specialization= =20 >> of coroutine_traits. >> > > Which is rather the opposite of how P0057 works, where the return type is= =20 > the return type, and the promise type is *deduced* from that. > > So again, you're deviating farther from P0057, not closer. > Hm, how any change in existing text is supposed to deviate closer to it? =20 > > That's not how P0057 works. Indeed, that's not what P0057 is *for*.=20 >>> Remember the general idea of await in P0057: it halts the function, but= it=20 >>> also *explicitly* allows the transfer of control of the function to the= *await=20 >>> expression*. And thus, control is not necessarily transferred to the=20 >>> return value. >>> >> >> Yes, of course, it does not have to.=20 >> > > So... how do you do it? In P0057, it happens through `await_suspend`,=20 > which takes a coroutine_handle<>. So in your idea, how does it work? > For example await_suspend can be function template which takes concrete=20 coroutine.=20 =20 > > Oh sure, you use different keywords. But the behavior of those keywords i= s=20 >>> basically the behavior of the functions P0114 implements. Basically, P0= 114=20 >>> is what you want, even if you would prefer that the form appeared more = like=20 >>> P0057. >>> >> >> Personally I prefer P0114 - it is more powerful, gives less overhead, an= d=20 >> shifts from concrete await or yield features towards more general langua= ge=20 >> feature. >> But if P0057 is much more likely to get into ISO, then I would like to= =20 >> remove discussed overhead. >> > > Here's my problem with that notion. > > What you really want is P0114. But you don't believe that it'll make it= =20 > in. So instead, you propose suggestions to change P0057. Which will in th= e=20 > end... turn it into a *gimped* version of P0114. > P0114 is much more powerful than changes I propose. =20 > > What P0114 fails is at .then-style continuations. > Why? I already showed example of List Monad which is exactly .then-style. There is already example within Boost.Asio which uses macro-based stackless= =20 coroutine for .then style IO. --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_928_1211755242.1445151069826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 17 October 2015 =D0=B3., 20:07:12 UTC+3 Nicol Bolas:
On Saturday, October 17, 2015 at 11:= 43:32 AM UTC-4, Evgeny Panasyuk wrote:
17 October 2015 =D0=B3., 16:31:25 UTC+3 Nicol Bolas:
P0057 is the result of numero= us revisions of an idea, across several years, as well as with lots of impl= ementation experience. Why should we impair such a design just because you = think that, one day, someone might propose a better one?
<= /blockquote>

Yes, better design is possible.
But that is not the= only issue - if there will be big overhead, it would have limited usabilit= y. As Giovanni mentioned above, if performance is not an issue - stackful c= oroutines would cover most of use cases of slow stackless coroutines.

I don't understand you rhetoric here. O= n the one hand, you claim that there is "big overhead" and that P= 0057 are "slow stackless coroutines." Yet later, you specifically= state that "Again, I should prepare detailed report (in order for it = to have real effect)". Which means that you, as of yet, have no actual= evidence that overhead is "big" or that P0057 is "slow"= ;.

No. this is wrong conclusion. "= ;need to make detailed report" !=3D "I don't have any evidenc= e".
=C2=A0
You have repeatedly made the positive claims that P0057 is = "slow", that it has "big overhead". It's time to pu= t up or shut up: present your evidence for these claims, or we should consi= der your statements to be at best conjecture.

Note: "evidence&q= uot; means actual evidence. Not "well, if you do this, the optimizer m= ight not work" or whatever. Actual, good-faith evidence.

There = is apparently an implementation of P0114. And there is an implementation of= await. Use them to provide us with evidence of your claims.

Here is an example:
auto numbers(int n)
{
=C2=A0 =C2=A0 for (int i =3D 0;= i = !=3D n; ++i)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 yield i;
}

int main()
{
=C2=A0 =C2=A0 unsigned res =3D 0;
=C2= =A0 =C2=A0 auto &&xs =3D numbers(1 << 30);
=C2= =A0 =C2=A0 {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 boost::progress_timer t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto= x : xs)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 res +=3D x;
=C2=A0 =C2= =A0 }
=C2=A0 =C2= =A0 cout &= lt;< re= s <<= endl;
}
I made = two variants. One is P0057 yield/generator, another one is similar code bas= ed on Boost.Asio stackless coroutine macros.
I used VS2015 x64 for both = cases.
P0057 version has allocation, i.e. even for this simple case elis= ion trickery is not implemented. But I do not measure allocation, I just me= asure inner loop. Macro version is 4.57x faster. And note, macro version is= far from being optimal in a sense that with compiler support it is possibl= e to get even better result.
=C2=A0
=C2=A0

You said that you do not = want to change mechanics of function signature.

No, what I didn't want was for a function signature to lie= .. Where it magically is transformed into a struct, or the return type gets = replaced by something else or some such.
<= br>What about case with "auto" return type, where it is generated= via specialization of coroutine_traits?
If in this case you still would= say that "it is replaced by something else" - then how it differ= s from P0057:
auto foo(int x)
{
=C2=A0=C2=A0=C2=A0 yield x;
}
Here return type is not int.

=C2=A0=
An= d that part is what keeps tripping you up. Because if you insist on being a= ble to return a compiler-generated type (whether it's directly or store= d in the return object), there is no way to specify such a thing in C++. An= d therefore, there is going to have to be some place where you cheat= ..

Why returning generator in P0057 (wh= en it's "result type" is auto) is not cheating? And why retur= ning traits<tag, params...>::type is cheating? What is the principal = difference?
=C2=A0
=C2=A0
And no, your appr= oach is not "closer" to P0057. It's farther. The return type = is a coroutine now, not a future, or generator, or other user-defined type.= It's an actual coroutine.

No, I mean th= at actual return type would be specified by specialization of coroutine_tra= its.

Which is rather the opposite of h= ow P0057 works, where the return type is the return type, and the promise t= ype is deduced from that.

So again, you're deviating fart= her from P0057, not closer.

Hm, how an= y change in existing text is supposed to deviate closer to it?
=C2=A0

That's not how P0057 works. = Indeed, that's not what P0057 is for. Remember the general idea = of await in P0057: it halts the function, but it also explicitly all= ows the transfer of control of the function to the await expression.= And thus, control is not necessarily transferred to the return value.
<= /div>

Yes, of course, it does not have to.
<= /div>

So... how do you do it? In P0057, it happens thr= ough `await_suspend`, which takes a coroutine_handle<>. So in your id= ea, how does it work?

For example awai= t_suspend can be function template which takes concrete coroutine.
=C2= =A0

Oh sure, you use different= keywords. But the behavior of those keywords is basically the behavior of = the functions P0114 implements. Basically, P0114 is what you want, even if = you would prefer that the form appeared more like P0057.

Personally I prefer P0114 - it is more powerful, gives less ov= erhead, and shifts from concrete await or yield features towards more gener= al language feature.
But if P0057 is much more likely to get into ISO, t= hen I would like to remove discussed overhead.
=

Here's my problem with that notion.

What you really wan= t is P0114. But you don't believe that it'll make it in. So instead= , you propose suggestions to change P0057. Which will in the end... turn it= into a gimped version of P0114.
P0114 is much more powerful than changes I propose.
=C2=A0

What P0114= fails is at .then-style continuations.
Why?
I already showed example of List Monad which is exactly .then-sty= le.
There is already example within Boost.Asio which uses macro-based st= ackless coroutine for .then style IO.

--

---
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_928_1211755242.1445151069826-- ------=_Part_927_1213310975.1445151069825-- .