220 35015 <6ed3bbca-1cee-4b69-a527-29109d4d5d5f@isocpp.org> 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: Thu, 19 Oct 2017 02:18:20 -0700 (PDT) Lines: 492 Approved: news@gmane.org Message-ID: <6ed3bbca-1cee-4b69-a527-29109d4d5d5f@isocpp.org> 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> <342fbace-1540-4333-9fd4-f2ee8012e852@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1430_702259966.1508404700913" X-Trace: blaine.gmane.org 1508404706 14563 195.159.176.226 (19 Oct 2017 09:18:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 19 Oct 2017 09:18:26 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBXO3UHHQKGQENTW7VCQ@isocpp.org Thu Oct 19 11:18:21 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 1e56y3-0002uL-1z for gclcip-std-proposals@m.gmane.org; Thu, 19 Oct 2017 11:18:19 +0200 Original-Received: by mail-ua0-f199.google.com with SMTP id l40sf4317024uah.1 for ; Thu, 19 Oct 2017 02:18:26 -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=J856AWHdg4CuDrRJbjnPBWY1n615XZXdtzJPSP1uc/k=; b=EV5LbjdN0Bzktryad4I+3MjJ3GPEIsEQcBUly25aMYL/G19WuJFsxnFecrIg8X506v c1Rw+sJqZG1piJ1Ifs2sthV3QNcI59EstbqNC2x+ncwsQeGeDKz6BzWCRi5aBVXwv+UZ A2Oo4eWyRBEffVxRpxRLzUKtWJ0MmvZcrKC042JNVRycPtRb50swAvgVdQl2moXBfIRx QAsG52po8I1h9QLripdUVJlXYmXIO4SlmmFG/z5LCMvYhAyd9LGTSqtROH+1XZDOVhH1 H2vlpvRKrn5dm0fW6mPjrA81LKUFJtPYP45FegaNK/OEYeFfCjQE4FCt5mjWhalnQB/R KNyQ== 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=J856AWHdg4CuDrRJbjnPBWY1n615XZXdtzJPSP1uc/k=; b=el/CDvTZMWWB6o5KYYixdMSmC3rANmxqJtS24+Qy6KQEPHmCdINwv6Hj5A78D1broR xeKrIaTVyB9BUnJv3mtoOBHTG3nO5KM/7ieHcrd7V3VRTrhBlX5u1vVwg6t85E8gLNyB b6dPjYCSdCteVQLbd+Bc15SXqk24XuQhmdB3gLcLRIeVQxYosqYsWm/zzGpyOQnaty8A Bel2SuQ34gBNslewQJ+85PoMNUT4fCfX0XlXKPu1mQdrY5BYPxkNDzCc5Y/xwbEKlvZG YlENIigPHokbxMj/PyUyTNOCLADqtd2k6Ha8hz0EoYxGym/y35NIOWTU8kuHdNey5G3k 31Wg== X-Gm-Message-State: AMCzsaUc31FCj1H8peXgTL8rT5S3itorTvdPVBSSpkBP/8GQszYOsIwG FdbXDU5ItKSOKFGzkxhDQaZoRA== X-Google-Smtp-Source: ABhQp+Rcj2M7Qdr4b5FhVsaTU0bgTj4KXasniP1W/Q9YHJjMaPXutVl23VJZNOodnZ9bog1n1teN6Q== X-Received: by 10.176.23.151 with SMTP id r23mr409840uaf.65.1508404706320; Thu, 19 Oct 2017 02:18:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.56.109 with SMTP id q42ls1918959uad.18.gmail; Thu, 19 Oct 2017 02:18:21 -0700 (PDT) X-Received: by 10.31.96.146 with SMTP id u140mr81998vkb.2.1508404701547; Thu, 19 Oct 2017 02:18:21 -0700 (PDT) In-Reply-To: <342fbace-1540-4333-9fd4-f2ee8012e852@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:35015 Archived-At: ------=_Part_1430_702259966.1508404700913 Content-Type: multipart/alternative; boundary="----=_Part_1431_163873856.1508404700914" ------=_Part_1431_163873856.1508404700914 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wednesday, October 18, 2017 at 3:32:37 AM UTC+8, Nicol Bolas wrote: > > On Monday, October 16, 2017 at 11:35:55 PM UTC-4, Mingxin Wang wrote: >> >> 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=20 >>>> facility is positive for performance in large-scale programming. >>>> >>> >>> Where is the "large-scale programming" that needs "large-scale"=20 >>> quantities of `any` and/or `function` or similar type-erased types?=20 >>> Generally speaking, such tools are not used in high-performance code, n= ot=20 >>> so much because of allocation behavior, but because they require=20 >>> type-erasure and therefore are more expensive than static polymorphism. >>> >> >> I disagree with that. I think polymorphic requirements are more likely t= o=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). >> > > OK, there seems to be a misunderstanding as to what "large-scale" meant. = I=20 > took that to mean "used a lot in performance-critical code." You seemed t= o=20 > take that to mean "large program." > > Allow me to rephrase what I said, taking this into account: who cares? > > Unless you are in performance-critical code, performance doesn't matter.= =20 > However "large-scale" or "small-scale" the code is, unless the allocation= =20 > is happening in the part of the code that is critical for performance, yo= u=20 > shouldn't care where the memory comes from. > > It is true that the performance of memory allocation is not likely to be a= =20 bottleneck in some cases. However, the performance issue was introduced to= =20 prove that the PMR system is somewhat problematic, and it also reflects to= =20 issues about usability and extendibility. For usability, as a user, I dislike using the memory resources with=20 pointers (so does references), because we are responsible for managing the= =20 lifetime of the concrete memory resources, e.g. via new/delete. If=20 `std::memory_resource` is defined as a polymorphic wrapper, it is no longer= =20 an issue, because the wrapper could manage the lifetime of the concrete=20 entity in a proper way. Moreover, with the support from my upcoming =E2=80= =9Cproxy=20 system=E2=80=9D, we could also have more lifetime management strategies fro= m=20 =E2=80=9Caggregated relationship=E2=80=9D to =E2=80=9Cweak association rela= tionship=E2=80=9D. For extendibility, as an implementer of a 3rd party library extending the= =20 PMR system, I do dislike overriding a virtual function like=20 `std::pmr::memory_resource::do_is_equal`, which forces us to use RTTI just= =20 to compare whether two memory resources are reflexive. If there is no such= =20 =E2=80=9Cvirtual base=E2=80=9D, it becomes easy for us to produce such logi= c with some=20 proper overloads of `operator=3D=3D`. So unless adding tasks to a threadpool is a significant part of your code's= =20 > performance (and it's hard to see how that could be the case), there's no= =20 > reason to have a *static* facility in `function` for overriding=20 > allocation behavior. A dynamic polymorphic facility would make sense, but= =20 > again, we can use `pmr::memory_resource` for that as is. > Yes, =E2=80=9Cwe can use `pmr::memory_resource`=E2=80=9D, but there is a be= tter choice. =20 > Actually, allocation is much more expensive than polymorphism in various= =20 >> implementations for `std::any`. >> > > ... nobody suggested otherwise. The only question is whether that code is= =20 > performance-critical, and whether the performance difference between stat= ic=20 > polymorphism and dynamic polymorphism will matter. > > 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,= =20 >>> so *by definition* it can be used in "polymorphic facilities". And you= =20 >>> can very 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>> MemoryResource>` template that takes its `pmr::memory_resource`-derived= =20 >>> class by type. As such, it can de-virtualize any calls to the=20 >>> allocation/deallocation functions. Thus, it would be essentially zero= =20 >>> overhead. >>> >> >> However, this compiler optimization does not hold under all=20 >> circumstances, especially when there are classes derived from a=20 >> "`pmr::memory_resource`-derived class", unless it is explicitly declared= =20 >> "final". >> > > I was thinking that it would simply call `MR::allocate` to allocate the= =20 > bytes, where `MR` is the memory resource type passed to the template. Tha= t=20 > ought to bypass the virtual mechanism. But then I looked at=20 > `pmr::memory_resource` and saw that the actual virtual functions are=20 > private. It can still be done; make `pmr::memory_resource` declare=20 > `static_allocator` a friend of itself, so that it can directly cal= l=20 > `do_allocate` non-virtually. > It is doable, but less elegant. If we are not using a function=20 polymorphically, why bother defining it as a virtual one? =20 > Besides, a "`pmr::memory_resource`-derived class" is certainly not empty,= =20 >> even if it is stateless; so that `pmr::static_allocator> `pmr::memory_resource`-derived>` 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 si= ze. >> > > Is `static_allocator` going to derive from it? No; it has to hold a=20 > pointer to it, since one ought to be able to change memory resources. So= =20 > the instance of `memory_resource` is going to have to take up storage=20 > *somewhere*. > And we are also responsible for managing the lifetime of the concrete=20 memory resources. =20 > So let's look at this objectively. Thus far, the objective benefits from= =20 > enforcing the use of type-erased polymorphism for memory resources rather= =20 > than using a virtual base class is that... you save a pointer's worth of= =20 > bytes. But *only* when you're using static polymorphism; if you're=20 > actually using dynamic polymorphism via type-erasure, that cost comes bac= k. > > Is saving those few bytes really important enough to bother? > `Saving those few bytes` is not important in most cases. What important is= =20 that the PMR system is wasting those few bytes once you want to use it not= =20 polymorphically. Actually, the benefits in adding the concept =E2=80=9CMemoryResource=E2=80= =9D include not=20 only potentially higher performance, but also clearer semantics, more=20 usability and more extendibility. =20 > Also... when exactly would a memory resource not have state? If we're=20 > talking about optimizing memory allocations, you would generally be using= =20 > some kind of pool. And since you're optimizing memory allocations, you=20 > don't want to make this some global state (as that would require mutex=20 > locks or something similar on allocate/deallocate calls). So the=20 > memory_resource class would either contain the pool or reference the pool= ..=20 > Either way, it has state. > `std::pmr::new_delete_resource` is actually stateless. =20 > If you're doing one of those "arena" allocators where you just advance an= =20 > pointer, you might be able to get away with making it global by making th= e=20 > pointer atomic. But having multiple arena allocators is also something yo= u=20 > might want, and there's no reason to create multiple types just to have= =20 > that (which bloats code size due to template usage). So such resources=20 > probably access their arenas via either containing the arena or referenci= ng=20 > it. > I never denied the necessity in polymorphic allocators, and there is no=20 conflict between =E2=80=9Cthe demand in polymorphic memory resources=E2=80= =9D and =E2=80=9Cthe=20 demand in non-polymorphic ones=E2=80=9D. =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= =20 >>>> no 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=20 >> proxy=20 >> ".=20 >> I will add it into that proposal as a use case. >> > > Um... `pmr::memory_resource` *already exists* in the standard. It's not= =20 > going to be removed just because you think you've found something better. > I think it is somewhat subjective to draw such a conclusion before a panel= =20 discussion by the committee. Mingxin Wang=20 --=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/6ed3bbca-1cee-4b69-a527-29109d4d5d5f%40isocpp.or= g. ------=_Part_1431_163873856.1508404700914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, October 18, 2017 at 3:32:37 AM UTC+8, Nicol = Bolas wrote:
O= n Monday, October 16, 2017 at 11:35:55 PM UTC-4, Mingxin Wang wrote:
On Tuesday, October 17, 2= 017 at 4:44:16 AM UTC+8, Nicol Bolas wrote:
On Monday, October 16, 2017 at 6:26:09 AM UTC-4, M= ingxin Wang wrote:
=
Adding a "MemoryResource" type to the template of a polymorp= hic facility is positive for performance in large-scale programming.
<= /div>

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

