220 21843 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: Sat, 17 Oct 2015 08:08:52 -0700 (PDT) Lines: 321 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> <2e09660f-d688-474a-8811-85fb041f68b8@isocpp.org> <8b78abb4-16b6-4b65-8513-6e2c17317647@isocpp.org> <71a00cd0-bd53-4e00-8b00-c9bc97134df7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19_1073346561.1445094532903" X-Trace: ger.gmane.org 1445094538 2773 80.91.229.3 (17 Oct 2015 15:08:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:08:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBBWJRGYQKGQED7KP5HI@isocpp.org Sat Oct 17 17:08:58 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnT6O-0003il-8O for gclcip-std-proposals@m.gmane.org; Sat, 17 Oct 2015 17:08:56 +0200 Original-Received: by qkfm62 with SMTP id m62sf121156768qkf.2 for ; Sat, 17 Oct 2015 08:08:55 -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=f02TZyh6Vx3fXYBKuQnFoFwU2ws/limRDHSUWsnI6c4=; b=LUUAVyPwbt165VO66PJ/TgTA0zS3Tgb2yxdhZNXIYGdKlStyKSyXnvkhTlCPJNcB+C owi9B0RQfBaS9oAkaZOFTzbM4uw1vBeFOm97/xXxva6mQ3ivUQIPfrMQhqI1jVSbKQ6M 9E60sWdoCW0yieX8aXzjNeq0y/PqJqycmr4RCSiI6pBHkcnLXZ/vYu57eFOUMDBwkXaH 8vBiRNR5Y7FA4fEv1egrwUXDsWAaNzbChS2U5ZqZFYaC1k8olUdiw+ZQjK1+ZUDVy0r3 quklKPrm/ZPlk4COLmCUE9IEk8iS3dhrw04bdLmJrlT0hUHi8mcxnEQ7oZ/0wmZP2cww 4VQw== 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=f02TZyh6Vx3fXYBKuQnFoFwU2ws/limRDHSUWsnI6c4=; b=Q/694SmFdWAQgTyuoqd7zwnG8QM81QAdIPEK3BYx+4Nwyfsfuq1rY/0vF8bx3/9MYZ EmxqsZOeO+mURFBWFWl+A1UFUualfBcwrj2g0A9+GOZW/8cySmb8cxWwh4VVuF4HAYAt 2Z3Hl1ZtoSgrWIyg87Owf8xvHVGXqNCuC4mbnbLGX636BnW1xCTzJnPvhHLOG8fa0Xpm qOEnac1QeLYhn1+CSoMQ3qmcD8c786tqEOg30nO6B8v+/2XHAwNMWqsuzdMo5he64MJm 9jkcvqkvi/ewiiTPj60f6d31x1rLTge3I5QCCKZBy3Q4CSuPNiFNi5tOTLDGaHOOADHM oBWw== X-Gm-Message-State: ALoCoQmDDK2Dy+u2nSAOWCk5zk5W6Dx5RZioGHH4PxUQpT9n9ItIFMqHHvvvRTysnIMkqcYNy7Xl X-Received: by 10.140.201.197 with SMTP id w188mr17284664qha.1.1445094535063; Sat, 17 Oct 2015 08:08:55 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.39.11 with SMTP id n11ls928170ion.59.gmail; Sat, 17 Oct 2015 08:08:54 -0700 (PDT) X-Received: by 10.50.8.2 with SMTP id n2mr232871iga.7.1445094534198; Sat, 17 Oct 2015 08:08:54 -0700 (PDT) In-Reply-To: <71a00cd0-bd53-4e00-8b00-c9bc97134df7@isocpp.org> 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:21843 Archived-At: ------=_Part_19_1073346561.1445094532903 Content-Type: multipart/alternative; boundary="----=_Part_20_198429440.1445094532904" ------=_Part_20_198429440.1445094532904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, October 17, 2015 at 7:35:35 AM UTC-4, Evgeny Panasyuk wrote: > > 16 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2015 =D0=B3., 19:26:18 UTC+= 3 Nicol Bolas : > Your proposal seems to require a lot of special-case handling at the type= =20 >> level. >> > > No, it does not require much of special-case handling. > =20 > >> >> it is possible to return type with template inside. For instance >>> struct generator >>> { >>> template class coroutine_value> >>> struct apply { ... }; >>> }; >>> >>> >> OK, so... what does that do? Does `generator` store the coroutine? >> > > It describes how to create result type. > Are you saying that if the function says `generator foo()`, then the=20 function *really* returns `generator::apply`? How exactly is this auto-magic transformation *not* "special-case=20 handling"? Because it looks pretty special-case to me. Your proposal exposes *everyone* to the deep guts of working with a=20 >> coroutine. All just for some minor performance gain that in most situati= ons=20 >> compilers can optimize out. >> > > It is not a minor difference. One allocation and virtual/indirect calls= =20 > for resumption is a huge overhead for things like generators. > Two words: citation needed. See below for details: And even when they can't, *you* can optimize them out with a decent=20 >> allocator. >> > > First of all, I don't want to use custom allocators for simple things lik= e=20 > generators. Second, even custom allocator is not zero-overhead - at least= =20 > it must check size, because it is not known at compile time. > You are genuinely and seriously claiming that a conditional branch based on= =20 two numbers constitutes "overhead". And this overhead is so incredibly=20 *burdensome* (despite only happening in the generator's initialization)=20 that any and all language changes to remove said overhead are completely=20 justified. It's statements like this that are why I hate it when people start bringing= =20 up the zero-overhead principle as some kind of religious doctrine. Why does this overhead matter? The performance of a generator that returns integers on a fixed range is=20 *irrelevant*. Nobody in their right mind is going to use generators for=20 that. We have *ranges* for that. The purpose of a generator, in a *real application*, is to be able to have= =20 a process take an arbitrary amount of time. You get a value from that=20 process, then you do something, then get another. Until the next value is= =20 available, your process stops. That's the idea. If the cost of generating that value is non-trivial, then the cost of the= =20 virtual call to do said generation is negligible. If the cost of *using*=20 that value is non-trivial, then the cost of the virtual call is again=20 irrelevant. Which means that, if either the creation or consumption of that data is at= =20 all meaningful, if it requires anything more than the most basic few lines= =20 of code, then it *does not matter* what the overhead of the call is. It=20 will be a rounding error in any performance analysis you would care to=20 perform on your code. The overhead here is only "huge" if your generators *and* processing code= =20 are so trivial that your code would be written better as a straight-up=20 range-based for loop. If you are actually doing meaningful work, then any= =20 call overhead will be insignificant next to that. This is why the zero-overhead principle is not some inviolate rule of=20 *doctrine* which justifies any and all language changes. It is a *principle= *,=20 who's application must be weighed against all other applicable factors.=20 It's there to remind us not to needlessly add undue overhead. It is not=20 mean to be used to judge that any proposal is a priori wrong just because= =20 there may be a lower overhead way to do it. And P0057 does gain something from this overhead. It gains not having=20 automatic generation of return types, so functions still make sense. It=20 gains the ability to transfer control to someone other than the caller=20 (which your proposal does not), allowing the feature to be useful for *more= =20 than* just "generators". And so forth. Even if we accept that this is a good way to make a proposal... it's not a= =20 >>>> *proposal* yet. It's just some ideas being batted around on a forum.= =20 >>>> None of the various coroutine proposals do anything like what you've= =20 >>>> suggested. Why should we halt or delay progress on P0057 because you= =20 >>>> *think* you might be able to do better? >>>> >>>> >>> If authors of P0057 still would insist on design with intrinsic overhea= d=20 >>> and high burden on optimizers, then you are right - probably viable pat= h is=20 >>> to make another proposal. >>> >> >> Passive-aggressiveness does not prove your point. >> > > Constantly calling things "nonsense" things you do not like - does not=20 > prove your point either. > Except that what I called "syntactic nonsense" really was syntactic=20 nonsense. You declared that `generator` was a template type in your=20 original code. And you returned it without providing a template argument.= =20 That's not legal C++ code, so calling it "syntactic nonsense" is perfectly= =20 valid. Whereas the "high burden on optimizers" statement remains without=20 foundation. > --=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_20_198429440.1445094532904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, October 17, 2015 at 7:35:35 AM UTC-4, Evgeny Panasyuk wrote:
16 =D0=BE=D0=BA=D1=82=D1=8F= =D0=B1=D1=80=D1=8F 2015 =D0=B3., 19:26:18 UTC+3 Nicol Bolas :
Your proposa= l seems to require a lot of special-case handling at the type level.

