220 21744 article Path: news.gmane.org!not-for-mail From: Nicol Bolas 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: Tue, 13 Oct 2015 21:46:50 -0700 (PDT) Lines: 251 Approved: news@gmane.org Message-ID: 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> <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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6485_1764221694.1444798011001" X-Trace: ger.gmane.org 1444798020 24620 80.91.229.3 (14 Oct 2015 04:47:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 04:47:00 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBPF466YAKGQEJEPSZZA@isocpp.org Wed Oct 14 06:46:55 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmDxm-0000qy-9e for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 06:46:54 +0200 Original-Received: by iodv82 with SMTP id v82sf68945225iod.0 for ; Tue, 13 Oct 2015 21:46:53 -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=mMqxuqur8grp1LNad4u7uE4cNK4EP0ymnVovTHWfXOo=; b=ZC8qhP98CQQRG3sRGt/DMHd4frvrxUr++9Rxwj8lOVyw1A92J2z2b7pCHGG+6xO8J4 9P9SdrW1RaBBJFyG9vlPavmOU/HOU/n8j0FkXtka0h2zVwdtRP1xGFo07rHvCuWRi86D d53n5zWRslJsZ3ORQ4eSdY48bFI6QsDL98AQvvsCfm5kEZkEDz6aewIKl2z8NYzo/mzc GHXrfBBbz08agkq8mQcXWZt8b/8PvPF6UTKNXvpnr5YdxuS8DNb8Yb+XuzGpMMqM/blg n9UVcPZ/GzWqFjPyXoy2NQ5SlYGw9+n8zGnYQ84ceI4DmpyPM2MFQ9xi/r8zOkHaEkku 2Ijw== 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=mMqxuqur8grp1LNad4u7uE4cNK4EP0ymnVovTHWfXOo=; b=H0Jpmbd30UJw6BT/aOWZ835Olpxc1CzKSNpRQYI3GboESfpCJFAvPyaiguTmpRUESg +YCXvD8ynJ3KN6mtK2RSSH24Y0HyVqSQqKFecYG+ehhAaA3LryPP6SXnqkMDtEFrnD/M lRi4LhNDknZYCmr/r57+k1Vu43K3nNcvpKC9Jiy3vm4jYhiJroivuvNFza9yp3LEAPLZ USqpNJQrN520FDt/njf+70JQsFcn8JJIdW4hRhIWK2HA3sIEKuJZOezv99LjT7NUeJr+ ioymZjNgXTf4UQAM8NKNifAowk5ixYVch55gpIlbD2fFIRc0TW2qVtMBRRCUNF4ehUbe mfPg== X-Gm-Message-State: ALoCoQmoR/dbxH4UhPWuNl+cviCd7EaXOP5IyxMHaeHdfK8kH3jfE4OzyxsQBJn3VWqXei32rjsk X-Received: by 10.50.142.103 with SMTP id rv7mr20463757igb.2.1444798013051; Tue, 13 Oct 2015 21:46:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.88.73 with SMTP id be9ls1637809igb.28.canary; Tue, 13 Oct 2015 21:46:52 -0700 (PDT) X-Received: by 10.50.143.12 with SMTP id sa12mr293150igb.7.1444798012176; Tue, 13 Oct 2015 21:46:52 -0700 (PDT) In-Reply-To: <561DC957.8080603@gmail.com> X-Original-Sender: jmckesson@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:21744 Archived-At: ------=_Part_6485_1764221694.1444798011001 Content-Type: multipart/alternative; boundary="----=_Part_6486_896213012.1444798011002" ------=_Part_6486_896213012.1444798011002 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 13, 2015 at 11:17:53 PM UTC-4, Evgeny Panasyuk wrote: > > 14.10.2015 4:57, Nicol Bolas: > > Except that he's already proven (in this thread no less) that a > > good optimizer can elide the allocation. If the compiler can > > reasonably /make/ it zero overhead, then it /is/ zero overhead. > > > > > > > > 1. It is impossible (practically) in general case. > > For instance in case when we put coroutines in container, like: > > | > > vectorx(N); > > | > > In case of coroutines with concrete types and sizeof known at > > compile - this can be done within single allocation. > > But if coroutine type is erased the we will have N+1 allocations in > > general case - it can't be practically elided. > > > > > > Ignoring the rest of the discussion on this point, I never claimed that > > P0057 could guarantee elision in the case you present here. Before, you > > asked about a /specific/ problem, and I answered with a specific example > > showing that it was elidable. What you've shown here hardly disproves my > > point. > > It is not zero overhead even with good optimizer/compiler, because they > can't elide every allocation, and I am not talking about some exotic > cases. > Thus far, including in this post, you haven't mentioned an example that would actually compile. You linked to some macro code, but macros are, basically, *cheating*. They get to break all kinds of C++ rules, which an actual language feature would not. > > > > Also... how does `vector` make any kind of sense with regard > > to P0114? The type isn't type erased, so each coroutine has its own > > type. Therefore, in order to put them in a homogeneous container like > > `vector`, you'll have to type-erase them. Which requires memory > allocation. > > At which point, your version gains /nothing/ over P0057. > > Same coroutines have same concrete types. For instance, with P0114 it > may be: > | > struct concrete_coroutine > { > resumable auto r = expression; > // ... > }; > ... > make_unique(N); > | > `auto` doesn't work that way. Non-static data members cannot be `auto`. Normally I wouldn't care about a small issue like that, but it basically makes your code impossible. Without `auto` NSDMI (and I wouldn't hold my breath on seeing it ), you can't store a resumable expression. So you can't make containers of them. Unless you erase their types. So again, you've gained *nothing*. Your macro solution gets around this because it uses macros. > Again, I am not talking specifically about P0114. Even P0057 can be > changed to have concrete coroutine type. > I'd be curious to see how, exactly. And I don't mean some macro nonsense. I mean the specific details of how you turn P0057's `coroutine_handle` into a type. See, the way P0057 works is that the coroutine object is introduced in one specific place: the awaiter object's `await_suspend` method. That's the first place where user code gets to touch a coroutine, and if the method doesn't store it or otherwise keep it around, it's also the last. That's what I meant when I said "adding a template". Because now, `await_suspend` *must* become a template function. There's no other way to capture a parameter of an arbitrary, compiler-generated type. But what of generators and promises in such a scenario? A `generator` needs to be able to store any coroutine, so it has to... type erase it. The promise type cannot be a template on the coroutine type, since it was declared long before the coroutine handle appeared. And so forth. In short, the entirety of P0057 is designed around a type-erased `coroutine_handle`. You can't simply declare that it's not type-erased and expect everything to work reasonably. The entire design would need to be rethought. If you want this done, then you're going to need to go through the effort of designing the feature to work without type erasure. Then you have to get someone to implement it. Then, you can know whether it works just as well as P0057, whether it's equally easy to use, and how much of a performance advantage it gets. If any. -- --- 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_6486_896213012.1444798011002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, October 13, 2015 at 11:17:53 PM UTC-4, Evgeny Panasyuk wrote:14.10.2015 4:57, Nicol Bolas:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Except that he's already proven (i= n this thread no less) that a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 good optimizer can elide the allocatio= n. If the compiler can
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 reasonably /make/ it zero overhead, th= en it /is/ zero overhead.
>
>
>
> =C2=A0 =C2=A0 1. It is impossible (practically) in general case.
> =C2=A0 =C2=A0 For instance in case when we put coroutines in conta= iner, like:
> =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 vector<coroutine>x(N);
> =C2=A0 =C2=A0 |
> =C2=A0 =C2=A0 In case of coroutines with concrete types and sizeof= known at
> =C2=A0 =C2=A0 compile - this can be done within single allocation.
> =C2=A0 =C2=A0 But if coroutine type is erased the we will have N+1= allocations in
> =C2=A0 =C2=A0 general case - it can't be practically elided.
>
>
> Ignoring the rest of the discussion on this point, I never claimed= that
> P0057 could guarantee elision in the case you present here. Before= , you
> asked about a /specific/ problem, and I answered with a specific e= xample
> showing that it was elidable. What you've shown here hardly di= sproves my
> point.