I dis= agree with that. I think polymorphic requirements are more likely to appear= in large-scale program, because independent modules are difficult to be im= plemented with templates, and therefore they tend to accept polymorphic inp= ut. For example, the "threadpool" is a common facility in large-s= cale programming, and it seems that no one could implement such facility wi= thout polymorphism (more specifically, function pointers).

OK, there seems to be a misunderstanding as to = what "large-scale" meant. I took that to mean "used a lot in= performance-critical code." You seemed to take that to mean "lar= ge program."

Allow me to rephrase what I said= , taking this into account: who cares?

Unless you = are in performance-critical code, performance doesn't matter. However &= quot;large-scale" or "small-scale" the code is, unless the a= llocation is happening in the part of the code that is critical for perform= ance, you shouldn't care where the memory comes from.


It is true that the performa= nce of memory allocation is not likely to be a bottleneck in some cases. Ho= wever, the performance issue was introduced to prove that the PMR system is= somewhat problematic, and it also reflects to issues about usability and e= xtendibility.

For usability, as a user, I dislike = using the memory resources with pointers (so does references), because we a= re responsible for managing the lifetime of the concrete memory resources, = e.g. via new/delete. If `std::memory_resource` is defined as a polymorphic = wrapper, it is no longer an issue, because the wrapper could manage the lif= etime of the concrete entity in a proper way. Moreover, with the support fr= om my upcoming =E2=80=9Cproxy system=E2=80=9D, we could also have more life= time management strategies from =E2=80=9Caggregated relationship=E2=80=9D t= o =E2=80=9Cweak association relationship=E2=80=9D.

