220 34938 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Micha=C5=82_Dominiak?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea about "std::pmr::memory_resource" Date: Sun, 15 Oct 2017 07:49:15 +0000 Lines: 165 Approved: news@gmane.org Message-ID: References: <0a8293b4-3246-47a5-9881-bc1ca4b91772@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114e6bc801429c055b912132" X-Trace: blaine.gmane.org 1508053765 13685 195.159.176.226 (15 Oct 2017 07:49:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 07:49:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCA6D5ULVYBRBBVGRTHQKGQEAEDQOCY@isocpp.org Sun Oct 15 09:49:21 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3dfk-0002tR-GG for gclcip-std-proposals@m.gmane.org; Sun, 15 Oct 2017 09:49:20 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id s41sf6126350uab.20 for ; Sun, 15 Oct 2017 00:49:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508053767; cv=pass; d=google.com; s=arc-20160816; b=u/WbIdD9Bmi0f86pjMVnMagDD6kxtYyF7l4nFsoBezARaOD2M7fWs+xqR1qMd3wAXj rKRbbAtaIsb8P3ZOUi9YvcwR0MjU1ZaloVoSvA632cm2Cf3/ftaVYIFOdHA+eArjZ66n yGI9d1O04fTK0lnQhXMHwyPD1twUbLdkloYeO6a6O1SmBl3SDdJj1xhtNLxPv41oYnAA eZ6rt6iFx8V98CYStKXPboR/3WNp6wGFSQw3UDOnINnH+ua6CQHibYyIc1BzpuyJXe96 H8xDFdrxCuOdl/v4I5MBAJhqAdtJ4ew6PSJ/8gVwP4MPy/G24BCdifkphcjmE6sTp8ed ZFJA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=0JqenMFEFhzIyOGI4+4YFOCZIuqLNuEqzNAtrlXd2PU=; b=C3I6LA7du7pfsAwrf8J/fBnNvYFr65sgv5nEYjL1XWfWbP5CB3Cjv8SSeXbolhhBn+ S837NdFkfRZbrEvGdKPzrtTleBv3Vr6/16Ump1YyCtYVIgZl5sdruDNwE04cIyI40UFR x+ZkD1/u7rkCiVUEUCU18YApyu8fs5ael/CMoLf9Y7NQoVQVHpXJiNv2JONHWNJ3UC4O c42dNcOHb3mh8MCVxolDXfw8wKpEUUXvo83IFH6b4v8TWRgDdVZ7dS6mpvhyOZA8K+jq /Qgv9BOc04LdzE50t63uqI5g1hj9nqyA8G1X2cqck1KIH0NfhkP6uYn1VwcJ2wi2yqyp kUdQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=UkgafcyH; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=0JqenMFEFhzIyOGI4+4YFOCZIuqLNuEqzNAtrlXd2PU=; b=wiN8ZNMX2zgt/uNv9rb2kTRl0ok6x2LhrLxxMqszBknA22WZAU/ei8lsaD1CYHi9Z9 GeDYBnvoiMGIANf3muqLJa2+3i32GTuGRd8WzwCgpQvOYIz+3+AjVA8m55HdYavvV7Ul 0OoGqzqVKLfxDUzJtwy3rbhB0mBg6UYMW07sr6008eZhAvnX1819h8SVNXJAAHZB4t+9 YeCaq0mUHZWtHn7MU7t5oAwIWuZpnPXdwfbdYtveaaZLhlDEXaMhCqUv1niL6TlnHhmM xpNWOa4eCKXX8B8LtHVf7RkruU6IP7vXokbHAVOtUgkdna3G8KZKvVi6eblw/a1HvV2v KIJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=0JqenMFEFhzIyOGI4+4YFOCZIuqLNuEqzNAtrlXd2PU=; b=hPgQHwJNjjPRS8xiNe2nHZz5gDMJ7DtpEV+60dD3eCvOZSlNaOI5kPuhjiSjKs0zcT Bm8tJTpGpgxyA3sERPds4upwocPsUvVU1G1Jr56QTSS64ZDLRAVrbJkI7L66SNfpGf/D 5dMZryftkjpF/C5NsJGaNvLjBtv8dJ/HDQeTaf4naMG9cqFaPDbRTeUdOJE/ea4t3wRK H/hrDua0tf0pt6V4F8TXvigt+TAr+f3cKyyxQM3bH0CJnYtlTJY6h4ikDgrVfkxc5Q9Z 1c3ZbK8oF45/V6I4liDDyivrN5sLgH79ZfBqkVXcmQcYmqTj9qEJjqeuhq0Sv172fYo3 aVKw== X-Gm-Message-State: AMCzsaXY+Og3q5GYahJzdjtd0OyZXKwGWspvxMRoSgz1vXT8udrySaNy G41Ew5u+dZrzd9s60EOYTko= X-Google-Smtp-Source: AOwi7QDtHH/2yK1UHXJvjZI7+AAM0GcKOfSgogp3jZX+8tSX1dioY6czsXMxSiUJ/20v0ii85zoQ1g== X-Received: by 10.176.19.70 with SMTP id h6mr3290787uae.94.1508053767777; Sun, 15 Oct 2017 00:49:27 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.77.90 with SMTP id k26ls1063838uag.3.gmail; Sun, 15 Oct 2017 00:49:26 -0700 (PDT) X-Received: by 10.31.2.137 with SMTP id 131mr4790028vkc.190.1508053766256; Sun, 15 Oct 2017 00:49:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508053766; cv=none; d=google.com; s=arc-20160816; b=Al+OIRQY3y/z6FFUa6Q0WTuThr0voE+9d4QToZZvnl7y3BbtZ/EAAANzkMb1WgD5gP 8bSCdTZ06NEdvwjPDxmzDLThJdbZ/pIy9SoVuCZbxHFqxoHfNLIcv31YX+nHOgAB+ke+ kGtuj0nm1xqMwLd4/He8OW9w+/VADWh3xQZr2+uBPaunNzK6v4nUdAXHPbd0hpj43PxK iuWSFtAE8hMPn83q8hviB38R4tHWdBnyoZtWfaUC8LXWF/6KL6b4lnw5/S1vnd0IrsJc x4WikmCLygr/KBbsd69rLfEdEN/MvxsU9gmMsFfzCMgIGGsJy095X9MSp4XuikQujeWk 6nlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=51OgjiRnjoUPXZhTocccSLkiB2TRHOWdxLm4MQz16oE=; b=SgC/EB7hgYfKpMVoKd9iTN/C1gOE68lY1mhbSUjg4X9kdijtHEQEZUglIplki4DEva DPM4wIhqY4vBv6/XgPJ0uL202Y56SlZTIJmWs9SWZeW2rZvjRBcOzLnuBvmqVeP/i7Rx T62ZzfjiHYkxzzLrFvvPJiTVGEDbJsXqdKkXtYFK4xDNo06APh+S+X0qecGeS7Ahe7vs WRqtfLExi3ikFZgfkiH8vgBavmohMyBSFWynfgDYAzu3KVZepj+kDtroKvfG4bMPWv/M DQUDGth9/PL28MLVdXK5ab8p3ByoD/q3wE5ITHgXjw7Pnai5XHTEmcdHWqDWzqgaDxSe zXdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=UkgafcyH; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id g207sor1813087vkf.34.2017.10.15.00.49.26 for (Google Transport Security); Sun, 15 Oct 2017 00:49:26 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) client-ip=209.85.220.41; X-Received: by 10.31.195.195 with SMTP id t186mr4871142vkf.198.1508053765664; Sun, 15 Oct 2017 00:49:25 -0700 (PDT) In-Reply-To: X-Original-Sender: griwes@griwes.info X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@griwes-info.20150623.gappssmtp.com header.s=20150623 header.b=UkgafcyH; spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of admin@griwes.info) smtp.mailfrom=admin@griwes.info 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:34938 Archived-At: --001a114e6bc801429c055b912132 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's memory allocation, folks. Unless you're doing a forever growing allocator that just keeps a pointer to the next block and doesn't allow freeing the memory, the virtual dispatch cost is going to get drowned in the cost of actually, you know, allocating the memory. People need to stop microoptimizing every cycle in silly places like this, and focus on the things that actually make their systems slow. On Sun, Oct 15, 2017 at 8:48 AM Jonathan M=C3=BCller < jonathanmueller.dev@gmail.com> wrote: > On Oct 14, 2017 10:14, "Mingxin Wang" wrote: > > Specifically, in order to define a "concrete memory resource", I suggest > to add the following concept: > > A type MR meets the MemoryResource requirements if the following > expressions are well-formed and have the specified semantics (mr denotes = a > value of type MR). > > mr.allocate(bytes, alignment) > Requires: The types of `bytes` and `alignment` are both `std::size_t`. > Returns: A pointer to allocated storage with a size of at least `bytes`= .. > The returned storage is aligned to the specified `alignment`, if such > alignment is supported; otherwise it is aligned to `max_align`. > Throws: Appropriate exception if it is unable to allocate memory with > the requested size and alignment. > > mr.deallocate(p, bytes, alignment) > Requires: The type of `p` is `void*`, the type of `bytes` and > `alignment` are both `std::size_t`; `p` shall have been returned from a > prior call to `allocate(bytes, alignment)` on a memory resource equal to > `*this`, and the storage at `p` shall not yet have been deallocated. > Effects: Dispose of allocated storage. > Throws: Nothing. > > > > It is non-standard but my memory library provides an allocator concept > similar to those you've described. You can find it here: > github.com/foonathan/memory. > > > I agree that making the PMRs polymorphic by default wasn't an ideal > choice. They should have been template based and provide a type erasure > wrapper. > > However, I've heard that the virtual overhead doesn't really matter much. > > -- > 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/CAEddoJZzSZ5= RROJ6Uu%3D2%2BR90mXi%2BhnHPDCxobrHM2daM6AxPVw%40mail.gmail.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/CAPCFJdQUrdiHDcZtziJbm6H62osF0o2V2QFU0h1t0ZjyjY7= qcw%40mail.gmail.com. --001a114e6bc801429c055b912132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's memory allocation, folks. Unless you're doing= a forever growing allocator that just keeps a pointer to the next block an= d doesn't allow freeing the memory, the virtual dispatch cost is going = to get drowned in the cost of actually, you know, allocating the memory.
People need to stop microoptimizing every cycle in silly p= laces like this, and focus on the things that actually make their systems s= low.