No, it does not require much of special-case handl= ing.
=C2=A0

=
it is possibl= e to return type with template inside. For instance
struct generator
{
=C2=A0 =C2=A0 template<= <= span style=3D"color:#008">template= <typename> class coroutine_value>
=C2=A0 =C2=A0 struct<= /span> apply {= ... };=
};<= span style=3D"color:#000">


OK, so... what does that do? Does `generator` store the = coroutine?

It describes how to create result typ= e.

Are you saying that if the function= says `generator foo()`, then the function really returns `generator= ::apply<InsertCompilerThingHere>`?

How exactly is this auto-ma= gic transformation not "special-case handling"? Because it= looks pretty special-case to me.

Your proposal exposes everyone to the deep guts of wo= rking with a coroutine. All just for some minor performance gain that in mo= st situations compilers can optimize out.

It is = not a minor difference. One allocation and virtual/indirect calls for resum= ption is a huge overhead for things like generators.

Two words: citation needed.

See below for details:
=
And even when they can&#= 39;t, you can optimize them out with a decent allocator.

First of all, I don't want to use custom allocators= for simple things like generators. Second, even custom allocator is not ze= ro-overhead - at least it must check size, because it is not known at compi= le time.

You are genuinely and serious= ly claiming that a conditional branch based on two numbers constitutes &quo= t;overhead". And this overhead is so incredibly burdensome (des= pite only happening in the generator's initialization) that any and all= language changes to remove said overhead are completely justified.

