220 21736 <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> 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 18:57:55 -0700 (PDT) Lines: 232 Approved: news@gmane.org Message-ID: <58628096-14ae-42b2-89d3-c0bd2183bbc0@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6398_952166055.1444787875086" X-Trace: ger.gmane.org 1444787894 11494 80.91.229.3 (14 Oct 2015 01:58:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 01:58:14 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJHN62YAKGQEUV7MQWI@isocpp.org Wed Oct 14 03:58:00 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f199.google.com ([209.85.160.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmBKJ-0006ns-Af for gclcip-std-proposals@m.gmane.org; Wed, 14 Oct 2015 03:57:59 +0200 Original-Received: by ykoo7 with SMTP id o7sf36653530yko.3 for ; Tue, 13 Oct 2015 18:57:57 -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=2lSVDwT4mRnwsP9IeTzyj2DSibD9pxiaQWFqSahFvr8=; b=TiZ+4FgRxFhDuooq1IAKzu62QDQhStL6E13aQIzxxqlVmHF+iKCwvO8zft0On96tt9 fCt35R1Lv4+3ECYxAutLLfDLN95Rg/w2m6Y3Upj2bT/mzf0K2hxN5vqINLGljsoWLRsO zUlrcoeEnLZTOcsOo6Ka1F/hMqXk7WTnZjZ5ZUsRacQGPoLQsdcTJx9e8kTflftLDCzD CPrdrINltGLYW+IF1vdeoS+LuuccYKi/DI5eHtuyPzECBckBbpkYSpm4eaIeSkVfGTlY u/xR3s4WKmd6nZDK78O2FrSp2iuEEcvBmgEE5ltv4qRBU5KOEiH5fr2Y8S/M//kvSPp4 wVhg== 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=2lSVDwT4mRnwsP9IeTzyj2DSibD9pxiaQWFqSahFvr8=; b=etTQOtL0nww6pH54K6jWru2VKjwzbS/DD5TGKloirMvjOgc81KXTkJdW4mKK+e/P0H L/cI11U0mNvF/6XSr7gVILLC/JPknaeGs9XBHo+eoIthON7a6ChHiBkNyLYX5ACrLRWT mfZsaD2/uxW+/2iA/JdiJidhoV1T/zVDFvXaQ1FADBR3Kho7iwEUrgBDszdRlEbRuhvH wA43K0Hwu1WfEffOry+gYuvO3csf0KdK0W4C0ppai1uGNFwmN+H4JW9PPawwFHrm8t+o ZrR1a9O0R5crt5WChypAoeV9axtXjOlu61tQC8noq0M4Bua1X15K+I+sUdghliv9WadL q9EA== X-Gm-Message-State: ALoCoQmhr2YFXIWbACrO+cSO/X+OBifcQggqNJpHXdTEIdgjTYf/hVTOzOTUmR142qjCwrwyl8X2 X-Received: by 10.129.71.195 with SMTP id u186mr452293ywa.27.1444787877774; Tue, 13 Oct 2015 18:57:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.155.19 with SMTP id d19ls48070ioe.19.gmail; Tue, 13 Oct 2015 18:57:56 -0700 (PDT) X-Received: by 10.50.225.70 with SMTP id ri6mr212563igc.9.1444787876255; Tue, 13 Oct 2015 18:57:56 -0700 (PDT) In-Reply-To: <99bdb3ae-9214-4440-8572-4c47a61eda46@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:21736 Archived-At: ------=_Part_6398_952166055.1444787875086 Content-Type: multipart/alternative; boundary="----=_Part_6399_1366650080.1444787875087" ------=_Part_6399_1366650080.1444787875087 Content-Type: text/plain; charset=UTF-8 On Tuesday, October 13, 2015 at 7:45:42 PM UTC-4, Evgeny Panasyuk wrote: > > 14.10.2015 1:22, Nicol Bolas: >> >> On Tuesday, October 13, 2015 at 5:37:50 PM UTC-4, Evgeny Panasyuk wrote: >>> >>> 13.10.2015 2:03, Gor Nishanov: >>> > >>> > My main concern about P0057R0 is type-erasure - it is far from >>> being >>> > zero-overhead. >>> > >>> > >>> > I have had an outstanding challenge for a year already to anyone who >>> > thinks that way to come up with a real world problem, reduce it to >>> > managable size (say async_tcp_reader) write it up it both ways using >>> > P0057 and whatever you consider zero overhead and evaluate on three >>> > criteria: >>> >>> Example of real world problem is generator/yield. >>> An extra allocation here results in significant overhead. Even if some >>> kind of "small object optimization" scheme is used - it is still not >>> zero overhead. >>> >> >> 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: > vector x(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. 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. > 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. The only question that remains is this: given full inlining, where does the optimizer break down? Do you have any actual knowledge that it breaks down in common cases? Or can a smart one cover 80-90% of these cases? Stop talking theory as though this weren't an idea that has already been implemented on at least one compiler. > 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. 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. 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. Adding a template on top of everything only makes things harder. -- --- 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_6399_1366650080.1444787875087 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, October 13, 2015 at 7:45:42 PM UTC-4, Evgeny Panasyuk wrote:14.10.2015 1:22, Nicol Bolas:
On Tuesday, October 13= , 2015 at 5:37:50 PM UTC-4, Evgeny Panasyuk wrote:
13.10.2015 2:03, Gor Nishanov:
>
> =C2=A0 =C2=A0 My main concern about P0057R0 is type-erasure - it i= s far from being
> =C2=A0 =C2=A0 zero-overhead.
>
>
> I have had an outstanding challenge for a year already to anyone w= ho
> thinks that way to come up with a real world problem, reduce it to
> managable size (say async_tcp_reader) write it up it both ways usi= ng
> P0057 and whatever you consider zero overhead and evaluate on thre= e
> criteria:

