220 21295 <36f46c03-b1f1-4230-b686-a7a9a1c491cb@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Mon, 5 Oct 2015 07:42:04 -0700 (PDT) Lines: 160 Approved: news@gmane.org Message-ID: <36f46c03-b1f1-4230-b686-a7a9a1c491cb@isocpp.org> References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <1bf00a8f-5f20-43de-a319-2712ab34eafd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1625_1099703307.1444056124710" X-Trace: ger.gmane.org 1444056130 12910 80.91.229.3 (5 Oct 2015 14:42:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 14:42:10 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBPMYZKYAKGQEKHDCYBQ@isocpp.org Mon Oct 05 16:42:09 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 1Zj6xr-0000uk-CT for gclcip-std-proposals@m.gmane.org; Mon, 05 Oct 2015 16:42:07 +0200 Original-Received: by qkey1 with SMTP id y1sf245339596qke.0 for ; Mon, 05 Oct 2015 07:42:06 -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=IV6RKNebAtJE2dhBa/K6PZEyEFiClbMK6EXlwbXvqjw=; b=oux0zfrhGJAn3tLhHlW2V96N1ZZ3EPcyKTWqePdql7KylxZIdFYTGRDFYgpMRF3hXg 1JW961XoGxSAwx0OykZRxQj6OfsABXP9+fLR/NnWImgtJ0W77GC8ieZajYfN3v1Mm1g1 bTFgyV0L/6ZA2rdn9YsfXWRKtXeoj1llaD3GIdEmY56CunsnyCuyeBdGOBLUQl5SkdKA G4/fRFYTCCRf4OMKwD8Y/nZig3psttDCqVV5hmkMnVwkVWj0Iut1mWCbVr6yF9jHJFFC FYJC+gc1K1mqPbUxme6FU6Q6OpVuvvU63z9D7Q71Wu4B/5uidIIPaWufYpM7G9w9LIoJ N5Tg== 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=IV6RKNebAtJE2dhBa/K6PZEyEFiClbMK6EXlwbXvqjw=; b=M/iBqqdUGuFqYeiU2TToBZ4wkrhWHxFdRbZxA5sVMxng7AJ8Q0z5f/7uafY7ZJH8zz 0RpTWBHTiFyXz2wuSKIzvIDGq9hjDacz+Boe7B8C1CEKHfOHJ7+7nzu03YAzOYgfY0xA t2oDJT22A+6KqfNr0uiNfcveu+o6HZaJOmwBlYDqKv+m0tZdu7D1rBNznAnF3Ch9n3Sq Pdysj5pXFCO/8Nsb4STymFatysybkSeAdYha6v6gygmFxBMjJNJLL6wiX62OuO4RXscZ H3YMhMbA3O060n1jfJnqxuY4xhGeD9Jsy01jLAL0gjbqT+c5CCZhDhoy2B/EVJ+y64of rCIQ== X-Gm-Message-State: ALoCoQlvIfezHfcLROkABn95hSaFESnyOHTBF8RAAz2XgYmfNvhMZt+F8FmGdRvF1drhIARwP1tm X-Received: by 10.140.237.202 with SMTP id i193mr26302873qhc.10.1444056126700; Mon, 05 Oct 2015 07:42:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.136.196 with SMTP id qc4ls1245289igb.25.gmail; Mon, 05 Oct 2015 07:42:05 -0700 (PDT) X-Received: by 10.50.8.42 with SMTP id o10mr97073iga.7.1444056125792; Mon, 05 Oct 2015 07:42:05 -0700 (PDT) In-Reply-To: <1bf00a8f-5f20-43de-a319-2712ab34eafd@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:21295 Archived-At: ------=_Part_1625_1099703307.1444056124710 Content-Type: multipart/alternative; boundary="----=_Part_1626_530967356.1444056124719" ------=_Part_1626_530967356.1444056124719 Content-Type: text/plain; charset=UTF-8 On Sunday, October 4, 2015 at 7:14:05 AM UTC-4, german...@hubblehome.com wrote: > > On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote: >> >> I see a bit of a mistake, again, in my opinion, to embed a scheduler into >>> the language, when you could do it in a library, as Christopher's paper >>> shows. >>> >> >> There is absolutely no embedded scheduler in P0057 and never was. >> > > Hello Gor. If there is no scheduler, I do not understand how await can > work. Forgive my ignorance, as I said above, I do not know to detail. But > my understanding is that if you have a call to await, that state for the > suspended coroutine must be kept somewhere. Where? I understand that this > state must live somewhere. Where is that state held? > After reading the proposal a bit, it's clear that `await` does not actually "wait" on anything. For the most part, it's a syntactic transformation on an expression. The expression that `await` applies to must result in an object that has a certain interface. And the logic for `await` calls that interface. If there is any scheduling logic going on, it is in the implementation of that interface, not in `await` itself. As such, the storage in question is in the object resulting from the `await` expression. And the closest to scheduling that `await` gets is the decision to check if the value is ready before yielding. Sorry if I make any mistakes during my explanation, I am not an expert on > this papers, I just happen to understand quite well > Christopher's metaphor of function objects and I see very difficult > something more performant that non-type erased coroutines > that only take the space strictly required. > How much more performant? Is it enough to be worth arguing about? After all, most things you'll be using await for won't be cheap operations. Will you actually *notice* any such performance loss? That's not to say that I much *like* resumable functions as a proposal. I can't say I look forward to doing a bunch of `await`ing and using specialized return values just to be able to allow some deeply nested function perform a `yield` back to the original caller. And that's not even using threading. That being said, I noticed one thing about resumable expressions that makes it a complete deal-breaker for me: When a resumable function is used in a resumable expression, the definition > of the function must appear before the end of the translation unit. > Um, no. I understand that this requirement is not necessarily recursive. That is, you don't need the definition of every function the resumable one calls. However, if the resumable one you call *itself* makes a resumable call, you will need those definitions. And if they make resumable calls, you'll need *those* definitions. And so forth. If it's a choice between forbidding inlining and *forcing* inlining, I'll accept the overhead of forbidding inlining. -- --- 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_1626_530967356.1444056124719 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, October 4, 2015 at 7:14:05 AM UTC-4, german...@hubblehome.com wr= ote:
On Sunday= , October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote:
= I see a bit of a mistake, again, in my opinion, to embed a scheduler into t= he language, when you could do it in a library, as Christopher's paper = shows.

