220 34975 article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea about "std::pmr::memory_resource" Date: Mon, 16 Oct 2017 20:35:55 -0700 (PDT) Lines: 254 Approved: news@gmane.org Message-ID: References: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> <07ddb1f6-d3af-43df-bf96-8975c1ab4313@isocpp.org> <2e191a96-1952-479b-b78b-22e31f8e03de@isocpp.org> <0e37b5ae-64f6-4a8a-86bd-f44b119ed40a@isocpp.org> <15f8c5ba-3a6a-4441-9620-92e157c66094@isocpp.org> <26fe4cb4-98ca-41cc-ac96-5c51851799d1@isocpp.org> <784ffce8-ace7-449d-a13d-a99d7336117a@isocpp.org> <60f71623-0a56-478e-8dcc-e76685fc8706@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19046_446693016.1508211355794" X-Trace: blaine.gmane.org 1508211363 31293 195.159.176.226 (17 Oct 2017 03:36:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 03:36:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBHHVSXHQKGQE574YUNY@isocpp.org Tue Oct 17 05:35:58 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4Ifb-0006W8-T1 for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 05:35:56 +0200 Original-Received: by mail-ua0-f199.google.com with SMTP id h34sf236475uaa.8 for ; Mon, 16 Oct 2017 20:36:03 -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=+JY7cGy/GmiHrnyEzW/sXBwmFM8G0Rqd5QvpXz3wd8w=; b=cv3hTxVRwuj5IDnJHq9Vpu7HCtpXf6Ygn77RUekELBGbwmEXAhWpzsRua5D13+8Cl2 fv20QpFyeHpd4MiV3ix2pIXZwN6RBCmPi3xBPLV21bGiyaFsIKY1MtA3z/6IYPWCR3ew nZtT6dimOruRzqKMvJNiTFKZfBY0NRigiHMjWjQgWr6NsBWu7R8tkfdWfiW8AWJAeUge 37RoT2OGqiIx7IbslQCuaac7V9GzShkOGFdt6UAM3yjoXK1J79De6du+t9jSOd4i3XMy iwaPyt9g04I2O5rC/O3y6kSvGLIFwA73TpUCE1Ti6azezWYsp0DtUFWLt/SanyFlUoMX GKgQ== 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=+JY7cGy/GmiHrnyEzW/sXBwmFM8G0Rqd5QvpXz3wd8w=; b=sn2ghKHGE03E7U3Jky7KruLw0wJwYKHlYSCEHr04TYYUWiIr86F1Qad4qQ7IOH5vtl LpuyovivXHECV9n+X4YqQRCFGBhRwyRWjgcn87kAbwIeF6AoPJGJoCzf+HRiFPEklY45 kjkpj98Z2FHM7/HF14wTUvFFa+3I4RCrIo0RZ7k7iobncV+kqmWOo4bhp9AjYRt7xAbt qTVkj7UlLiCGBlCKtS0b4VzEjo5I0HmQooTyX7GtdNj5E4FPNPP5owtZ/eclDp3vHCzj cIFZuFKo3Y87+nTDi9XkPihkvgnR2/XCWJBQV2zTJV6EyfHpz9MLXdArCf3gyhzare4f wBoA== X-Gm-Message-State: AMCzsaXaOk8gCmiMF3ZqUIjpQxEq+MEVabHzwiK03BMNJzSChnHDqjO0 RvOaPTHxmkNuy+PS6cCuqPb3Eg== X-Google-Smtp-Source: AOwi7QAeZGLaCbrZVnX9SN/DxJDgvcPP949ZQd3LZPW2agnQCNV6qyHJQnDaYbZlmqvUQe1vKDtIhA== X-Received: by 10.159.59.10 with SMTP id i10mr6254467uah.61.1508211358018; Mon, 16 Oct 2017 20:35:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.56.21 with SMTP id f21ls31610vka.1.gmail; Mon, 16 Oct 2017 20:35:56 -0700 (PDT) X-Received: by 10.31.137.138 with SMTP id l132mr542482vkd.14.1508211356341; Mon, 16 Oct 2017 20:35:56 -0700 (PDT) In-Reply-To: <60f71623-0a56-478e-8dcc-e76685fc8706@isocpp.org> X-Original-Sender: wmx16835vv@163.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:34975 Archived-At: ------=_Part_19046_446693016.1508211355794 Content-Type: multipart/alternative; boundary="----=_Part_19047_379779897.1508211355794" ------=_Part_19047_379779897.1508211355794 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tuesday, October 17, 2017 at 4:44:16 AM UTC+8, Nicol Bolas wrote: > > On Monday, October 16, 2017 at 6:26:09 AM UTC-4, Mingxin Wang wrote: >> >> Adding a "MemoryResource" type to the template of a polymorphic facility= =20 >> is positive for performance in large-scale programming. >> > > Where is the "large-scale programming" that needs "large-scale" quantitie= s=20 > of `any` and/or `function` or similar type-erased types? Generally=20 > speaking, such tools are not used in high-performance code, not so much= =20 > because of allocation behavior, but because they require type-erasure and= =20 > therefore are more expensive than static polymorphism. > I disagree with that. I think polymorphic requirements are more likely to= =20 appear in large-scale program, because independent modules are difficult to= =20 be implemented with templates, and therefore they tend to accept=20 polymorphic input. For example, the "threadpool" is a common facility in=20 large-scale programming, and it seems that no one could implement such=20 facility without polymorphism (more specifically, function pointers). Actually, allocation is much more expensive than polymorphism in various=20 implementations for `std::any`. In order to prove that, I have run a couple= =20 of performance tests for the "template constructor" (that is, construct=20 from an arbitrary type) and "copy constructor" of `std::any` with empty=20 trivial types whose size range from 1 to 64. Here is the environment information: CPU: Intel=C2=AE core(TM) i7-4700HQ @ 2.40GHz Memory: 12GB OS: CentOS 7.2 Compiler: gcc 7.1.0 x64 posix Compiler Flags: -Wall -fexceptions -march=3Dcorei7-avx =E2=80=93O3 -m64 -fc= oncepts=20 -std=3Dc++17 And the experimental results are as follows: It is apparent that the execution time has increased significantly when the= =20 size of the test class changes from 8 to 9. It is because that the size for= =20 "Small Object Optimization" is 8 (defined by the implementation of=20 `std::any`). When the size becomes larger, there are memory allocations,=20 and allocations consume much more time than polymorphism. We could use it in allocators and polymorphic facilities, and we are able= =20 >> to configure whether the memory resource should be polymorphic. >> > > Which we can already do. `pmr::memory_resource` is a polymorphic type, so= *by=20 > definition* it can be used in "polymorphic facilities". And you can very= =20 > much build allocators out of them; that's what a=20 > `pmr::polymorphic_allocator` *is*. > > If you wanted, you could make a `pmr::static_allocator= `=20 > template that takes its `pmr::memory_resource`-derived class by type. As= =20 > such, it can de-virtualize any calls to the allocation/deallocation=20 > functions. Thus, it would be essentially zero overhead. > However, this compiler optimization does not hold under all circumstances,= =20 especially when there are classes derived from a=20 "`pmr::memory_resource`-derived class", unless it is explicitly declared=20 "final". Besides, a "`pmr::memory_resource`-derived class" is certainly not empty,= =20 even if it is stateless; so that `pmr::static_allocator` could not be empty either. Even if the=20 compiler could deduce that a "`pmr::memory_resource`-derived class" is=20 accessible without any dispatcher, there is no chance to optimize the size. =20 > So what *exactly* can you not do currently that you want to do? > > If there is no particular demand in "std::pmr::memory_resource", I have n= o=20 >> objection to removing it, because it is easily implementable with "the= =20 >> proxy=20 >> "=20 >> (I am still working on that proposal). >> > > But we do have a "particular demand" for it; that's why it was=20 > standardized. If there was no demand, we wouldn't have standardized it. > OK, that's no big deal, because it is easily implementable with "the proxy= =20 ".=20 I will add it into that proposal as a use case. Mingxin Wang --=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/d41189b5-cf47-4ddc-bf3c-0274394015f2%40isocpp.or= g. ------=_Part_19047_379779897.1508211355794 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, October 17, 2017 at 4:44:16 AM UTC+8, Nicol Bo= las wrote:
On = Monday, October 16, 2017 at 6:26:09 AM UTC-4, Mingxin Wang wrote:
Adding a "MemoryRe= source" type to the template of a polymorphic facility is positive for= performance in large-scale programming.