On Sun, Oct= 15, 2017 at 8:48 AM Jonathan M=C3=BCller <jonathanmueller.dev@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Oct 14, 2017 10:14, "Mingxin Wang" &= lt;wmx16835vv@163.c= om> wrote:
Specifically, in order to define a "concrete memory resource= ", I suggest to add the following concept:

A = type MR meets the MemoryResource requirements if the following expressions = are well-formed and have the specified semantics (mr denotes a value of typ= e MR).

mr.allocate(bytes, alignment)
=C2= =A0 Requires: The types of `bytes` and `alignment` are both `std::size_t`.<= /div>
=C2=A0 Returns: A pointer to allocated storage with a size of at = least `bytes`. The returned storage is aligned to the specified `alignment`= , if such alignment is supported; otherwise it is aligned to `max_align`.
=C2=A0 Throws: Appropriate exception if it is unable to allocate m= emory with the requested size and alignment.

mr.de= allocate(p, bytes, alignment)
=C2=A0 Requires: The type of `p` is= `void*`, the type of `bytes` and `alignment` are both `std::size_t`; `p` s= hall have been returned from a prior call to `allocate(bytes, alignment)` o= n a memory resource equal to `*this`, and the storage at `p` shall not yet = have been deallocated.
=C2=A0 Effects: Dispose of allocated stora= ge.
=C2=A0 Throws: Nothing.
<= div dir=3D"auto">
<pl= ug>
It is non-standard but my memory library provides an allocator concept sim= ilar to those you've described. You can find it here: github.com/foonathan/memory= .
</plug>

I agree that making the PMRs polymorphic by default wasn= 't an ideal choice. They should have been template based and provide a = type erasure wrapper.

Ho= wever, I've heard that the virtual overhead doesn't really matter m= uch.

--
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/CAEddoJZzSZ5RROJ6Uu%3D2%2BR90mXi%2BhnHPDCxobrHM2daM6AxPVw%40mail= ..gmail.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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQUrdiHDcZt= ziJbm6H62osF0o2V2QFU0h1t0ZjyjY7qcw%40mail.gmail.com.
--001a114e6bc801429c055b912132-- .