220 40349 <649745f6-d2ff-4a01-bb51-964ba48ea1ee@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Runtime code generation and self modifying code Date: Sat, 6 Oct 2018 11:22:15 -0700 (PDT) Lines: 322 Approved: news@gmane.org Message-ID: <649745f6-d2ff-4a01-bb51-964ba48ea1ee@isocpp.org> References: <4489f889-977c-45f2-8a2f-186ee3b06bff@isocpp.org> <4503e7f2-de35-413f-a0d6-3d637c0609e9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1228_402401588.1538850135223" X-Trace: blaine.gmane.org 1538850011 3405 195.159.176.226 (6 Oct 2018 18:20:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2018 18:20:11 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBWH24POQKGQEGDCE4FA@isocpp.org Sat Oct 06 20:20:07 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f70.google.com ([209.85.161.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8rBP-0000lQ-Eg for gclcip-std-proposals@m.gmane.org; Sat, 06 Oct 2018 20:20:07 +0200 Original-Received: by mail-yw1-f70.google.com with SMTP id i1-v6sf9950971ywd.4 for ; Sat, 06 Oct 2018 11:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=eTHsQhGzT5p+PaQxPvAHMnb8eEuB+kHbTpoKgw2P2AQ=; b=oL/dbWoecMWLFHs0F6/AQH2/mP1rVxx6kI0H9G+Pn6JsFhxJ4oQB/XM5f7TzMnbrGy IFP7nNanY4um9o+KNBzJXqW27dFlAfvRnGIKoTyb3v4lUwIzWOzWU4g9tRRBK4FQWzuM WAfrOl5pDiDswytVrD3n76XAQ278UZwe+IUXmjmViLjEkvy8qjrTomFEkwZV1EWFXBhZ L2wjcMgdk1v2ga20GntYR7/Tbx0cpYKK8gDqTU3rYOpjHwXpuaJN2+duyxfvK73IDN51 kU0VUuLx687+180ASZFUpFzzV2RBxm/dj2KLZRNsGfhL7QoBc4r7BB02oC+mNfQ3tizp x8jQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=eTHsQhGzT5p+PaQxPvAHMnb8eEuB+kHbTpoKgw2P2AQ=; b=JRZ91VVON0kRm2gWIfTEmW5PZmSOwWJR6aSvf2LM7FGBlmR7X6yLcyJIqnM5D3i1zD te+iUU6Jo4A6PCsGG0vbtlw9Om2Krl9BXLvdQHqaUJxUeCv6lY28wZdDx+5R9b9ogSEH T62eqyfNDcFzvB7vgDrCbFEyJgWPc34fNunGjHUheet0Lqcej794VILdY3fzKF2dOXbg 4+Ff6rvnNoU/p9d3jLSEgnHMj1QP7/lGqe2Y3nZjTNg4ABCGyBPQF9VUSSioiq5uljXj jh9XvKvlwmazI3ApOzGw4iPTQ3+9bR7utKMtzgWLnZlFgsaFULx671RaMS3u5yYlUk1O 0mPw== 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: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=eTHsQhGzT5p+PaQxPvAHMnb8eEuB+kHbTpoKgw2P2AQ=; b=rFNWmMT2dNNege3/GWKPAliEG+Q3QrRYjkOeMJLVzOxLuOua+tGj8pjas+My+oCbL8 KNA/TNicQiNtmz8TZjSY5k6wZGXzijA6Cn+NwWiMyncBBlo5mislbaLEYWIpsoEH8ed5 uBUulRZXzNJVS8ZzSMte3oogsh/9EnmIE9hjHHg2NESSsl2sCivq60a4gvz02RcZD4SM UGc2cyaPk3KuahGHDZcNw1chuA9OhkTsBBKljQdpAviUGV7j6MdECTOobOLvhNf6IC/P H9RJDg/2ZL9q5v/xqQ7ir6WfKcH1v28nRPdmmRgjK6pyiEQ18gQMcTy5AOxwi4IfaOQF B3yw== X-Gm-Message-State: ABuFfoiZ15JL+QhGl0rNY5synnrpSbzAjR0TdeU50h7iKkzsM3jtTrDx XJ7GIZmXI+Ee4UNjryghkKhfhQ== X-Google-Smtp-Source: ACcGV62S7h2T2ZSXbtd3/86gPUNLr4qMyNwtpTUjxxrC8+L++YRtZKhGr90bruyn3PoJ0vYUcfBniw== X-Received: by 2002:a25:a091:: with SMTP id y17-v6mr9976435ybh.53.1538850137323; Sat, 06 Oct 2018 11:22:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:ae21:: with SMTP id m33-v6ls2566863ywh.9.gmail; Sat, 06 Oct 2018 11:22:15 -0700 (PDT) X-Received: by 2002:a81:13d4:: with SMTP id 203-v6mr135201ywt.5.1538850135673; Sat, 06 Oct 2018 11:22:15 -0700 (PDT) In-Reply-To: <4503e7f2-de35-413f-a0d6-3d637c0609e9@isocpp.org> X-Original-Sender: inkwizytoryankes@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:40349 Archived-At: ------=_Part_1228_402401588.1538850135223 Content-Type: multipart/alternative; boundary="----=_Part_1229_1584657147.1538850135224" ------=_Part_1229_1584657147.1538850135224 Content-Type: text/plain; charset="UTF-8" I probably have better solution: Great Memory Flush We have: One global counter that use only `memory_order_seq_cst` Thread local copy of this global counter (it will be updated to current value). Each static variable have atomic variable that store old value of global counter. Algorithm will look something like that: if (__static_var_counter > __thread_local_counter) //this could be even not atomic access { if (__static_var_counter != NOT_INIT) { __thread_local_counter = __great_memory_counter.load( memory_order_seq_cst); } else { __init_var(); //can lock __static_var_counter = __great_memory_counter.inc( memory_order_seq_cst); __thread_local_counter = __static_var_counter; } } If static variable value is less than current thread value the we can safely access memory protected by this variable. Because we already reload memory some time ago. If we encounter sequence of static variables: static int x; static int y; static int z; We can check only for last if it variable is less than current thread value and then skip whole block of initialization. On Saturday, October 6, 2018 at 7:25:47 PM UTC+2, Marcin Jaczewski wrote: > > > > On Friday, October 5, 2018 at 2:58:02 AM UTC+2, Ren Industries wrote: >> >> Couldn't a compiler just output that code for this idiom? >> Sounds like a QOI issue. >> >> > Could use of thread locals could improve this situation? You could store > info if variable was already check, if not we go current path if yes then > we can skip memory barrier. > > Only thing that current we can do is use function with `static` is return > pointer for future use: > X& init() > { > static X a{ }; > return a; > } > > void foo(X& stored) //free of cost > { > stored.bar(); > } > > int main() > { > foo(init()); //only main pay cost of init > } > > auto& global_x = init(); //this could work too > > > > >> On Thu, Oct 4, 2018 at 8:35 PM Matthew Fioravante >> wrote: >> >>> One big area where dynamic languages are way ahead of C++ is runtime >>> dynamic code generation or self modifying code. >>> >>> >>> One tiny example is singleton initialization. The only safe way in C++ >>> to do non-constexpr singletons is by lazy init. >>> >>> The problem with lazy init is that you have to pay for a branch on every >>> access, and that usually involves an atomic check. >>> >>> What if you instead you atomically overwrote the check with NOPS. Then >>> the branch is gone and accessing the object is as efficient as if it >>> weren't lazy. >>> >>> Has anyone considered writing proposals for improving runtime code gen >>> with C++? >>> >>> -- >>> 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-proposal...@isocpp.org. >>> To post to this group, send email to std-pr...@isocpp.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4489f889-977c-45f2-8a2f-186ee3b06bff%40isocpp.org >>> >>> . >>> >> -- 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/649745f6-d2ff-4a01-bb51-964ba48ea1ee%40isocpp.org. ------=_Part_1229_1584657147.1538850135224 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I probably have better solution: Great Memory Flush