There is absolutely no embedde= d scheduler in P0057 and never was.

Hello Gor. If there is no scheduler, I do not understand how await ca= n work. Forgive my ignorance, as I said above, I do not know to detail. But=
my understanding is that if you have a call to await, that state= for the suspended coroutine must be kept somewhere. Where? I understand th= at this state must live somewhere. Where is that state held?

After reading the proposal a bit, it's clear that `a= wait` does not actually "wait" on anything. For the most part, it= 's a syntactic transformation on an expression.

The expression t= hat `await` applies to must result in an object that has a certain interfac= e. And the logic for `await` calls that interface. If there is any scheduli= ng logic going on, it is in the implementation of that interface, not in `a= wait` itself.

As such, the storage in question is in the object resu= lting from the `await` expression.

And the closest to scheduling tha= t `await` gets is the decision to check if the value is ready before yieldi= ng.

Sorry if I make any mistakes during my explanation, I a= m not an expert on this papers, I just happen to understand quite well
Christopher's metaphor of function objects and I see very difficu= lt something more performant that non-type erased coroutines
that= only take the space strictly required.

Ho= w much more performant? Is it enough to be worth arguing about? After all, = most things you'll be using await for won't be cheap operations. Wi= ll you actually notice any such performance loss?

That's = not to say that I much like resumable functions as a proposal. I can= 't say I look forward to doing a bunch of `await`ing and using speciali= zed return values just to be able to allow some deeply nested function perf= orm a `yield` back to the original caller. And that's not even using th= reading.

That being said, I noticed one thing about resumable expres= sions that makes it a complete deal-breaker for me:

When a resumable function is use= d in a resumable expression, the definition of the function must appear bef= ore the end of the translation unit.

Um, no. I understa= nd that this requirement is not necessarily recursive. That is, you don'= ;t need the definition of every function the resumable one calls. However, = if the resumable one you call itself makes a resumable call, you wil= l need those definitions. And if they make resumable calls, you'll need= those definitions. And so forth.

If it's a choice betwee= n forbidding inlining and forcing inlining, I'll accept the over= head of forbidding inlining.

--

---
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_1626_530967356.1444056124719-- ------=_Part_1625_1099703307.1444056124710-- .