220 4863 article Path: news.gmane.org!not-for-mail From: "j.carlson" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal: std::sequence Date: Tue, 4 Jun 2013 18:45:31 -0400 Lines: 249 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: multipart/alternative; boundary="51ae6e0b_3d1b58ba_8d5" X-Trace: ger.gmane.org 1370385937 32243 80.91.229.3 (4 Jun 2013 22:45:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Jun 2013 22:45:37 +0000 (UTC) To: Original-X-From: std-proposals+bncBDQ2R4E5RIKBBDW4XGGQKGQENR4LYAI@isocpp.org Wed Jun 05 00:45:36 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yh0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ujzyx-0001gx-N4 for gclcip-std-proposals@m.gmane.org; Wed, 05 Jun 2013 00:45:35 +0200 Original-Received: by mail-yh0-f72.google.com with SMTP id f73sf953692yha.7 for ; Tue, 04 Jun 2013 15:45:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-beenthere:x-yahoo-newman-id:x-yahoo-newman-property:x-ymail-osg :x-yahoo-smtp:x-rocket-received:date:from:to:cc:message-id :in-reply-to:references:subject:x-mailer:mime-version :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; bh=+lR88NSRH501PVO8AUBlX/oTim/BgOBSIl3kMoZOPHg=; b=jQgokAdrVcODSeRe70mZtaPf+0tbvic0qtuImr85C9neoTU5bA308VBwtkO0zvr+LN nRGK7oCeVV3MmUsSRCT9E1CrCm/slQ0PlMlwF5HKXapmOfLlbmLU7F164JgR3nzPaHEX DJlWfTKIBz+tsmJfgldCbRj6IN9bkXGwdFZKlsetiDC4SQz4mNDjqE5iUisNwQalFaic SogNfRxCySSjN68QeizW80ssypQptlAHDqMm9HgSRdUvQh8/pAWZngjgn7IotGbZCIR3 X-Received: by 10.236.46.50 with SMTP id q38mr16137314yhb.44.1370385934858; Tue, 04 Jun 2013 15:45:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.98.99 with SMTP id eh3ls578777qeb.15.gmail; Tue, 04 Jun 2013 15:45:33 -0700 (PDT) X-Received: by 10.236.75.2 with SMTP id y2mr22727079yhd.166.1370385933192; Tue, 04 Jun 2013 15:45:33 -0700 (PDT) Original-Received: from nm29-vm4.bullet.mail.ne1.yahoo.com (nm29-vm4.bullet.mail.ne1.yahoo.com. [98.138.91.189]) by mx.google.com with ESMTPS id r23si33132018yhl.127.2013.06.04.15.45.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Jun 2013 15:45:33 -0700 (PDT) Received-SPF: neutral (google.com: 98.138.91.189 is neither permitted nor denied by best guess record for domain of carrierandoperator@yahoo.co.uk) client-ip=98.138.91.189; Original-Received: from [98.138.90.57] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:45:32 -0000 Original-Received: from [98.138.226.129] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:45:32 -0000 Original-Received: from [127.0.0.1] by smtp216.mail.ne1.yahoo.com with NNFMP; 04 Jun 2013 22:45:32 -0000 X-Yahoo-Newman-Id: 326991.28417.bm@smtp216.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EsnrWSEVM1kxAeMVU5.kWGBxh8XnemcF6jotoVrPjbNMKj9 YsrkOFRjxnWWsQD2GIia7jMoz5wx_LIquaXV1AZiCYUyNZZZT.74vs3e0zO9 ICzUqpWG3z.1R7rNGlqxbQQ.vYz4R2toUfGaPOyQGucLgxj73_ijDl9jef8S kMAySPS9.zmRGrHQjPc257Mh8KzZofatPKsICm1uRRoNK.RAo9SpF3TxE3Kx IwAYDU8PGcdI4VbQbO4USYha33F8djPOyob6wAPpKiK0gQ0sY1oHXa2N56hx y.4oPs0OXYIkT5y5778ZHslEKibt6Yuc9FaY_VN_7RQBATlLEi57KTv9j57w sX1WSopTffLJfX4WSJkWP2bdY361l9XCYf3gbZGHmEqwBDLg10UXTktBzubc 8xRff3Hx94UAdKsFbJhITETOWQd4Zo_WF2aTS3n0oDMpE.lCBH4w0gq32cMG SG0D0DGEVvGnGdjMr5iGCzSkUjT3hDR6KPhnXv6.mPdthc9bDEDmCsQwVAiG qDdzj X-Yahoo-SMTP: zek3l4KswBAfmLXs2UMoTR8fUk1Gk5ZuUJctqK8zhg-- X-Rocket-Received: from server-2.private (carrierandoperator@24.63.251.162 with ) by smtp216.mail.ne1.yahoo.com with SMTP; 04 Jun 2013 15:45:32 -0700 PDT In-Reply-To: X-Mailer: Airmail (175) X-Original-Sender: carrierandoperator@yahoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 98.138.91.189 is neither permitted nor denied by best guess record for domain of carrierandoperator@yahoo.co.uk) smtp.mail=carrierandoperator@yahoo.co.uk; dkim=pass header.i=@yahoo.co.uk 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:4863 Archived-At: --51ae6e0b_3d1b58ba_8d5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida (felipe.m.almeida@gm= ail.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 wrote: [snip] =A0 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 in larger and = slower code. .... how? They'll just be a pair of pointers or a pointer+size either way. 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 large= r 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, -- =20 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 p= roblem. 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 ligh= tweight and shortlived, yet theirs are assignable and adjustable in size. W= hy should we use yours instead of theirs (ie: array_ref)? Me: The smallest array_ref could be the same size as a sequence. Because a= rray_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 wa= y. So my initial statement that sequences are lightweight was with no comparis= on to array_ref. I then concurred that the object size of sequences and arr= ay_refs should be identical after a comparison was made to array_ref. The r= eason I hinted they may not *ultimately* be equal in size is that there are= open considerations regarding array_ref which could affect layout (but lik= ely would not affect size). The difference I noted when comparing sequence vs array_ref with relation t= o 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).= This difference I mentioned isn't going to a revolutionary difference, mer= ely a measurable difference in some scenarios. I'm also assuming you all fi= gure this won't result in a great difference in speed (that was never my cl= aim 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 sc= affolding methods, the proposed array_ref has a higher overall complexity t= han sequences. Without spending hours creating tests, comparing generated assembly, and pr= ofiling 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 of= 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 candida= te I suspect there won't be additional overhead in many scenarios, particularl= y where locality is minimized. -- j.carlson --=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. --51ae6e0b_3d1b58ba_8d5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


=

On June 4, 2013 at 1:38:07 PM, Felipe Magno de Almeida (felipe.m.alme= ida@gmail.com) wrote:

On Tue, Jun 4, 2013 at 11:27 AM, <carrierandope= rator@yahoo.co.uk> = ;wrote:

On Mo= nday, 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 wrote:

[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 res= ult in larger and slower code.

... how? They'll = just be a pair of pointers or a pointer+size either way.

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 larger and slower]?". Or to= put a better way: how would your sequence be smaller or faster than an arr= ay_ref. I wonder myself the same question.

[sn= ip]

Regards,
-- 
Felipe Magno de Almeida

Ok, to quickly summarize the "Lightweight" = conversation inline:

=

Me: (initial float)

Jeffrey: So your proposed class is no= t assignable? That's likely to be a problem.

Me: =85They are very short lived and lightweight to construct= and copy=85

Nicol: And LLVM an= d Google have gotten by with types that are equally lightweight and shortli= ved, yet theirs are assignable and adjustable in size. Why should we use yo= urs instead of theirs (ie: array_ref)?

Me: The smallest array_ref could be the same size as a sequence. B= ecause array_ref's members are not const, it could result in larger and slo= wer code.

Nicol: how? They'll j= ust be a pair of pointers or a pointer+size either way.


So my initial statement that sequences are lightweight w= as with no comparison to array_ref. I then concurred that the object size o= f sequences and array_refs should be identical after a comparison was made = to array_ref. The reason I hinted they may not *ultimately* be equal in siz= e is that there are open considerations regarding array_ref which could aff= ect layout (but 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 slowe= r binary (but the big benefit over array_ref is that mutable elements are s= upported). This difference I mentioned isn't going to a revolutionary diffe= rence, 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 n= ever my claim when making the comparison).


The differences I have touched on in this discussion so far are:

<= p id=3D"bloop_customfont" style=3D"margin: 0px; "> - 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 a= rray_ref has a higher overall complexity than sequences.


Without spending hours creating tests, comparing genera= ted assembly, and profiling using multiple compilers and platforms - these = complexity increases could result in:

- more exported symbols

- larger class bodies

- great= er build and link times

- more = reads and writes necessary. include cases where execution is out of the opt= imizer's visibility.

= - more ins= tructions

- more branching

<= p id=3D"bloop_customfont" style=3D"margin: 0px; "> - more variables for an optimizer t= o track

- reduced locality. s= equences generally maintain very close locality.

- and consequently less likely to be a good optimization = or inline candidate

<= br>

I suspect there w= on't be additional overhead in many scenarios, particularly where locality = is minimized.


--
j.carlson

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
--51ae6e0b_3d1b58ba_8d5-- .