<= /div>
Where is the "large-scale programming" that needs "= ;large-scale" quantities of `any` and/or `function` or similar type-er= ased types? Generally speaking, such tools are not used in high-performance= code, not so much because of allocation behavior, but because they require= type-erasure and therefore are more expensive than static polymorphism.

I disagree with that. I think pol= ymorphic requirements are more likely to appear in large-scale program, bec= ause independent modules are difficult to be implemented with templates, an= d therefore they tend to accept polymorphic input. For example, the "t= hreadpool" is a common facility in large-scale programming, and it see= ms that no one could implement such facility without polymorphism (more spe= cifically, function pointers).

Actually, allocatio= n is much more expensive than polymorphism in various implementations for `= std::any`. In order to prove that, I have run a couple of performance tests= for the "template constructor" (that is, construct from an arbit= rary type) and "copy constructor" of `std::any` with empty trivia= l types whose size=C2=A0range from 1 to 64.

Here i= s the=C2=A0environment information:

CPU: Inte= l=C2=AE core(TM) i7-4700HQ @ 2.40GHz
Memory: 12GB
OS: C= entOS 7.2
Compiler: gcc 7.1.0 x64 posix
Compiler Flags:= -Wall -fexceptions -march=3Dcorei7-avx =E2=80=93O3 -m64 -fconcepts -std=3D= c++17