We have:
One global counter that use = only `memory_order_seq_cst`
Thread local copy of this global coun= ter (it will be updated to current value).
Each static variable h= ave atomic variable that store old value of global counter.

<= /div>
Algorithm will look something like that:

if (__static_var_counter > __thread_local_counter) //this could be even not <= span style=3D"color: #800;" class=3D"styled-by-prettify">atomic access
{
=C2=A0 =C2=A0 if (__static_var_counter !=3D NOT_INIT)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __thread_local_coun= ter =3D __great_memo= ry_counter= ..load(memory_order_seq_cst);
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 else
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 __init_var(); //can= lock
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 __static_var_counter =3D __great_memory_counter.inc(memory_order_seq_cst);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 __thread_local_co= unter =3D<= /span> __static_v= ar_counter= ;
=C2= =A0 =C2=A0 }
}
=

If static variable value is less than current thread value= the we can safely access memory protected by this variable. Because we alr= eady reload memory some time ago.
If we encounter sequence o= f static variables:
static int x;
static int y;
static = int z;
=
We can check only for last if it variable is less than current thread= value and then skip whole block of initialization.


On Sat= urday, October 6, 2018 at 7:25:47 PM UTC+2, Marcin Jaczewski wrote:


On Friday, Oc= tober 5, 2018 at 2:58:02 AM UTC+2, Ren Industries wrote:
Couldn't a compiler just output= that code for this idiom?
Sounds like a QOI issue.


Could use of thread locals could improve this = situation? You could store info if variable was already check, if not we go= current path if yes then we can skip memory barrier.

<= div>Only thing that current we can do is use function with `static` is retu= rn pointer for future use:
X= & init()
{
=C2=A0 static X a{ };
=C2=A0 return a;
}

void foo(X& stored) //free of cost
{
=C2=A0 stored.bar= ();
= }

int main()
{
=C2=A0 = foo(ini= t()); <= /span>//only main pay cost of init
}

auto& global_x =3D init(); //this could work too


=C2=A0
On Thu, Oct 4, 2018 at 8:35 PM Matthew Fioravante <fmatth...@gmail.com> wrote:
One big area where dynamic languages are way ahead= of C++ is runtime dynamic code generation or self modifying code.


One tiny example is singleton initializ= ation. The only safe way in C++ to do non-constexpr singletons is by lazy i= nit.

The problem with lazy init is that you h= ave to pay for a branch on every access, and that usually involves an atomi= c check.

What if you instead you atomically overwr= ote the check with NOPS. Then the branch is gone and accessing the object i= s as efficient as if it weren't lazy.

Has = anyone considered writing proposals for improving runtime code gen with C++= ?

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/4489f889-977c-45f2-8a2f-= 186ee3b06bff%40isocpp.org.

--
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/649745f6-d2ff-4a01-bb51-964ba48ea1ee= %40isocpp.org.
------=_Part_1229_1584657147.1538850135224-- ------=_Part_1228_402401588.1538850135223-- .