It is not zero overhead even with good optimizer/compiler, because they= =20
can't elide every allocation, and I am not talking about some exoti= c cases.

Thus far, including in this post, you haven't= mentioned an example that would actually compile.

You linked to som= e macro code, but macros are, basically, cheating. They get to break= all kinds of C++ rules, which an actual language feature would not.
=C2= =A0
>
> Also... how does `vector<coroutine>` make any kind of sense = with regard
> to P0114? The type isn't type erased, so each coroutine has it= s own
> type. Therefore, in order to put them in a homogeneous container l= ike
> `vector`, you'll have to type-erase them. Which requires memor= y allocation.
=C2=A0> At which point, your version gains /nothing/ over P0057.

Same coroutines have same concrete types. For instance, with P0114 it= =20
may be:
|
struct concrete_coroutine
{
=C2=A0 =C2=A0 =C2=A0resumable auto r =3D expression;
=C2=A0 =C2=A0 =C2=A0// ...
};
...
make_unique<concrete_coroutine[]>(N);
|

`auto` doesn't work that way. Non-static= data members cannot be `auto`. Normally I wouldn't care about a small = issue like that, but it basically makes your code impossible.

Withou= t `auto` NSDMI (and I wouldn't hold my breath on seeing it), yo= u can't store a resumable expression. So you can't make containers = of them.

Unless you erase their types. So again, you've gained <= i>nothing.

Your macro solution gets around this because it uses = macros.
=C2=A0
Again, I am not talking specifically about P0114. Even P0057 can be=20
changed to have concrete coroutine type.

I'd be curious to see how, exactly.

An= d I don't mean some macro nonsense. I mean the specific details of how = you turn P0057's `coroutine_handle` into a type.

See, the way P0= 057 works is that the coroutine object is introduced in one specific place:= the awaiter object's `await_suspend` method. That's the first plac= e where user code gets to touch a coroutine, and if the method doesn't = store it or otherwise keep it around, it's also the last.

That&#= 39;s what I meant when I said "adding a template". Because now, `= await_suspend` must become a template function. There's no other= way to capture a parameter of an arbitrary, compiler-generated type.
But what of generators and promises in such a scenario? A `generator<i= nt>` needs to be able to store any coroutine, so it has to... type erase= it. The promise type cannot be a template on the coroutine type, since it = was declared long before the coroutine handle appeared. And so forth.
In short, the entirety of P0057 is designed around a type-erased `corouti= ne_handle`. You can't simply declare that it's not type-erased and = expect everything to work reasonably. The entire design would need to be re= thought.

If you want this done, then you're going to need to go = through the effort of designing the feature to work without type erasure. T= hen you have to get someone to implement it. Then, you can know whether it = works just as well as P0057, whether it's equally easy to use, and how = much of a performance advantage it gets.

If any.

--

---
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_6486_896213012.1444798011002-- ------=_Part_6485_1764221694.1444798011001-- .