220 4864 article Path: news.gmane.org!not-for-mail From: Jeffrey Yasskin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Tue, 4 Jun 2013 15:54:45 -0700 Lines: 151 Approved: news@gmane.org Message-ID: References: <4551abbc-43aa-4520-a91a-f8eb25a90588@isocpp.org> <2c8e6079-9c87-425a-93e2-39251df57cd8@isocpp.org> <9f1cace3-0503-4a3c-a8ce-d7546564b3ef@isocpp.org> <1c991e6e-6bc3-4822-9ffd-7f2508e63974@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1370386510 5800 80.91.229.3 (4 Jun 2013 22:55:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 22:55:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBSXAXGGQKGQE4OKE4NY@isocpp.org Wed Jun 05 00:55:11 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f72.google.com ([209.85.212.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uk08B-00023K-UK for gclcip-std-proposals@m.gmane.org; Wed, 05 Jun 2013 00:55:08 +0200 Original-Received: by mail-vb0-f72.google.com with SMTP id q12sf462976vbe.3 for ; Tue, 04 Jun 2013 15:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=ciLV0F8fqosucrrIVdHs566GWgT+J6G/mftnXLijGc0=; b=Sd9pUVu/a0q6Z4osAD1y+/meovZKi5yxMhF/CcAo2bLKMX8W48dMFRY5P+fQ27Svlk xj2hwz2g4a87t7s+CtN5IKqRbD4xk7sw5RzA7Px4KTrLx+9s7LAEaIm4z1Y0ugjjEgnO 9HTmA1LbQJbAlwbElS6NodHa7xau7sUbavuVx8Dm8iEELFf+zlqcJPzQMq1xcnWt4nJZ CrYYY3RvNzMmbp9DIDFCEiqQ/UDqioUYEpHuZbD9ZWBWWI8r6sHSXekc7T4WaV7UWoTc 3+VIvN5xVif8CIBfbygKp/A10b+oZEI8q5SRq//jzD1J5AnKPnOexQXvia2p/5jfpl6n k X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-gm-message-state:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; bh=ciLV0F8fqosucrrIVdHs566GWgT+J6G/mftnXLijGc0=; b=fSElgCGG+1XMKK3JARYx78lZncp6TZdupSu3VYHQ6aPazC4Z8TTMbWIbXzAJbtIzvR HafkoqiiUdX0IL9vcJFJE3h99+xCMYB0LXrUktwZ/ZlFVtsxVDZ7Z5shNM/poqJkkBnB kFjZjqLK1E/xyQfKAGxJbHIbNTQTe62M80vD1/bJf0rijtOWQHZkmUG5dgGYIu9VwLFy r5hStZcRXIGlwtDln1+OR0zuFyoSem+YzPytkLSWhfRbKAZZOSY0/rKr2zAf5P2r1/P0 RwCCFX70pQVkei9mnMYuE/uBkOWCpoytWi5nh7trZNsYen1aJfi X-Received: by 10.236.126.14 with SMTP id a14mr16090387yhi.20.1370386507054; Tue, 04 Jun 2013 15:55:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.98.138 with SMTP id ei10ls518640qeb.79.gmail; Tue, 04 Jun 2013 15:55:05 -0700 (PDT) X-Received: by 10.224.184.78 with SMTP id cj14mr25365193qab.69.1370386505792; Tue, 04 Jun 2013 15:55:05 -0700 (PDT) Original-Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [2607:f8b0:400d:c01::232]) by mx.google.com with ESMTPS id p1si4739573qcj.61.2013.06.04.15.55.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Jun 2013 15:55:05 -0700 (PDT) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c01::232 as permitted sender) client-ip=2607:f8b0:400d:c01::232; Original-Received: by mail-qc0-f178.google.com with SMTP id l11so521506qcy.37 for ; Tue, 04 Jun 2013 15:55:05 -0700 (PDT) X-Received: by 10.224.79.138 with SMTP id p10mr25470421qak.13.1370386505542; Tue, 04 Jun 2013 15:55:05 -0700 (PDT) Original-Received: by 10.229.78.22 with HTTP; Tue, 4 Jun 2013 15:54:45 -0700 (PDT) In-Reply-To: X-Gm-Message-State: ALoCoQnxlpJh7H07/fvNqj5DayO4HdXlKoTXD5TiuW2wsdKSIFOZFPYx4Q2Zn+HrkRE6cqo5EDV71gZo6y1zvchf5FJaD1U72kho/ZZx87660TIWR3f/WyFYLOcKDUyWVo2WwkJgv74H0EO5lrmPcMg3qVlT3J3+EvQ3R5164IhUxgKZa2cIkjkeyTnoLCkqOmeXq9VCYOED X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c01::232 as permitted sender) smtp.mail=jyasskin@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=none) d=google.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:4864 Archived-At: On Tue, Jun 4, 2013 at 3:45 PM, j.carlson wrote: > > > On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida > (felipe.m.almeida@gmail.com) wrote: > > On Tue, Jun 4, 2013 at 11:27 AM, wrote: >> >> >> On Monday, June 3, 2013 6:39:35 PM UTC-4, Nicol Bolas wrote: >>> >>> On Monday, June 3, 2013 1:24:54 PM UTC-7, carrieran...@yahoo.co.uk wrot= e: > > > [snip] > >>>> >>>> re Lightweight: The smallest array_ref could be the same size as a >>>> sequence. Because array_ref's members are not const, it could result i= n >>>> larger and slower code. >>> >>> >>> ... how? They'll just be a pair of pointers or a pointer+size either wa= y. >> >> >> So you have checked my math. What exactly is your question? > > > The question seems to be "how [would array_ref's members not const be lar= ger > and slower]?". Or to put a better way: how would your sequence be smaller= or > faster than an array_ref. I wonder myself the same question. > > [snip] > > Regards, > -- > Felipe Magno de Almeida > > Ok, to quickly summarize the "Lightweight" conversation inline: > > > Me: (initial float) > > Jeffrey: So your proposed class is not assignable? That's likely to be a > problem. > > Me: =85They are very short lived and lightweight to construct and copy=85 > > Nicol: And LLVM and Google have gotten by with types that are equally > lightweight and shortlived, yet theirs are assignable and adjustable in > size. Why should we use yours instead of theirs (ie: array_ref)? > > Me: The smallest array_ref could be the same size as a sequence. Because > array_ref's members are not const, it could result in larger and slower > code. > > Nicol: how? They'll just be a pair of pointers or a pointer+size either w= ay. > > > So my initial statement that sequences are lightweight was with no > comparison to array_ref. I then concurred that the object size of sequenc= es > and array_refs should be identical after a comparison was made to array_r= ef. > The reason I hinted they may not *ultimately* be equal in size is that th= ere > are open considerations regarding array_ref which could affect layout (bu= t > likely would not affect size). > > > The difference I noted when comparing sequence vs array_ref with relation= to > being "Lightweight" is that it can result in a larger and slower binary (= but > the big benefit over array_ref is that mutable elements are supported). T= his > difference I mentioned isn't going to a revolutionary difference, merely = a > measurable difference in some scenarios. I'm also assuming you all figure > this won't result in a great difference in speed (that was never my claim > when making the comparison). > > > The differences I have touched on in this discussion so far are: > > - array_ref's size() may change > > - array_ref's pointer may change > > - For these reasons and because of the required additional mutators and > scaffolding methods, the proposed array_ref has a higher overall complexi= ty > than sequences. > > > Without spending hours creating tests, comparing generated assembly, and > profiling using multiple compilers and platforms - these complexity > increases could result in: > > - more exported symbols > > - larger class bodies > > - greater build and link times > > - more reads and writes necessary. include cases where execution is out o= f > the optimizer's visibility. > > - more instructions > > - more branching > > - more variables for an optimizer to track > > - reduced locality. sequences generally maintain very close locality. > > - and consequently less likely to be a good optimization or inline candid= ate > > > I suspect there won't be additional overhead in many scenarios, particula= rly > where locality is minimized. Yeah, you might see a performance difference for non-const array_ref<>s where the compiler can't assume they don't change. If users see that, they can create const array_ref<>s instead. Is there a difference between const array_ref<>s and sequence<>s? --=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/?hl=3Den. .