220 30308 article Path: news.gmane.org!.POSTED!not-for-mail From: Brittany Friedman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Zero initialization and std::uinitialized_t Date: Thu, 5 Jan 2017 12:19:16 -0600 Lines: 203 Approved: news@gmane.org Message-ID: References: <3870bc78-3ce6-1825-4558-cdfbb8241fcc@gmail.com> <4624163.gm4MgrvsJC@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d4ed279dede05455cf066 X-Trace: blaine.gmane.org 1483640373 10384 195.159.176.226 (5 Jan 2017 18:19:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2017 18:19:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCHLPXGUXMJBBJU4XLBQKGQEQ7UHVPQ@isocpp.org Thu Jan 05 19:19:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f199.google.com ([209.85.216.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPCd8-0000qt-KY for gclcip-std-proposals@m.gmane.org; Thu, 05 Jan 2017 19:19:14 +0100 Original-Received: by mail-qt0-f199.google.com with SMTP id f4sf997616qte.1 for ; Thu, 05 Jan 2017 10:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=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-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=FC5WfKIZO39dRxiCimTy49uihfiYMxr6GS8PDIWuSY4=; b=CcG9cCVKHs1pFwYFYJvB1qNeiaSRvzf+K/fpxzLykGqsTajS8kY1m2ojwuw0XMfgG4 lG4XZQpX4YNTkBSViyPXSFd17oSaLayePy6dIkSqCLxg2/Z86zv95DJK4iPF9Z7j/XiC UCJ4UCngpvnK1EctB83KbFtzvgQ5l4AVZ5GuSc4Dx5uHn/7oVGuTeCczR+bvS8uYX8Q4 flyFny7gtvg2dXJIRWZMJTsY+ICMevbQdE5J+hoiYdZYKdbu+3vo5LHIbV7HWl7rLXz0 +SqhFZZ9FxiECvCaWkJM5domrI4eK3L6tyRPpTlK+28wksj9I8nZICAIqNnMuDgo5uOZ Oeug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state: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-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=FC5WfKIZO39dRxiCimTy49uihfiYMxr6GS8PDIWuSY4=; b=YSez+Q5VeMgRM4Pdo/YZLDFljsxZ2gQHmfslZMZbQr4aj5X72wb3mFUrAW8kcA5mSI X7H+vpMaCAlf2OcR/xb/u3wZSLl6VSm+HNgHV7nAdFy6uQDEFm5cRSGvH8ShaaWqoEoO hq07Luvw/Df+gWXO/60S/PVVBOk9RyhoBFrYXVxet7UgC+ww+CPq6/Ow3mOGaABBXQDQ j2JVt8Lio/CNZ4DjzwzxJPzCcGPnsK/Dzfa9NvHRIPUQxkUIfKEj0kB3+uvVpKHei4bT bBPjjTjvG3P0/K2IUX4jIVz5oRkoO9fBZm6AgTRdkRnwCmPULnS3NDNCHSl18hdlWwih CxOQ== X-Gm-Message-State: AIkVDXINcQ8W37VfleJfAGc3X2MW6JwsteQ7KqpGCZR3bAwUoZHUl0e24WjZsf2SdfmBSQ== X-Received: by 10.237.59.203 with SMTP id s11mr18953511qte.32.1483640358614; Thu, 05 Jan 2017 10:19:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.8.69 with SMTP id 63ls25228384oty.30.gmail; Thu, 05 Jan 2017 10:19:17 -0800 (PST) X-Received: by 10.55.192.137 with SMTP id v9mr69196322qkv.305.1483640357830; Thu, 05 Jan 2017 10:19:17 -0800 (PST) Original-Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com. [2607:f8b0:400d:c0d::235]) by mx.google.com with ESMTPS id v80si38277167qkl.21.2017.01.05.10.19.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 10:19:17 -0800 (PST) Received-SPF: pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:400d:c0d::235 as permitted sender) client-ip=2607:f8b0:400d:c0d::235; Original-Received: by mail-qt0-x235.google.com with SMTP id v23so58277882qtb.0 for ; Thu, 05 Jan 2017 10:19:17 -0800 (PST) X-Received: by 10.200.46.123 with SMTP id s56mr66281636qta.8.1483640357376; Thu, 05 Jan 2017 10:19:17 -0800 (PST) Original-Received: by 10.140.31.6 with HTTP; Thu, 5 Jan 2017 10:19:16 -0800 (PST) In-Reply-To: X-Original-Sender: fourthgeek@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of fourthgeek@gmail.com designates 2607:f8b0:400d:c0d::235 as permitted sender) smtp.mailfrom=fourthgeek@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:30308 Archived-At: --001a113d4ed279dede05455cf066 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One possible place where this could have severe negative impacts would be write-combined memory. Some of the vagaries of write-combined memory are discussed here: https://fgiesen.wordpress.com/2013/01/29/write-combining-is-not-your-friend= / Especially note at the end how it talks about the importance of sequential writes. If we do one pass over the data structure to zero-initialize it and another pass over the data structure to set it to the actual values we want then you may cause either major performance hits or even undefined behavior= .. I've never worked with WC memory myself so I don't know how much this might or might not be an issue, but remember that C++ might also be used in some lower level drivers for example. On Thu, Jan 5, 2017 at 12:12 PM, Avi Kivity wrote: > On 01/05/2017 06:53 PM, Thiago Macieira wrote: > >> Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Vouti= lainen >> escreveu: >> >>> In order to make the proposed change, come back with proof that it >>> doesn't hurt performance anywhere. >>> Before that, it will not fly anywhere. >>> >> Think especially of non-static data members. >> > > That was indeed my motivation. Statics are already initialized, and > automatic storage duration variables are normally declared at the point o= f > initialization in modern code. > > Given NSDMI, your proposal >> automatically means all member variables are zero-initialised unless >> explicitly initialised ith std::uninitialised in the constructor. This i= s >> a >> perfect example of what Ville is saying: the compiler simply cannot prov= e >> that >> a variable left uninitialised in a constructor is a good thing or not. >> >> Changing the default means all constructors (including inline ones!) mus= t >> zero-intialise, even variables whose contents are protected by other >> member >> variables, =C3=A0 la std::optional. >> > > > No, std::optional will placement-new the variable when the optional is > engaged. Similar to how reserved-but-not-initialized vector elements are > not initialized until they are push_back()ed. > > > Of course, there is a performance impact, but with modern C++ it grows > smaller and smaller as people use containers, or other abstractions to > manage their data; for example std::string or a matrix library know wheth= er > they need to initialize or not. There will be some code that is negative= ly > impacted (this can be addressed by adding std::uninitialized or whatever) > and some code that is positively impacted, by converting heisenbugs to > repeatable behavior. > > > > -- > 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/is > ocpp.org/d/msgid/std-proposals/bf9fe7b0-93ea-a553-3a4a- > bf15ea59b721%40scylladb.com. > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CADbh%2BeT7iCftgC9Bier%3DeY-EmrP1qEQ5PH17VkeDt28= mXAQcXg%40mail.gmail.com. --001a113d4ed279dede05455cf066 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 5, 2017 at 12:12 PM, Avi Kivity <avi@scy= lladb.com> wrote:
On 01/05/2017 06:53 PM, Thiago Macieira wrote:
Em quinta-feira, 5 de janeiro de 2017, =C3=A0s 12:58:58 PST, Ville Voutilai= nen
escreveu:
In order to make the proposed change, come back with proof that it
doesn't hurt performance anywhere.
Before that, it will not fly anywhere.
Think especially of non-static data members.

 That was indeed my motivation.=C2=A0 Statics are already initialized, and a= utomatic storage duration variables are normally declared at the point of i= nitialization in modern code.