For extendibility, as an implementer of a 3rd party library extending the = PMR system, I do dislike overriding a virtual function like `std::pmr::memo= ry_resource::do_is_equal`, which forces us to use RTTI just to compare whet= her two memory resources are reflexive. If there is no such =E2=80=9Cvirtua= l base=E2=80=9D, it becomes easy for us to produce such logic with some pro= per overloads of `operator=3D=3D`.

So unless a= dding tasks to a threadpool is a significant part of your code's perfor= mance (and it's hard to see how that could be the case), there's no= reason to have a static facility in `function` for overriding alloc= ation behavior. A dynamic polymorphic facility would make sense, but again,= we can use `pmr::memory_resource` for that as is.
=

Yes, =E2=80=9Cwe can use `pmr::memory_resource`=E2=80= =9D, but there is a better choice.
=C2=A0
Actually, allocati= on is much more expensive than polymorphism in various implementations for = `std::any`.

... nobody suggeste= d otherwise. The only question is whether that code is performance-critical= , and whether the performance difference between static polymorphism and dy= namic polymorphism will matter.

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 polymorphic type, so by definition it ca= n be used in "polymorphic facilities". And you can very much buil= d allocators out of them; that's what a `pmr::polymorphic_allocator<= T>` is.

If you wanted, you could ma= ke a `pmr::static_allocator<T, MemoryResource>` template that takes i= ts `pmr::memory_resource`-derived class by type. As such, it can de-virtual= ize any calls to the allocation/deallocation functions. Thus, it would be e= ssentially zero overhead.

