220 14206 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Germ=C3=A1n_Diago?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?ISO-8859-1?Q?=5Bstd=2Dproposals=5D_Re=3A_Question_for_Germ=E1n_Diago=3A_N413?= =?ISO-8859-1?Q?4_and_N4244?= Date: Sat, 25 Oct 2014 02:47:22 -0700 (PDT) Lines: 167 Approved: news@gmane.org Message-ID: References: <44e2f2f7-aff5-4cfa-86ff-aefad5b971ab@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_648_1420756984.1414230442448" X-Trace: ger.gmane.org 1414230452 20650 80.91.229.3 (25 Oct 2014 09:47:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 09:47:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDC2VXM4YYDRBK7DVWRAKGQEXFTOYYI@isocpp.org Sat Oct 25 11:47:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XhxwT-0000Da-Vi for gclcip-std-proposals@m.gmane.org; Sat, 25 Oct 2014 11:47:26 +0200 Original-Received: by mail-pa0-f69.google.com with SMTP id eu11sf641833pac.0 for ; Sat, 25 Oct 2014 02:47:24 -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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=96szGxeK9vYX1jvCM0czp154MaJWuzDi7jnbg7iq/mc=; b=NqbarpD08ePqRfB6BWEGWtY/haHzKfiTch4sLCWcJ5/h3BwaNiFhkrVKGfhoRiJtW7 PSIfcv1thLEXarhJYAXVkwpGpqd+FN7s+YJJ82jr1AJmcy4/F3xO6FKdT1UYVoD9AuhR 3VgHBPmrnqyz/5vwCu+djtsO7tDIf7YGXZ6xpNH4SZ8mRz5dkzr0yLFtixNu1IYmoSoP LX1m9P1XycmH/JCSVeo7txTHOQTHs4cKz4KYCjO5pmF8C1Gb7FXbjoeuLGypEHFBzklp 6nQ+ff6HBc6NC4MFCo2zMubfpz1HG0FSSZVaMwNta8O9101rxBusa9Fq6XNfjHBf7B7U 38tQ== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=96szGxeK9vYX1jvCM0czp154MaJWuzDi7jnbg7iq/mc=; b=h4Wm1084LQsZXo7VFD1SBuC6ZdhonJWxKV65zxYmemAaCudhjv6P/zhQA00kUnoiVA jbu2YTkT1OCLYyoXd5flYTCgruCO9j1XzrBElGBpj3d9vRfnuGj+X2vWTEanJkKPDxfW WvJHbCTUMbuVZ0A28XI8tDNLRvKswafYGaVkq6TZ0s9psiTtbzBaQ7E1mnIwhUJ2+lUo xh49N+6SxsDVh58AiuWaTCfyI/txpKOMKGu6xeXe7dT9IJ9+Fdy/XjUKcEr8qyxdob9I 8mbBmJTyfM4bt6IWJeHFBvP9WzgmzdEHe7lDaJEupwLdkhMeYWnPV8zRh+w0hqDfNZIT uiwQ== X-Gm-Message-State: ALoCoQlpRWxnoHgO+9FZjIIYuTCF3/6bUSd6Gq9hHXBAWPnv60wkbtsI+GEizUml6He9SKu29wY9 X-Received: by 10.66.219.135 with SMTP id po7mr11543936pac.9.1414230444513; Sat, 25 Oct 2014 02:47:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.12.66 with SMTP id w63ls46163ioi.83.gmail; Sat, 25 Oct 2014 02:47:23 -0700 (PDT) X-Received: by 10.50.124.8 with SMTP id me8mr108918igb.3.1414230443773; Sat, 25 Oct 2014 02:47:23 -0700 (PDT) In-Reply-To: <44e2f2f7-aff5-4cfa-86ff-aefad5b971ab@isocpp.org> X-Original-Sender: germandiago@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:14206 Archived-At: ------=_Part_648_1420756984.1414230442448 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Disclaimer: I don't claim to fully understand both proposals yet. Hello Gor Nishanov, I was taking a look at both papers again. I think, as you said in your=20 comment in youtube, that they are similar in performance. However, without being an expert on the matter, I find two key differences= =20 in both: 1. In my opinion, N4244 seems easier to reason about in the sense that I do= =20 know what is happening under the hood, because everything is modeled after a lambda. I do understand this model and I am= =20 confident is as lightweight as it can be. 2. In N4244 it mentions: "17.1 Unspecified memory representation". I am concerned about this and how normal stateless functions are handled=20 when await/yield is found:=20 do we need runtime support? AFAIK, functions are stateless, so this info must be somewhere.=20 A resumable lambda from N4244 is stateful, I know what happens under the=20 hood: it is just a capture list. For example, from N4134: auto squares =3D [&]{ for(x:S) yield x*x;} ; With n4244 in my hands, I can completely figure out what is happening=20 there: it is just a function object, I can easily see how lightweight this gets, since it is equivalent to a hand-coded=20 function object + sizeof(x + S ref) + sizeof(resumable_point), if I am not wrong. How is this translated in your proposal, about object size, etc? Maybe it= =20 is the same, my problem is that it is more difficult for me to follow and understand :) So I apologize if they are=20 equivalent. Another example: template async_generator> Timestamp(async_read_stream S)=20 { for await(v: S) yield {v, system_clock::now()}; } I can't figure out how this is implemented. Sorry if I don't fully=20 understand things yet. My point here is also, that I find resumable lambdas very easy to reason=20 about, I could do it in a few minutes. The problem I find with the design in your paper, which I also like a lot,= =20 is that I find it more difficult to reason about what is happening under the hood. Regards, Germ=C3=A1n Diago G=C3=B3mez El s=C3=A1bado, 25 de octubre de 2014 10:43:14 UTC+7, Gor Nishanov escribi= =C3=B3: > > Hi Germ=C3=A1n: > > You mentioned in a youtube comment that you are concerned about efficienc= y=20 > of N4134 as compared to that of N4244. I am wondering if you have a=20 > particular example in mind. I am very interested in learning what do you= =20 > think are the weak points of N4134 as compared to N4134. > > Thank you, > Gor > > --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_648_1420756984.1414230442448 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Disclaimer: I don't claim to fully understand both proposa= ls yet.