= It's statements like this that are why I hate it when people start=20 bringing up the zero-overhead principle as some kind of religious=20 doctrine.

Why does this overhead matter?

The performance of a= generator that returns integers on a fixed range is irrelevant. Nob= ody in their right mind is going to use generators for that. We have ran= ges for that.

The purpose of a generator, in a real applicati= on, is to be able to have a process take an arbitrary amount of time. Y= ou get a value from that process, then you do something, then get another. = Until the next value is available, your process stops. That's the idea.=

If the cost of generating that value is non-trivial, then the cost = of the virtual call to do said generation is negligible. If the cost of = using that value is non-trivial, then the cost of the virtual call is a= gain irrelevant.

Which means that, if either the creation or consump= tion of that data is at all meaningful, if it requires anything more than t= he most basic few lines of code, then it does not matter what the ov= erhead of the call is. It will be a rounding error in any performance analy= sis you would care to perform on your code.

The overhead here is onl= y "huge" if your generators and processing code are so tri= vial that your code would be written better as a straight-up range-based fo= r loop. If you are actually doing meaningful work, then any call overhead w= ill be insignificant next to that.

This is why the zero-overhead pri= nciple is not some inviolate rule of doctrine which justifies any an= d all language changes. It is a principle, who's application mus= t be weighed against all other applicable factors. It's there to remind= us not to needlessly add undue overhead. It is not mean to be used to judg= e that any proposal is a priori wrong just because there may be a lower ove= rhead way to do it.

And P0057 does gain something from this overhead= .. It gains not having automatic generation of return types, so functions st= ill make sense. It gains the ability to transfer control to someone other t= han the caller (which your proposal does not), allowing the feature to be u= seful for more than just "generators". And so forth.
Even if we a= ccept that this is a good way to make a proposal... it's not a propo= sal yet. It's just some ideas being batted around on a forum. None = of the various coroutine proposals do anything like what you've suggest= ed. Why should we halt or delay progress on P0057 because you think = you might be able to do better?


If autho= rs of P0057 still would insist on design with intrinsic overhead and high b= urden on optimizers, then you are right - probably viable path is to make a= nother proposal.

Passive-aggressivenes= s does not prove your point.

Constantly calling = things "nonsense" things you do not like - does not prove your po= int either.

Except that what I called = "syntactic nonsense" really was syntactic nonsense. You declared = that `generator` was a template type in your original code. And you returne= d it without providing a template argument. That's not legal C++ code, = so calling it "syntactic nonsense" is perfectly valid.

Whe= reas the "high burden on optimizers" statement remains without fo= undation.

--

---
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_20_198429440.1445094532904-- ------=_Part_19_1073346561.1445094532903-- .