220 34934 <7b0ea405-f401-4883-9626-5642f94b8cfe@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: euloanty@live.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on more methods towards containers in the future Date: Sat, 14 Oct 2017 20:39:01 -0700 (PDT) Lines: 197 Approved: news@gmane.org Message-ID: <7b0ea405-f401-4883-9626-5642f94b8cfe@isocpp.org> 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_2000_1340154353.1508038741386" X-Trace: blaine.gmane.org 1508038742 26525 195.159.176.226 (15 Oct 2017 03:39:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 03:39:02 +0000 (UTC) Cc: euloanty@live.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDPYX6PYRQNBBVVQRPHQKGQEXP5I2KI@isocpp.org Sun Oct 15 05:38:57 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3ZlQ-0006CS-6D for gclcip-std-proposals@m.gmane.org; Sun, 15 Oct 2017 05:38:56 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id d12sf5778649uaj.18 for ; Sat, 14 Oct 2017 20:39:04 -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=4S8EFv2KNCEcohlBXIJk284GZRvm2Lu7+FGk42vcOTc=; b=WVu1ki8WyCFKJ6N3HE4HD81F1SO6ccDXXoKdzF4UN7zKqYHUDMQbrseOWIRwk3u8XN GHF+aTtUS3/bypdWuDHUn+8UY+GFExv0Tp4aF3N+ghd0HtNELVdHvndTnX++HOmI3tfK rVGsPq7oCMfs/VwBm/b4d/BwHlHO7MRej4Ebs7ebHxddJWqg18i37FNNwZrdNb8oTw19 R0hG17pEPDyLdlKp21SNyAMa6PIcDZvy7UTuvSwamO1xf/4S0Gz+0tM/DXjGQ0utdRL0 ocMmHjIfxTj09VlrEQuVeeylT/nViv3eXnRoFscWpGP0vep676XIS86o/WbLbpMJpdRq p1Mw== 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=4S8EFv2KNCEcohlBXIJk284GZRvm2Lu7+FGk42vcOTc=; b=FlzvSVZIVlXp1dHFSc4T7Oa1fKyDPWLPPY+cHeWueanb922luDYCT+6g0MBD217P2v nWLzmc+tYuBEUk1tQW1rZeQefaC/4++xbs1k1S7KHIFlVC/3GgatDdYSSXJ7tuGBNjbL gBUbRq0PgcZfVHhGSqSRfl9ds8u1KeysIVlk7wGXQtvAJj5F4/OFz0XH4SUZd8YgM/Iu gf13fTa5oDPkCKa2/n33LGehsGJX1kkXtIVHfa0xS5iWQrY0sGlvK9PRBRQPLguRgtf5 nAtSXchq4oDP9VIGJrsHoeSepeFA0gNi9DrnL3aipTe9OKplPcdeDfjMpzVnL7YejlW9 DUmQ== X-Gm-Message-State: AMCzsaX2hfTjpCdlvedXaXPskIxa+qqDtjuTOTMWpaglnf4JpP/4bBNs lB96ATlCyyIg9Elw2h8vCD9LCQ== X-Google-Smtp-Source: AOwi7QBwhdbLxlUxLoJSsmvoqfGgXMrfezKkpOZEyhhiEd0ai306HhfioT4HwzrFtINwNh6a5GXiYw== X-Received: by 10.176.65.193 with SMTP id 59mr3214152uap.71.1508038743522; Sat, 14 Oct 2017 20:39:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.27.91 with SMTP id n27ls1752010uai.5.gmail; Sat, 14 Oct 2017 20:39:02 -0700 (PDT) X-Received: by 10.31.142.13 with SMTP id q13mr393199vkd.1.1508038741989; Sat, 14 Oct 2017 20:39:01 -0700 (PDT) In-Reply-To: X-Original-Sender: euloanty@live.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:34934 Archived-At: ------=_Part_2000_1340154353.1508038741386 Content-Type: multipart/alternative; boundary="----=_Part_2001_2061535071.1508038741386" ------=_Part_2001_2061535071.1508038741386 Content-Type: text/plain; charset="UTF-8" yea. I've written an entire vector for unsafe operations. lol On Saturday, October 14, 2017 at 7:50:41 PM UTC-4, Marcin Jaczewski wrote: > > > 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/7b0ea405-f401-4883-9626-5642f94b8cfe%40isocpp.org. ------=_Part_2001_2061535071.1508038741386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yea. I've written an entire vector<T> for u= nsafe operations. lol

On Saturday, October 14, 201= 7 at 7:50:41 PM UTC-4, Marcin Jaczewski wrote:


On Saturday, October 14, 201= 7 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:


O2 won= t eliminate this cost. It is not optimization issue. I always use -O2 to co= mpile 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:<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
On Saturday, Octobe= r 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/7b0ea405-f401-4883-9626-5642f94b8cfe= %40isocpp.org.
------=_Part_2001_2061535071.1508038741386-- ------=_Part_2000_1340154353.1508038741386-- .