And the=C2=A0experimental results are = as follows:

=



It is apparent that the execution time has increased significantly when t= he size of the test class changes from 8 to 9. It is because that the size = for "Small Object Optimization" is 8 (defined by the implementati= on of `std::any`). When the size becomes larger, there are memory allocatio= ns, and allocations consume much more time than polymorphism.
We could use it in = allocators and polymorphic facilities, and we are able to configure whether= the memory resource should be polymorphic.

Which we can already do. `pmr::memory_resource` is a polym= orphic type, so by definition it can be used in "polymorphic fa= cilities". And you can very much build allocators out of them; that= 9;s what a `pmr::polymorphic_allocator<T>` is.
=
If you wanted, you could make a `pmr::static_allocator<T,= MemoryResource>` template that takes its `pmr::memory_resource`-derived= class by type. As such, it can de-virtualize any calls to the allocation/d= eallocation functions. Thus, it would be essentially zero overhead.

However, this compiler optimization do= es not hold under all circumstances, especially when there are classes deri= ved from a "`pmr::memory_resource`-derived class", unless it is e= xplicitly declared "final".

Besides, a &= quot;`pmr::memory_resource`-derived class" is certainly not empty, eve= n if it is stateless; so that `pmr::static_allocator<T, `pmr::memory_res= ource`-derived>` could not be empty either. Even if the compiler could d= educe that a "`pmr::memory_resource`-derived class" is accessible= without any dispatcher, there is no chance to optimize the size.
=C2=A0
=
So what exactly can you not do currently that you want to do?

If there is no particular demand in "s= td::pmr::memory_resource", I have no objection to removing it, because= it is easily implementable with "the proxy" (I am sti= ll working on that proposal).

B= ut we do have a "particular demand" for it; that's why it was= standardized. If there was no demand, we wouldn't have standardized it= ..

OK, that's no big dea= l, because it is easily implementable with "the proxy". I will add it into that propo= sal as a use case.

Mingxin Wang

--
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/d41189b5-cf47-4ddc-bf3c-0274394015f2= %40isocpp.org.
------=_Part_19047_379779897.1508211355794-- ------=_Part_19046_446693016.1508211355794-- .