Howev= er, this compiler optimization does not hold under all circumstances, espec= ially when there are classes derived from a "`pmr::memory_resource`-derived class", unless it is explicitly declared "final".=

I was thinking that it would s= imply call `MR::allocate` to allocate the bytes, where `MR` is the memory r= esource type passed to the template. That ought to bypass the virtual mecha= nism. But then I looked at `pmr::memory_resource` and saw that the actual v= irtual functions are private. It can still be done; make `pmr::memory_resou= rce` declare `static_allocator<T, MR>` a friend of itself, so that it= can directly call `do_allocate` non-virtually.

It is doable, but less elegant. If we are not using a func= tion polymorphically, why bother defining it as a virtual one?
=C2=A0
<= /div>
Besides, a "`pmr::memory_resource`-derived class" = is certainly not empty, even if it is stateless; so that `pmr::static_alloc= ator<T, `pmr::memory_resource`-derived>` could not be empty eith= er. Even if the compiler could deduce that a "`pmr::memory_resource`-<= wbr>derived class" is accessible without any dispatcher, there is no c= hance to optimize the size.

Is = `static_allocator` going to derive from it? No; it has to hold a pointer to= it, since one ought to be able to change memory resources. So the instance= of `memory_resource` is going to have to take up storage somewhere.=

And we are also responsible fo= r managing the lifetime of the concrete memory resources.
=C2= =A0
So let's look at this objectively. Thus far, the objective = benefits from enforcing the use of type-erased polymorphism for memory reso= urces rather than using a virtual base class is that... you save a pointer&= #39;s worth of bytes. But only when you're using static polymorp= hism; if you're actually using dynamic polymorphism via type-erasure, t= hat cost comes back.

Is saving those few bytes really i= mportant enough to bother?

`Savi= ng those few bytes` is not important in most cases. What important is that = the PMR system is wasting those few bytes once you want to use it not polym= orphically.

Actually, the benefits in adding the c= oncept =E2=80=9CMemoryResource=E2=80=9D include not only potentially higher= performance, but also clearer semantics, more usability and more extendibi= lity.
=C2=A0
Also... when exactly would a memory = resource not have state? If we're talking about optimizing memory alloc= ations, you would generally be using some kind of pool. And since you'r= e optimizing memory allocations, you don't want to make this some globa= l state (as that would require mutex locks or something similar on allocate= /deallocate calls). So the memory_resource class would either contain the p= ool or reference the pool. Either way, it has state.

`std::pmr::new_delete_resource` is actually stateless= ..
=C2=A0
If you're doing one of those "arena" allo= cators where you just advance an pointer, you might be able to get away wit= h making it global by making the pointer atomic. But having multiple arena = allocators is also something you might want, and there's no reason to c= reate multiple types just to have that (which bloats code size due to templ= ate usage). So such resources probably access their arenas via either conta= ining the arena or referencing it.

<= div>I never denied the necessity in polymorphic allocators, and there is no= conflict between =E2=80=9Cthe demand in polymorphic memory resources=E2=80= =9D and =E2=80=9Cthe demand in non-polymorphic ones=E2=80=9D.
=C2=A0
=
So what exactly can you not do currently that you want to do?

If there is no particular demand in "std::pmr::memory_resource&= quot;, I have no objection to removing it, because it is easily implementab= le with "the proxy" (I am still working on that propos= al).

But we do have a "par= ticular demand" for it; that's why it was standardized. If there w= as no demand, we wouldn't have standardized it.

OK, that's no big deal, because it is easily i= mplementable with "the proxy". I will add it into that= proposal as a use case.

Um... = `pmr::memory_resource` already exists in the standard. It's not = going to be removed just because you think you've found something bette= r.

I think it is somewhat subje= ctive to draw such a conclusion before a panel discussion by the committee.=

Mingxin Wang=C2=A0

--
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/6ed3bbca-1cee-4b69-a527-29109d4d5d5f= %40isocpp.org.
------=_Part_1431_163873856.1508404700914-- ------=_Part_1430_702259966.1508404700913-- .