Example of real world problem is generator/yield.
An extra allocation here results in significant overhead. Even if some= =20
kind of "small object optimization" scheme is used - it is st= ill not=20
zero overhead.

Except that he's already proven (in this thre= ad no less) that a good optimizer can elide the allocation. If the compiler= can reasonably make it zero overhead, then it is zero overhe= ad.



1. It is impossible (practical= ly) in general case.
For instance in case when we put coroutines in cont= ainer, like:
vector<coroutine> x(N);
In case of coroutines with concrete= types and sizeof known at compile - this can be done within single allocat= ion.
But if coroutine type is erased the we will have N+1 allocations in= general case - it can't be practically elided.
<= div>
Ignoring the rest of the discussion on this point, I never claimed = that P0057 could guarantee elision in the case you present here. Before, yo= u asked about a specific problem, and I answered with a specific exa= mple showing that it was elidable. What you've shown here hardly dispro= ves my point.

Also... how does `vector<coroutine>` make any ki= nd of sense with regard to P0114? The type isn't type erased, so each c= oroutine has its own type. Therefore, in order to put them in a homogeneous= container like `vector`, you'll have to type-erase them. Which require= s memory allocation.

At which point, your version gains nothing over P0057.
=C2=A0
=
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 wo= uld 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 c= all are inlined. If they're not inlined, you have to manually box them = (and the boxing function is no longer resumable). Boxing involves type eras= ure. 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 t= he TU has access to all relevant code.

The only question that remain= s is this: given full inlining, where does the optimizer break down?
Do you have any actual knowledge that it breaks down in common cases? Or c= an a smart one cover 80-90% of these cases? Stop talking theory as though t= his weren't an idea that has already been implemented on at least one c= ompiler.
=C2=A0
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 ju= st in a different place.

P0114 requires implementations to go throug= h whole hierarchies of inline function calls and generate types that repres= ent their stacks. It puts a lot of burden on implementer too; it's just= in the implementation of the feature rather than the optimization p= hase.

It's more or less the same work either way. Though admitte= dly, the P0114 does make it a bit easier for the compiler to see it.
4. C++11 has lambd= as with concrete type - this ensures zero overhead, and fits naturally into= language. We don't have type-erasured closures. We can use external ty= pe erasure like std::function when needed.
Why we should have type-erasu= re for stackless coroutines?

Because impleme= nting await machinery (promises, awaitable, etc) is hard enough as it is. A= dding a template on top of everything only makes things harder.

--

---
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_6399_1366650080.1444787875087-- ------=_Part_6398_952166055.1444787875086-- .