220 21739 <561DC957.8080603@gmail.com> 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: Wed, 14 Oct 2015 06:17:43 +0300 Lines: 153 Approved: news@gmane.org Message-ID: <561DC957.8080603@gmail.com> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1444792682 16081 80.91.229.3 (14 Oct 2015 03:18:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 03:18:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC54TLGKR4LBBXMS66YAKGQE5DIXO6Y@isocpp.org Wed Oct 14 05:17:54 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f198.google.com ([209.85.217.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmCZd-0007V4-6a for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 05:17:53 +0200 Original-Received: by lbbti1 with SMTP id ti1sf18781860lbb.3 for ; Tue, 13 Oct 2015 20:17:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-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=efU5L6O+jo5ajfw3AT+HjzNIAdZuKSr2x8MYybG8doM=; b=LhMzBTSdHf2M8MrO3zeSleaOmr8cjT5uCFogXVr+w3ntXaG87T1KvEJjytlALE7mF9 phiqoMWg6SGfWFMu3WDdGW8Ne4RxFA1bq7HJJF5c1Gwt6dxIsyy7nVcFjNpwNIa1r3jd Sxtydc3gM4IDUBdlKw7qRl24WwlamliZYqkK4T9QL/C2rtMMw2FzAjYjgWzp9FEt1F/5 F2/JYVKeQ7ec5UVRIZJQ7yJivja6PemERdSMWEoCk1KIiHw6INtdAa2U8/sRxTa3GXlw VtWoy3WnlWI5GwcEgni+oTE4+iCWf0f6J9paUJTKIwLr5nk1eQ4aVs8z1goizAnym/+g +/rQ= X-Gm-Message-State: ALoCoQmZCUIz2FbfTdaezIWNDyFQ/o+FfIIsTa0IMHA2jvOIZ2jVWQUsjImNDQLlNmS6Oud4RkgS X-Received: by 10.180.81.165 with SMTP id b5mr4945361wiy.1.1444792672625; Tue, 13 Oct 2015 20:17:52 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.155.70 with SMTP id d67ls311293lfe.25.gmail; Tue, 13 Oct 2015 20:17:48 -0700 (PDT) X-Received: by 10.112.150.201 with SMTP id uk9mr338965lbb.102.1444792668712; Tue, 13 Oct 2015 20:17:48 -0700 (PDT) Original-Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com. [2a00:1450:4010:c07::235]) by mx.google.com with ESMTPS id pr8si4192280lbc.15.2015.10.13.20.17.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2015 20:17:48 -0700 (PDT) Received-SPF: pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) client-ip=2a00:1450:4010:c07::235; Original-Received: by lffv3 with SMTP id v3so5126817lff.0 for ; Tue, 13 Oct 2015 20:17:48 -0700 (PDT) X-Received: by 10.25.163.199 with SMTP id m190mr222246lfe.13.1444792668374; Tue, 13 Oct 2015 20:17:48 -0700 (PDT) Original-Received: from [192.168.0.186] (81.13.117.87.donpac.ru. [87.117.13.81]) by smtp.googlemail.com with ESMTPSA id u12sm984946lfd.40.2015.10.13.20.17.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2015 20:17:47 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> X-Original-Sender: Evgeny.Panasyuk@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of evgeny.panasyuk@gmail.com designates 2a00:1450:4010:c07::235 as permitted sender) smtp.mailfrom=evgeny.panasyuk@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:21739 Archived-At: 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. > > 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); | For example, imagine some kind of TCP server, coroutine for each incoming connection does same job, has same locals, and as the consequence they have same type. LIVE DEMO using macro-based stackless coroutines from Boost.Asio: http://coliru.stacked-crooked.com/a/0c09744abd5e57ae > > 2. Even if consider only functions scopes - escape analysis would > not give 100% guarantee for elision in every case. First of all - I > think it would hit halting problem, second - some of functions in > call tree may not be inlined for adequate reasons - and this would > blind analysis. > > > P0114 /requires/ that all resumable functions you call are inlined. If > they're not inlined, you have to manually box them (and the boxing > function is no longer resumable). Boxing involves type erasure. And as > previously stated, memory allocation. > > In order for P0114 to not require the same allocations as P0057, you > must be using resumable functions directly, without boxing. So they must > be inline. And therefore, your second problem is a non-issue for > comparable cases: the compiler for the TU has access to all relevant code. It requires inlining of resumable things which are inside body of resumable functions. Outside of resumable context you can .resume() coroutine without inlining. > > The only question that remains is this: given full inlining, where does > the optimizer break down? For instance, when you store coroutine in some container, not an unusual case. > Stop talking theory as > though this weren't an idea that has already been implemented on at > least one compiler. I am not talking specifically about P0114. I am talking about stackless coroutines with concrete non-type-erased types. And this is already implementable in macro-library form. I already showed several examples in current topic, even await for List Monad. And these example are live - you can test them - modify and recompile it with your browser just by several mouse clicks - it is not just a theory, it is proven to work approach. > > 3. This would put additional burden on implementers, and I don't see > reasonable benefits which we get for such burden. > > > No, it doesn't. Or rather, it's the same burden, it's just in a > different place. It is not the same burden. Stackless coroutines with concrete types, P0114, as well as macro-based solutions - do not need special tricky allocation elision, they just don't do any allocation in a first place. > P0114 requires implementations to go through whole hierarchies of inline > function calls and generate types that represent their stacks. It puts a > lot of burden on implementer too; it's just in the implementation of the > feature rather than the /optimization/ phase. > > It's more or less the same work either way. Though admittedly, the P0114 > does make it a bit easier for the compiler to see it. Again, I am not talking specifically about P0114. Even P0057 can be changed to have concrete coroutine type. > > 4. C++11 has lambdas with concrete type - this ensures zero > overhead, and fits naturally into language. We don't have > type-erasured closures. We can use external type erasure like > std::function when needed. > Why we should have type-erasure for stackless coroutines? > > > Because implementing await machinery (promises, awaitable, etc) is hard > enough as it is. It is implementable to some extent even which macros, but with not pretty syntax. > Adding a template on top of everything only makes > things harder. Which template? Do you mean mandatory inlining in P0114? It requires this inlining in order to solve orthogonal and harder problem, not problem of allocations. N4244, somewhat predecessor of P0114 - also does not force type-erasure and allocation, but it does not require inlining you are referring to. -- --- 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/. .