220 34930 article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on more methods towards containers in the future Date: Sat, 14 Oct 2017 16:50:41 -0700 (PDT) Lines: 187 Approved: news@gmane.org Message-ID: References: <973f04da-1354-44f4-9d1f-23f04596b8dc@isocpp.org> <20171014085305.GA24512@fukushima.lysator.liu.se> <79c51b8c-6cc2-4872-8651-9dae513d1e21@isocpp.org> <1550fc17-cf97-438d-9e7a-862f729adbf5@isocpp.org> <0cc942cf-a217-4175-98b0-b466ac224dc7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2479_1769153568.1508025041751" X-Trace: blaine.gmane.org 1508025070 21964 195.159.176.226 (14 Oct 2017 23:51:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Oct 2017 23:51:10 +0000 (UTC) Cc: euloanty@live.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBUWFRLHQKGQEDFA47JY@isocpp.org Sun Oct 15 01:51:03 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3WCS-0001pJ-MD for gclcip-std-proposals@m.gmane.org; Sun, 15 Oct 2017 01:50:36 +0200 Original-Received: by mail-vk0-f71.google.com with SMTP id 126sf4812162vkj.0 for ; Sat, 14 Oct 2017 16:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=3bXdZsLnosYhFMMM0C7bbmoSUyIaSHheXAdkuPPeng0=; b=p3dlttGAFcSrgCJgReF+eF1b6sABOzYuWUwJerTFt0HesAn8xCv6VmOENj2axszs4h kGaBJVCCBMHLSU5BMpaF9RdX1RldUATV6Oolwlzas1mRs4TbyZxx7V8EdmWS5mSLm1jH VoUnNRTzv7YJCAmcb+VvuZJIsrCzkRZdH76RIR+AHVZFYRbG9D5QSOOtIGf/Y940RiSp 9dPy59rlepGwcPzaOIuhV1VmY6T7gTHJC9Rglt5xZ5Xdb2qqkEV+CwIyA17JEcF1u3V8 FUcDaHI5FYUYHrm8L/f1T+U7rCqfhAqpzZtBPX3owrPsi1PUx2L6qGp7Xfa9Vl1ACDx/ 9QJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=3bXdZsLnosYhFMMM0C7bbmoSUyIaSHheXAdkuPPeng0=; b=uZxD5gUO4WwYwiXFHQabP4I6ZieIoHH6hNK/6Fd7UeMBlcVvb6n8WvhCQzkA642rVm ZDw0FtKY83YX2b4Sa4sGa9cijM20ELvEQcbkeMdufCsBx7yt1UCCI026AmsnKN+Rud7l n1gETChZoBw8VlrQMhBPU9GdFYJ8SYnq2uEE5jKbgteKwvGmuJvhgi0Tuwsd1geUnhEj Ny/2Tr6Pelq0Ea+KrnxiM65eX2I682uUeRxo+KahxtDvwUgIcogYRGldxl8PIebxMluo 7E8gy7JknwMgzhhlqey89lO5vhBw8BVJF2PvazsC8I9wK/XCWwW9l+XH5Kswtt7367/+ WAhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version: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=3bXdZsLnosYhFMMM0C7bbmoSUyIaSHheXAdkuPPeng0=; b=NNY5M3JSlePvwCkeprrRhnKEOr/adXNCC7AilklK1Hie8ckHgQ4m3p75VMd7+xKBrF vXTYiv1n0tCDeJC4bPwqZvh7C5yxKsTSYiaDT+diII0apkcVraARbLO6e3xzo9eDgcRu epBCYLkVG7uWty9kZ0X8z4dZw8/82msSbZLIr+2aJ6UbSecZ+USb/qmJagKS2Hx+CGzZ CYjB3kEZd9f0BpDGhAAtFEvC+Fb3EqqBR6La4wqFMV286Z+ezPhtnHKlN2yXe717XplP 8Qxz3dQSZ+md1WD8eXiFfpomGcF4MQptMGV9xKkyAVKLs2uKgiIIx8YF3waYYGipywGG IFVA== X-Gm-Message-State: AMCzsaVeAny/3tKMsUCFuoIXUfk1a2lTz0lJTLY5TQKG8hTaHLQlMl5R o7kgX+Swdd8JfaYvuGR/pls/bQ== X-Google-Smtp-Source: AOwi7QBg9orTVX0F1891tnN0kcch7jnpzX9KfdmmJIiIEmtr3KbsgumbnNJZKBbpZShuyHVvM60fvQ== X-Received: by 10.176.21.98 with SMTP id p31mr3052932uae.31.1508025043781; Sat, 14 Oct 2017 16:50:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.28.76 with SMTP id o12ls2566510uaj.13.gmail; Sat, 14 Oct 2017 16:50:42 -0700 (PDT) X-Received: by 10.31.211.195 with SMTP id k186mr365850vkg.9.1508025042426; Sat, 14 Oct 2017 16:50:42 -0700 (PDT) In-Reply-To: X-Original-Sender: inkwizytoryankes@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:34930 Archived-At: ------=_Part_2479_1769153568.1508025041751 Content-Type: multipart/alternative; boundary="----=_Part_2480_1181761946.1508025041751" ------=_Part_2480_1181761946.1508025041751 Content-Type: text/plain; charset="UTF-8" On Saturday, October 14, 2017 at 4:02:28 PM UTC+2, ejsvifq mabmip wrote: > > reserve is also 1% > > On Saturday, October 14, 2017 at 9:49:14 AM UTC-4, Marcin Jaczewski wrote: >> >> >> >> On Saturday, October 14, 2017 at 3:27:44 PM UTC+2, ejsvifq mabmip wrote: >>> >>> https://github.com/euloanty/cqwrteur-vector/blob/master/deque.cc >>> >>> Try this code. >>> >>> BTW. deque is "slower" than vector because of this dumb check if >>> >>> On Saturday, October 14, 2017 at 9:24:37 AM UTC-4, eulo...@live.com >>> wrote: >>> >>>> O2 wont eliminate this cost. It is not optimization issue. I always use >>>> -O2 to compile my programs >>>> >>>> On Saturday, October 14, 2017 at 9:18:56 AM UTC-4, Todd Fleming wrote: >>>>> >>>>> On Saturday, October 14, 2017 at 8:45:29 AM UTC-4, ejsvifq mabmip >>>>> wrote: >>>>>> >>>>>> On Saturday, October 14, 2017 at 4:53:10 AM UTC-4, Magnus Fromreide >>>>>> wrote: >>>>>>> >>>>>>> On Fri, Oct 13, 2017 at 07:38:20PM -0700, eulo...@live.com wrote: >>>>>>> > Contiguous Containers: >>>>>>> > >>>>>>> > vector: >>>>>>> > add non check push_back. non check resize etc. >>>>>>> >>>>>>> What does this mean, you are a bit thin on details here. >>>>>>> >>>>>>> ok. when you push_back an element into the vector, it will first >>>>>> check whether size()==capacity(). It is an overhead when you know what >>>>>> exactly the size of elements you need. >>>>>> >>>>>> For example: >>>>>> >>>>>> vector v; >>>>>> v.reserve(10000000); >>>>>> for(std::size_t i(0);I!=v.capacity();++i) >>>>>> v.emplace_back(i); >>>>>> >>>>>> will be slower than >>>>>> >>>>>> vector v; >>>>>> v.reserve(10000000); >>>>>> for(std::size_t i(0);I!=v.capacity();++i) >>>>>> v.nonchecked_emplace_back(i); >>>>>> >>>>> >>>>> Benchmark requested using -O2 or higher; I doubt your performance >>>>> claim. >>>>> >>>>> Todd >>>>> >>>>> >> IMHO if check in `emplace_back` cost is too much for you, you probably >> create your own container of use some specialized one from SG14. >> Vector cover 99% use cases, you are probably in 1% that is not included. >> > No, reserve is avoid making memory allocation and object moving that is very costly, you want only avoid one check. Usually object construction is costly and this one thing do not have any effect on this. Of corse you can have case when it mater (POD type, cant prealocate beforehand, and you only copy objects without any computations). Do you have whole application when this small difference matter? btw index operator is bit different, simply for any object you only create it once and accessed multiple times. Your proposition is magnitude less useful in typical applications (aka 99%). You probably need some hand crafted containers to better fit your needs. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b080b79f-bd00-4265-b55b-2c860691912c%40isocpp.org. ------=_Part_2480_1181761946.1508025041751 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Saturday, October 14, 2017 at 4:02:28 PM UTC+2,= ejsvifq mabmip wrote:
reserve is also 1%

