220 21627 <86924069-44d0-447f-bf8a-a42e46579832@isocpp.org> article Path: news.gmane.org!not-for-mail From: Gor Nishanov 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: Mon, 12 Oct 2015 16:03:34 -0700 (PDT) Lines: 92 Approved: news@gmane.org Message-ID: <86924069-44d0-447f-bf8a-a42e46579832@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6330_1593848067.1444691014146" X-Trace: ger.gmane.org 1444691028 19017 80.91.229.3 (12 Oct 2015 23:03:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 23:03:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBR7Y6CYAKGQETB6WEIY@isocpp.org Tue Oct 13 01:03:38 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zlm80-0007uM-QW for gclcip-std-proposals@m.gmane.org; Tue, 13 Oct 2015 01:03:36 +0200 Original-Received: by igcxw12 with SMTP id xw12sf6487654igc.0 for ; Mon, 12 Oct 2015 16:03:36 -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=m6UXy22CoKz9+8Jp0L1B1lPP1hKjha3hRN1CDWu8c4o=; b=k9xvs2uegSTPornUt4zEMCK/jVhm+/ZN6NYkMjfQj9uHOmBVSZSGGOS1cIuNpurqrc 4WjO6Z7Lldtgvn6pBqGz2gu1IK9AccCy/Cgst2SpkxGZ7O7bJuZlVcnzmsiBEDC9KfCG 9npc4d1kmjLHVjHddunBfya6zT1S4Qq/XfjjcuWNa5dlYM7gjcCA+UuK7Sjyont6NiNr 1SK3PH1D7y8fNH30OZ+TzHbZtoGeIYnn5VnnlWUcMZjxTmxITvHHvIAcbZsAVXrsiRLc QuDRRzp6ffzjSJIFycbPLwN3pqQxJYSYuSUXn3CYqhDAD5MZZtbMVFt7abjnwits6tew 2XHA== 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=m6UXy22CoKz9+8Jp0L1B1lPP1hKjha3hRN1CDWu8c4o=; b=P3IZRnsKMkKfzxkVylvlm8Bb1KSd6nDEMi4OXJxrlV1N4TltY6lYjknjGqkn7pM+kj pEhEGYUNVWcdEa2Wk7wYc0wQZkroPwWOWNseH4Pti7Vq0WsZLM8m9Sh7Ng4IprmjU6/6 uu5A0ekFfyf0BQcqSJYeqzD91+RBxGiklxw38loE58/W+MugSV/EvPIBF0Q3+TwVTj7b ILMu4rUk99I2c6uxdRSlCCxR+FI5Wn3M4ZUgfxSpRl4MaZey82HO+ZDCHFAkggxUrpV4 l2d4bw/dejqeiwwVZkrjpKmYBuV8pcI8D1Ezt4phr0FhFgda9CUJ4APHjZHrBhDzfepE ih4A== X-Gm-Message-State: ALoCoQmHetDH0P6rE7GwTo8PpggDo7wKI1TCM1cYcKM2n8FFYNWcV41E0j4hz+/O6M6Zo0A/sECS X-Received: by 10.182.215.226 with SMTP id ol2mr26564805obc.11.1444691016103; Mon, 12 Oct 2015 16:03:36 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.130.139 with SMTP id m11ls1689589ioi.82.gmail; Mon, 12 Oct 2015 16:03:34 -0700 (PDT) X-Received: by 10.50.66.144 with SMTP id f16mr170900igt.14.1444691014891; Mon, 12 Oct 2015 16:03:34 -0700 (PDT) In-Reply-To: <561C3875.2050701@gmail.com> X-Original-Sender: GorNishanov@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:21627 Archived-At: ------=_Part_6330_1593848067.1444691014146 Content-Type: multipart/alternative; boundary="----=_Part_6331_884847826.1444691014146" ------=_Part_6331_884847826.1444691014146 Content-Type: text/plain; charset=UTF-8 On Monday, October 12, 2015 at 3:47:24 PM UTC-7, Evgeny Panasyuk wrote: > > 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: 1) How much code end-user have to write 2) How much library support required 3) What is an abstraction penalty, how many instructions need to get executed to get from, say, await Read(buf, len) to an low-level API/hardware, say WSARecv My statement is that P0057 is as good or better on all 3 criteria than any other proposal I've seen. If you want to accept the challenge, write up an equivalent to TcpReader described in one of these two presentations: Compared to hand-crafted state machines using callbacks, P0057 has negative overhead. See: https://github.com/CppCon/CppCon2015/blob/master/Presentations/C%2B%2B%20Coroutines/C%2B%2B%20Coroutines%20-%20Gor%20Nishanov%20-%20CppCon%202015.pdf or http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf -- --- 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_6331_884847826.1444691014146 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Monday, October 12, 2015 at 3:47:24 PM UTC-7, E= vgeny Panasyuk wrote:
My main c= oncern about P0057R0 is type-erasure - it is far from being=20
zero-overhead.

I have had an outstanding challenge fo= r 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:

1) How much code end-user have= to write
2) How much library support required
3) What = is an abstraction penalty, how many instructions need to get executed to ge= t from, say, await Read(buf, len) to an low-level API/hardware, say WSARecv=

My statement is that P0057 is as good or better o= n all 3 criteria than any other proposal I've seen. If you want to acce= pt the challenge, write up an equivalent to TcpReader described in one of t= hese two presentations:

Compared to hand-crafted s= tate machines using callbacks, P0057 has negative overhead. See:=C2=A0https= ://github.com/CppCon/CppCon2015/blob/master/Presentations/C%2B%2B%20Corouti= nes/C%2B%2B%20Coroutines%20-%20Gor%20Nishanov%20-%20CppCon%202015.pdf
=

or

http://open-std.org/JTC1/SC= 22/WG21/docs/papers/2014/n4287.pdf

--

---
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_6331_884847826.1444691014146-- ------=_Part_6330_1593848067.1444691014146-- .