220 40348 <4503e7f2-de35-413f-a0d6-3d637c0609e9@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 10:25:47 -0700 (PDT) Lines: 221 Approved: news@gmane.org Message-ID: <4503e7f2-de35-413f-a0d6-3d637c0609e9@isocpp.org> References: <4489f889-977c-45f2-8a2f-186ee3b06bff@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1071_2126836832.1538846747463" X-Trace: blaine.gmane.org 1538846624 19922 195.159.176.226 (6 Oct 2018 17:23:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2018 17:23:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBHHA4POQKGQEM3ITCWY@isocpp.org Sat Oct 06 19:23:40 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g8qIl-00055I-MP for gclcip-std-proposals@m.gmane.org; Sat, 06 Oct 2018 19:23:39 +0200 Original-Received: by mail-yw1-f69.google.com with SMTP id 131-v6sf9420279ywe.1 for ; Sat, 06 Oct 2018 10:25:50 -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=5jH9wgPPYr09iOJcGieYQMUsqU1/0x/MdDRrmVLWg1I=; b=brVrKk9IY+6VwoijhjWplkbqCxRjPOoh9ah1HUNItsCPC5HCowmftbv8inG7jaANL/ 0CczKowpO8tQFGVxP9DVqgBEyTQEnht8GfIsjXf8Ub0A0fNOvNbksT5OGGFz8qT3nS2c EQFk/aSCGH+fjAqx5SWYImwX0As4a0M23EhwQWzXCKJI48ZVV92ItbsjuN1mue86+G7W dtS7uyBzaDdcyCkVuia/3gmNlh8bFStgi/7JoLKTvhO4ze61o+Jw6eZkkGUfcSTHcly+ 8GCddsrm/V8dSkq8voNrqU1eqn0coZdmvY7F3I0J9EsAeNVRa+uyavfgdBITNA0OmGAA NCsg== 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=5jH9wgPPYr09iOJcGieYQMUsqU1/0x/MdDRrmVLWg1I=; b=QhmuTPIosSEo/ztle0Yk+DTQ9g7Fg+x4RDel5q3NpBEpCvU595by/itaajiW7x/Fme Gt/qoylYgmmyFJrYs6SIYCzknfTfHVrOCLowxSntoI5Ed2Y4D45Ct5H6JIMHMab0tcPX SLzsezEDtQJ7ZlGuNBT7rWVZkObjW6+MPYWt/3f8/eI6Bj4ueGvXo40zoNaUnnb9NSMZ +NTYjtgxZ7VVW0AjjMN7yn6GXCrMBvU2s7JWtJfvDL+NUh+EGi8u3cIXGvnnDB0vIcl4 kUWTk/qBax/gbED8kp3YXfPMKgiYGghUD+YneuUBiwRwHdp5MgAsGO6axiWrrz8aNSUn WltQ== 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=5jH9wgPPYr09iOJcGieYQMUsqU1/0x/MdDRrmVLWg1I=; b=JPAOOwaSmvOKilpWdhDhcvoyReShynUtBbPFIi8xWYMuHYq5gHLISkAvR9xiS4rtCo oRLMfM242MEXdhbJPXe2kpjfS22e9GzX/kW25FjMCv68Ed6s9umU08ZT1BfWHcfVt9Xj 8oY5XiQKisF6L3oju7eSZMrZY1xMPogpLqVgwLCQ/n2lcXb9ip2RZKQaJi97C3ZfV+/B Kj9cqH+vPlZBwSlFZ1RuTAkzct67LppLQquuqXEbv0njsSIIMW74ZHnjXWrW2+NvLAXc WE62tK3ku2hUfgw1sBO8GkeJVYMXY2xLIu83T5Sd37Otd/OMtd5rWtDwmoubd4ZhBepN 7VNw== X-Gm-Message-State: ABuFfoiFql9DmrHPIgq629ViHzHrW/0S1hLgO7lB5+vK5qKRyo9bHPNh YhDoBk1R6lin6/uS9L/fTqzA+Q== X-Google-Smtp-Source: ACcGV63qpVXGhnSSjtgiWegmfQcFqyl0i7WByY8+xbMtltgV/tQu1EIxZkGDrRrirKsolAqyB5SS0g== X-Received: by 2002:a25:bdc8:: with SMTP id g8-v6mr9892799ybk.101.1538846749831; Sat, 06 Oct 2018 10:25:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:b1c8:: with SMTP id p191-v6ls3750547ywh.3.gmail; Sat, 06 Oct 2018 10:25:48 -0700 (PDT) X-Received: by 2002:a81:1a07:: with SMTP id a7-v6mr151440ywa.1.1538846748245; Sat, 06 Oct 2018 10:25:48 -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-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:40348 Archived-At: ------=_Part_1071_2126836832.1538846747463 Content-Type: multipart/alternative; boundary="----=_Part_1072_228433328.1538846747464" ------=_Part_1072_228433328.1538846747464 Content-Type: text/plain; charset="UTF-8" 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/4503e7f2-de35-413f-a0d6-3d637c0609e9%40isocpp.org. ------=_Part_1072_228433328.1538846747464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Friday, October 5, 2018 at 2:58:02 AM UTC+2, Re= n Industries wrote:
Couldn't a compiler just output that code for this idiom?
Sou= nds 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 s= kip memory barrier.

Only thing that current we can= do is use function with `static` is return pointer for future use:
X& init()
{
=C2=A0 static X a{ };
=C2= =A0 return= a<= span style=3D"color: #660;" class=3D"styled-by-prettify">;
}

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

int= main()
{
=C2=A0 foo(init()); //only main pay cost of init
}

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


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


<= div>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 th= e branch is gone and accessing the object is as efficient as if it weren= 9;t lazy.

Has anyone considered writing propos= als 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.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 &= 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/4503e7f2-de35-413f-a0d6-3d637c0609e9= %40isocpp.org.
------=_Part_1072_228433328.1538846747464-- ------=_Part_1071_2126836832.1538846747463-- .