On Saturday, October 14, 2017 at 9:49:14= AM UTC-4, Marcin Jaczewski wrote:


On Saturday, October 14, 2017 at 3:27:44 PM UTC+2= , ejsvifq mabmip wrote:
Try this code.

BTW. deque is "sl= ower" than vector because of this dumb check if

On Saturday, Oc= tober 14, 2017 at 9:24:37 AM UTC-4, eulo...@live.com wrote:
O2 wont eliminate thi= s cost. It is not optimization issue. I always use -O2 to compile my progra= ms

On Saturday, October 14, 2017 at 9:18:56 AM UTC-4, Todd Fleming w= rote:
On Saturday, = October 14, 2017 at 8:45:29 AM UTC-4, ejsvifq mabmip wrote:
On Saturday, October 14, 2017 at 4= :53:10 AM UTC-4, Magnus Fromreide wrote:
On Fri, Oct 13, 2017 at 07:38:20PM -0700, eulo...@= live.com wrote:
> Contiguous Containers:
>=20
> vector:
> add non check push_back. non check resize etc.

What does this mean, you are a bit thin on details here.

ok. when you push_back an element into the vector, it= will first check whether size()=3D=3Dcapacity(). It is an overhead when yo= u know what exactly the size of elements you need.

For example:

vector<std::size_t> v;
v.reserve(10000000);
for(std::size_t i(0);I!=3Dv.capacity(= );++i)
=C2=A0 =C2=A0=C2=A0 v.emplace_back(i);

will be slower than

vector<std::size= _t> v;
v.reserve(10000000);
for(std::= size_t i(0);I!=3Dv.capacity();++i)
=C2=A0 =C2=A0=C2=A0 v.noncheck= ed_emplace_back(i);

Bench= mark requested using -O2 or higher; I doubt your performance claim.

Todd

=C2=A0
IMHO if check in `emplace_ba= ck` cost is too much for you, you probably create your own container of use= some specialized one from SG14.
Vector cover 99% use cases, you = are probably in 1% that is not included.
=

No, reserve is avoid making memory allocat= ion and object moving that is very costly, you want only avoid one check. U= sually object construction is costly and this one thing do not have any eff= ect on this.
Of corse you can have case when it mater (POD type, = cant prealocate beforehand, and you only copy objects without any computati= ons). Do you have whole application when this small difference matter?

btw index operator is bit different, simply for any ob= ject you only create it once and accessed multiple times. Your proposition = is magnitude less useful in typical applications (aka 99%). You probably ne= ed some hand crafted containers to better fit your needs.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b080b79f-bd00-4265-b55b-2c860691912c= %40isocpp.org.
------=_Part_2480_1181761946.1508025041751-- ------=_Part_2479_1769153568.1508025041751-- .