Hello Gor Nishanov,

I w= as taking a look at both papers again. I think, as you said in your comment= in youtube, that they are similar in performance.

However, without being an expert on the matter, I find two key differences= in both:

1. In my opinion, N4244 seems easier to = reason about in the sense that I do know what is happening under the hood, = because
everything is modeled after a lambda. I do understand thi= s model and I am confident is as lightweight as it can be.

2. In N4244 it mentions: "17.1 Unspecified memory representation".=
I am concerned about this and how normal stateless functions are= handled when await/yield is found: 

do we ne= ed runtime support?

AFAIK, functions are stateless= , so this info must be somewhere. 
A resumable lambda from N= 4244 is stateful, I know what happens under the hood: it is just a capture = list.

For example, from N4134:

auto squares =3D [&]{ for(x:S) yield x*x;} ;

=
With n4244 in my hands, I can completely figure out what is happe= ning there: it is just a function object, I can easily
see how li= ghtweight this gets, since it is equivalent to a hand-coded function object= + sizeof(x + S ref) + sizeof(resumable_point),
if I am not wrong= ..

How is this translated in your proposal, about o= bject size, etc? Maybe it is the same, my problem is that it is more
<= div>difficult for me to follow and understand :) So I apologize if they are= equivalent.

Another example:

=
template<class T>
async_generator<pair<T, s= ystem_clock::time_point>>
Timestamp(async_read_stream<T&= gt; S) 
{
    for await(v: S) yield {v, = system_clock::now()};
}

I can't fi= gure out how this is implemented. Sorry if I don't fully understand things = yet.

My point here is also, that I find resumable = lambdas very easy to reason about, I could do it in a few minutes.
The problem I find with the design in your paper, which I also like a lot= , is that I find it more difficult to reason about
what is happen= ing under the hood.

Regards,
Germ=C3=A1n= Diago G=C3=B3mez


El s=C3=A1bado, 2= 5 de octubre de 2014 10:43:14 UTC+7, Gor Nishanov escribi=C3=B3:
Hi Germ=C3=A1n:

You mentioned in a youtube comment that you are conc= erned about efficiency of N4134 as compared to that of N4244. I am wonderin= g if you have a particular example in mind. I am very interested in le= arning what do you think are the weak points of N4134 as compared= to N4134.

Thank you,
Gor

<= /div>

--

---
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_648_1420756984.1414230442448-- .