=C2=A0 Given NSDMI, your proposal
automatically means all member variables are zero-initialised unless
explicitly initialised ith std::uninitialised in the constructor. This is a=
perfect example of what Ville is saying: the compiler simply cannot prove t= hat
a variable left uninitialised in a constructor is a good thing or not.

Changing the default means all constructors (including inline ones!) must zero-intialise, even variables whose contents are protected by other member=
variables, =C3=A0 la std::optional.


 No, std::optional will placement-new the variable when the optional is enga= ged.=C2=A0 Similar to how reserved-but-not-initialized vector elements are = not initialized until they are push_back()ed.


Of course, there is a performance impact, but with modern C++ it grows smal= ler and smaller as people use containers, or other abstractions to manage t= heir data; for example std::string or a matrix library know whether they ne= ed to initialize or not.=C2=A0 There will be some code that is negatively i= mpacted (this can be addressed by adding std::uninitialized or whatever) an= d some code that is positively impacted, by converting heisenbugs to repeat= able behavior.



--
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.
 To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/bf9fe7b0-93ea-a553-3a4a-bf15ea59b721%40scylladb.com.

--
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/CADbh%2BeT7iC= ftgC9Bier%3DeY-EmrP1qEQ5PH17VkeDt28mXAQcXg%40mail.gmail.com.
--001a113d4ed279dede05455cf066-- .