220 14241 <8ebf3c43-0d6d-4bcf-b647-00209eda4d71@isocpp.org> article Path: news.gmane.org!not-for-mail From: german.gomez@personifyinc.com 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: Sun, 26 Oct 2014 23:07:05 -0700 (PDT) Lines: 678 Approved: news@gmane.org Message-ID: <8ebf3c43-0d6d-4bcf-b647-00209eda4d71@isocpp.org> 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_57_939632687.1414390025589" X-Trace: ger.gmane.org 1414390036 20435 80.91.229.3 (27 Oct 2014 06:07:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2014 06:07:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDWYPV7DUIFRBC6CW6RAKGQEDZOZUXA@isocpp.org Mon Oct 27 07:07:10 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XidSP-0001ox-1S for gclcip-std-proposals@m.gmane.org; Mon, 27 Oct 2014 07:07:09 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id m8sf8120888obr.5 for ; Sun, 26 Oct 2014 23:07:07 -0700 (PDT) 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=2XVxfi3KlngSgr/aEORrxbBE0G28M/OsuoaNvsxss9E=; b=QDDxx2CMxB8QOjs9k3NsXIrxxBsY6SNC2vTDAdevBnq+xx6IbefwXpCtugMbZiwcgM H3Dk6CB2QDv28+I5+MLZ7mjBk9cYLvJhlyAZzIL77WwwwNAikJcuKIXHPfJI+ev5iVJY EnkcK7zdwZ/Fv64BP0MDB9Ot/oxOfne8o9XKBZhodLjj8+GXsNi77ngNgLf3ng3D5py8 eIXISmGgh42bmQW/QVbJQVpJLMP1DSvQOhLQe8Vv7FkPmJZK7m27I5XfPj7B8gmTsoXB zBQ60cg+77gGNanmXcbmAyjkybnPCpGH3sKGQo8H4psjC9WZDGpDm531w3S6JcMA0Ew8 jWTg== X-Gm-Message-State: ALoCoQmYBvYDgz+3GqvXDCN6dRhx5TlKDb7tYg8hf4ABatf1PhD177RAbK6TmxV9tOx6SFm7StpA X-Received: by 10.182.27.244 with SMTP id w20mr12417539obg.46.1414390027772; Sun, 26 Oct 2014 23:07:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.166.195 with SMTP id p186ls1250602ioe.96.gmail; Sun, 26 Oct 2014 23:07:07 -0700 (PDT) X-Received: by 10.50.138.40 with SMTP id qn8mr195335igb.2.1414390027060; Sun, 26 Oct 2014 23:07:07 -0700 (PDT) In-Reply-To: <44e2f2f7-aff5-4cfa-86ff-aefad5b971ab@isocpp.org> X-Original-Sender: german.gomez@personifyinc.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:14241 Archived-At: ------=_Part_57_939632687.1414390025589 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, October 25, 2014 10:43:14 AM UTC+7, Gor Nishanov wrote: > > 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. > > Hello Gor, I think I understand things a bit better than before, but not fully yet :D.= =20 Coming back to the generator example, in the slides I see generator=20 (slide 50 and following). So the process I see in the slides is that there is a heap allocated=20 control block for the coroutine. Comparing: n4134 generator fib(int n) { ...} vs n4244: auto fib =3D [](int n) resumable { ... } n4134: - Need heap alloc? - In case I don't want heap alloc, do I need to customize alloc traits and= =20 write more code? + Seems to fit in a bigger framework not only with generators very=20 transparently. n4244: + Just function object sugar, really easy to understand, one of the most=20 appealing points IMHO. + I see obvious that I dont need a heap alloc, it is a function object. + I can reason how to copy/move a coroutine. - When I want to do something like below (networking) things are a bit more= =20 work to write. My conclusion here is that n4244 is more efficient *by default*, because it= =20 is not hiding that fact to me, but correct me if I am wrong.=20 Your proposal seems to be able to write both examples, the generator and the networking example, "uniformly", making them look the same.=20 Example 2 (networking): std::future tcp_reader(int total)=20 { char buf[64 * 1024]; ptrdiff_t result =3D 0; auto conn =3D await Tcp::Connect("127.0.0.1", 1337); =20 do=20 { auto bytesRead =3D await conn.Read(buf, sizeof(buf)); total -=3D bytesRead; result +=3D std::count(buf, buf + bytesRead, 'c'); }=20 while (total > 0); return result; } Slide 9: where does the "coroutine frame" live? I cannot convince myself=20 this does not need runtime support of some kind, because that state must be managed by someone.=20 Is this coroutine frame what can be controlled with the allocator (which=20 would be good). A rough n4244 (pseudo boost.asio code omitting error_code) would be like=20 the following: [](int total) resumable { promise p; future res =3D p.get_future(); char buf[64 * 1024]; ptrdiff_t result =3D 0; =20 auto conn =3D yield async_connect(..., *[]this); do { auto bytes_read =3D yield conn.async_read(...., *[]this); ... } while (total < 0); p.set_value(total); return res; } } I admit in n4134 it is a bit easier to write, but, if I am not wrong, not= =20 without its costs. n4134: + Easier to write. + Customizable to more than futures: good, but read below. +/- At the same time, it is hiding me the promise parts of things in that= =20 piece of code. This is a double edged sword because it is convenient but makes reasoning= =20 about what happens harder, and possible defficiencies in performance hidden. - Non/local state "somewhere". Where? n4244: - Harder to write. Though, I do know where all things are: inside the=20 object, because all the state is kept around. + Easy to reason about copy/move. + I dont need even to think of customizations, I could return anything:=20 just put it in the lambda body, it is gonna be saved in the object, locally. This eliminates the need for traits, it is just= =20 a function object! + Local state is inside the object. Biggest concerns from n4134:=20 =20 - heap allocations by default? Need customization point only for this?=20 Wouldn't be better to avoid heap in the first place? Is it=20 possible/feasible? - copy/move a coroutine: I am not sure how it works, not all the state is= =20 local. Easier for me to reason about n4244 in this sense. P.S.: Feel free to criticize the most you can :D Sorry if there are some=20 assumptions/mistakes that don't hold true at some point. This is my feedback as I understand both proposals, but I can never=20 understand them as deeply as the writers of both. Regards, Germ=C3=A1n Diago G=C3=B3mez --=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_57_939632687.1414390025589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, October 25, 2014 10:43:14 AM UTC+7, G= or Nishanov wrote:
Hi Germ=C3=A1n:

