220 21751 article Path: news.gmane.org!not-for-mail From: German Diago 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 14:12:19 +0700 Lines: 126 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> <78f1c83a-f866-4f64-aba2-939078fdc58b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0b865e7dcac605220b48ad X-Trace: ger.gmane.org 1444806752 20650 80.91.229.3 (14 Oct 2015 07:12:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 07:12:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKJVOEEVYNRBVEA7CYAKGQEKC3D3WA@isocpp.org Wed Oct 14 09:12:28 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qg0-f72.google.com ([209.85.192.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmGEd-00005I-8a for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 09:12:27 +0200 Original-Received: by qgx61 with SMTP id 61sf45654085qgx.3 for ; Wed, 14 Oct 2015 00:12:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=tPb7qyUmxgOUfG2gPzB0nGLQAfZVwmblM+vbS9iNHHQ=; b=S/0MhAhGG6EubOFbX0HtN5LE1ubWXj8jS5muQYhaSgUZ+MM7tMaedQvonRdp02bwy3 tuLSmHe3CvQQIVULUqZRl4vCBptuU5jt45BlcnvEPeFEEZgDmlyyffW4VpGb442mtPwd pvl4DjxMiHndI4lcWp0LmwDp5NAriB7C89FVpRYzfg53FQM9eUpc9pWPK+q277i4bee9 Gziy/PlqasC2MY76MeIECkDhtiktWdHBbAAmMZQ7DzZ+2dR1G6aQxw3b0aMVnVHDvrRO JXFH6j7QWiqVUm8QZ0txdHHZTyax2WdycRnqWpPbPHzulw9UvQa+Fd92aPsW0+tgVcyC LHNQ== X-Gm-Message-State: ALoCoQnz316L3a7hmdRjpp6PUluMjkVU8UOqTY7aaaqnSizuHgfwLiEhPn0UyVmrGhQ7OQmS/C7a X-Received: by 10.13.247.132 with SMTP id h126mr1328963ywf.56.1444806741499; Wed, 14 Oct 2015 00:12:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.202 with SMTP id 68ls22395qgx.97.gmail; Wed, 14 Oct 2015 00:12:20 -0700 (PDT) X-Received: by 10.129.104.198 with SMTP id d189mr1031350ywc.219.1444806740053; Wed, 14 Oct 2015 00:12:20 -0700 (PDT) Original-Received: from mail-yk0-f180.google.com (mail-yk0-f180.google.com. [209.85.160.180]) by mx.google.com with ESMTPS id b63si3115008ywc.76.2015.10.14.00.12.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 00:12:20 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.160.180 is neither permitted nor denied by best guess record for domain of german.diago@hubblehome.com) client-ip=209.85.160.180; Original-Received: by ykoo7 with SMTP id o7so39470706yko.0 for ; Wed, 14 Oct 2015 00:12:19 -0700 (PDT) X-Received: by 10.129.153.22 with SMTP id q22mr1033055ywg.328.1444806739718; Wed, 14 Oct 2015 00:12:19 -0700 (PDT) Original-Received: by 10.37.80.72 with HTTP; Wed, 14 Oct 2015 00:12:19 -0700 (PDT) In-Reply-To: X-Original-Sender: german.diago@hubblehome.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.160.180 is neither permitted nor denied by best guess record for domain of german.diago@hubblehome.com) smtp.mailfrom=german.diago@hubblehome.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:21751 Archived-At: --94eb2c0b865e7dcac605220b48ad Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 7:11 AM, Gor Nishanov wrote: > Okay. Slightly less cryptic reply. Coroutine frame must be stationary once > the coroutine starts running. > Resumable Expressions abandoned movability/copyability of the lambda* that > was present in earlier resumable lambda proposal. > The new paper mentions about opt-in to move/copy. Could be proposed. I find it useful. > > The difference is that in Resumable Expressions you must do type erasure > by hand which is difficult to eliminate. > Whereas in P0057 compiler decides whether it needs to do type erasure or > not, thus, allowing to optimize it out when unnecessary. > What I really like about resumable expressions is that it is really, really obvious and lightweight how it works. Your implementation, Gor, looks good to me. But I am concerned we can avoid some of the trouble. I do not see a problem in having library-abstracted generators on top of resumable expressions. Why should we embed a full protocol in the language itself when we can get it done with only "break resumable" and have the rest on top of library abstractions. I just do not get why, because additionally, you can have your generators, your await, everything, and remove type erasure and have *real* zero overhead from the beginning. Without any fancy optimizations or escape analysis. I am against introducing in the language something that is not inherently zero-overhead when we have alternatives. Do not get me wrong, the proposal gives a lot of inspiration, in my opinion, for how to do a few great things. But I honestly think we can do better. I know about your suggestion on how to compare, but I simply do not have enough time. I hope I had, but I am short on time. I see resumable expressions more understandable respect to the traditional c++ model and I think they guarantee zero-overhead in more cases than your proposal. Though, I recognize that the numbers you show for your implementation look good, but, again: 1. need compiler optimizations such as escape analysis. 2. no matter the way you put it, they are not inherently zero-overhead for the curent state of the art. Even you mentioned clang is planning to introduce some optimization that is not available already. I think we should not get into that trouble, we have alternatives. There are more compilers around also: Intel, IBM... -- --- 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/. --94eb2c0b865e7dcac605220b48ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 14, 2015 at 7:11 AM, Gor Nishanov <gornishanov@gmail.c= om> wrote:
Okay. Slightly less cryptic reply. Coroutine frame must be stationary once= the coroutine starts running.
Resumable Expressions abandoned movabili= ty/copyability of the lambda* that was present in earlier resumable lambda = proposal.

The new paper me= ntions about opt-in to move/copy. Could be proposed. I find it useful.
= =C2=A0
=

The difference is that in Resumable Expressions you mus= t do type erasure by hand which is difficult to eliminate.
Wherea= s in P0057 compiler decides whether it needs to do type erasure or not, thu= s, allowing to optimize it out when unnecessary.

What I really like about resumable expressions is tha= t it is really, really obvious and lightweight how it works.
= Your implementation, Gor, looks good to me. But I am concerned we can avoid= some of the trouble. I do not see a problem
in having librar= y-abstracted generators on top of resumable expressions. Why should we embe= d a full protocol in the language itself
when we can get it d= one with only "break resumable" and have the rest on top of libra= ry abstractions. I just do not get why,
because additionally,= you can have your generators, your await, everything, and remove type eras= ure and have *real* zero overhead
from the beginning. Without= any fancy optimizations or escape analysis. I am against introducing in th= e language something that
is not inherently zero-overhead whe= n we have alternatives. Do not get me wrong, the proposal gives a lot of in= spiration, in my opinion,
for how to do a few great things. B= ut I honestly think we can do better.

I know about your s= uggestion on how to compare, but I simply do not have enough time. I hope I= had, but I am short on time.
I see resumable expressions mor= e understandable respect to the traditional c++ model and I think they guar= antee zero-overhead
in more cases than your proposal. Though,= I recognize that the numbers you show for your implementation look good, b= ut, again:

1. need compiler optimizations such as escape = analysis.
2.=C2=A0 no matter the way you put it, they are not= inherently zero-overhead for the curent state of the art. Even you mention= ed clang
is planning to introduce some optimization that is n= ot available already. I think we should not get into that trouble,
we have alternatives. There are more compilers around also: Intel, IB= M...


--

---
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>.
--94eb2c0b865e7dcac605220b48ad-- .