You mentioned in a youtu= be comment that you are concerned about efficiency of N4134 as compared to = that of N4244. I am wondering if you have a particular example in mind= .. I am very interested in learning what do you think are the weak= points of N4134 as compared to N4134.


Hello Gor,

I think I unders= tand things a bit better than before, but not fully yet :D. 
Coming back to the generator example, in the slides I see generator<int= > (slide 50 and following).

So the process I se= e in the slides is that there is a heap allocated control block for the cor= outine.

Comparing:

n4134 = generator<int> fib(int n) { ...}

vs

n4244: auto fib =3D [](int n) resumable { ... }
=
n4134:

- Need heap alloc?
- In case I don't want heap alloc, do I need to customize alloc traits and= write more code?
+ Seems to fit in a bigger framework not only w= ith generators very transparently.

n4244:

+ Just function object sugar, really easy to understand, o= ne of the most appealing points IMHO.
+ I see obvious that I dont= need a heap alloc, it is a function object.
+ I can reason how t= o copy/move a coroutine.
- When I want to do something like below= (networking) things are a bit more work to write.

My conclusion here is that n4244 is more efficient *by default*, because i= t is not hiding that fact to me,
but correct me if I am wrong.&nb= sp;

Your proposal seems to be able to write bo= th examples,
the generator and the networking example, "unifo= rmly",
making them look the same. 

= Example 2 (networking):

std::= future<ptrdiff_t> tcp_reader(int total)

{

    char buf[64 * 1024];

    ptrdiff_t result =3D 0;

    auto conn =3D await Tcp::Connect("127.0.0.1", 1337);   =

    do

    {

        auto bytesRead =3D await conn.Read(buf, sizeof(buf));

        total -=3D byte= sRead;

 &nb= sp;      result +=3D std::count(buf, buf + bytesRead, 'c= ');

    }

    while (total > 0);

 &nb= sp;  return result;

}


Slide 9: where does the "c= oroutine frame" live? I cannot convince myself this does not need runtime s= upport of some kind,

because that state must be managed by someone.&nb= sp;

Is this coroutine frame what can be controlled with the allocator = (which would be good).


A rough n4244 (pseudo boost.asio code= omitting error_code) would be like the following:


[](int total) resumable

{

                promis= e<ptrdiff_t> p;

=                 future<ptrdiff_t= > res =3D p.get_future();

                char buf[64 = * 1024];

   =             ptrdiff_t result =3D 0;  

      &n= bsp;         auto conn =3D yield async_connect(..., *[]= this);

    &= nbsp;           do {

              &n= bsp;   auto bytes_read =3D yield conn.async_read(...., *[]this);

       =           ...

                }= while (total < 0);


    &n= bsp;           p.set_value(total);

          &n= bsp;     return res;

         }

}


I admit in n4134 it is a bi= t easier to write, but, if I am not wrong, not without its costs.

n4134:

+ Easier to write.
+ Customizable to more than futures: good, but read below.
=
+/- At the same time, it is hiding me the promise parts of things in t= hat piece of code.
This is a double edged sword because it = is convenient but makes reasoning about what
happens harder, and = possible defficiencies in performance hidden.
- Non/local state "= somewhere". Where?

n4244:

- Harder to write. Though, I do know where all things are: inside the obje= ct, because all the state is kept around.
+ Easy to reason about = copy/move.
+ I dont need even to think of customizations, I could= return anything: just put it in the lambda body, it is gonna be saved
   in the object, locally. This eliminates the need for tra= its, it is just a function object!
+ Local state is inside the ob= ject.

Biggest concerns from n4134: 
 
- heap allocations by default? Need customization point o= nly for this? Wouldn't be better to avoid heap in the first place? Is it po= ssible/feasible?
- copy/move a coroutine: I am not sure how it wo= rks, not all the state is local. Easier for me to reason about n4244 in thi= s sense.

P.S.: Feel free to criticize the most you= can :D Sorry if there are some assumptions/mistakes that don't hold true a= t some point.
This is my feedback as I understand both proposals,= but I can never understand them as deeply as the writers of both.

Regards,

<= p style=3D"margin-top: 0pt; margin-bottom: 0pt; margin-left: 0in; direction= : ltr; unicode-bidi: embed; word-break: normal;">Germ=C3=A1n Diago G=C3=B3m= ez

--

---
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_57_939632687.1414390025589-- .