220 27007 article Path: news.gmane.org!not-for-mail From: Carl Cook Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Thu, 14 Jul 2016 15:56:32 -0700 (PDT) Lines: 321 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1130_1635151240.1468536992777" X-Trace: ger.gmane.org 1468537005 18174 80.91.229.3 (14 Jul 2016 22:56:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 22:56:45 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD27VEPGSEGBBIVRUC6AKGQE6E6DZTQ@isocpp.org Fri Jul 15 00:56:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNpYZ-0005VW-UM for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 00:56:36 +0200 Original-Received: by mail-vk0-f69.google.com with SMTP id r67sf8100882vkb.2 for ; Thu, 14 Jul 2016 15:56:35 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=9tnCV2CTVpYPwuaWQUPQNQiNS77LM5zP9L07e1IWPk0=; b=VXy06O7Q/jCJezXJ8p8E8KsUke884Pgswhk/m2xdIYkRf5rEcErF+CRUz+79d61qkV 3qZ7NAPC7bkUFqSMgcbMOYAac4phYCfZYzV5UwCd6b/jz1VtVRpPXTew4St00dkTptaV fK7+YZz6M6NAgVdHLxYWWoS8E7pLvwKMzGgc8YRcVfDqj3PKEEfHpS/xMMbrte9JHGLG RKX6wwynuMhZ0tJXC7/dsXghDSn6vedyTyOD0Job+esEkgNZjB3iu6HQrwVk+1GaE5RU x1xFE+syGBaH2ZiHkrt+o07IpAo0acfuBDmtxV2qhKGDItJf9eo9IZIv7vIZ2jkNmHpv 106g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=9tnCV2CTVpYPwuaWQUPQNQiNS77LM5zP9L07e1IWPk0=; b=cOf6zUeYBtUJPZzGGN9UXWPbdd9cJpRrhiqQWJYA/M1ivy/uFFJWr5vDSUhxs24j4e rdcL4BN0vIInsjnnh2PlVKOAENaLjRekA/6qKc07fTIjylxK2YaI6Y8W5aGQ3cdoJG5s kJxrONZrqiz3jKaarJ3uQs6DezgvsZMasIcGR2pOLmmL3TToaktf1ZnA2VX82IsVHHuv PLB1sKCoZFRl7CKlH3quo6jXdMTwKErCXY+DqxsCQDdceMZecp1zLyWJMAPuq0/jYOkm DMdmCuxrDMWwoKDWwokoXiewq2ZgE1EhZB6Xad2KuhoU4KDPCkHRMqsevnR5b9n8lMTl IGMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=9tnCV2CTVpYPwuaWQUPQNQiNS77LM5zP9L07e1IWPk0=; b=AULaG6gNt8PLdy3OGxwymVUOnIk0teLOn9cmBp6BE0v46nHtPbtAG1hi4VabwruORH 1bc42rEa8J76lnQhMZzdSIue1wb/uAz131S8mrW05oQuTzEH73LcPOvJ2fp6vj9WweXd z9q1WV1j4OKyMlwmAP5cA+lmdKHAULmXBtFqfScm11zgjYFguFmf0F94yoQeMVbuJycO tUbNQa3OzdK/zQe+9UDTpcKXsTh8rxrJT8ijVXurEzc11RUlWTZmUaao2W1c8qNKNQpn 8Miq72rBJQUgNRy7KgskWPCejQ1C//lX+/Pps+4jSpcAtoslq6AYSl7C8TpKsHxPUFmA QjYQ== X-Gm-Message-State: ALyK8tKE6jonlkKPr6+GgducZD/21CRtRYIZvloHIGyYwcQbMlbay2bYD+ZlECbAn1Wirw== X-Received: by 10.129.39.138 with SMTP id n132mr13211433ywn.42.1468536994969; Thu, 14 Jul 2016 15:56:34 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.15.148 with SMTP id 20ls1039254iop.25.gmail; Thu, 14 Jul 2016 15:56:33 -0700 (PDT) X-Received: by 10.36.53.200 with SMTP id k191mr1471897ita.9.1468536993888; Thu, 14 Jul 2016 15:56:33 -0700 (PDT) In-Reply-To: X-Original-Sender: carl.cook@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:27007 Archived-At: ------=_Part_1130_1635151240.1468536992777 Content-Type: multipart/alternative; boundary="----=_Part_1131_2098187099.1468536992778" ------=_Part_1131_2098187099.1468536992778 Content-Type: text/plain; charset=UTF-8 Hi all, Thanks very much for the feedback so far, this is exactly what I was looking for. Below are my responses to the questions raised. Please let me know if I haven't answered concisely enough, or have misunderstood the comments. - Is this too specialized for the standard library? Should this be in a TR/boost/extension only? - This is the most important comment in my opinion, and the driver for this proposal - to determine the level of support - Possibly it should be kept out of the standard. Here we are talking about introducting a whole new type, plus optionally specifying buffer sizes/alignment, just to save an allocation - On the flip side, it's actually more than an allocation. It's cache locality, potential to prefetch, deterministic performance, etc - This leads on to a bigger question - should low latency/high performance be a concern of the standard library? - I would argue yes, as industries such as finance/games/image processing/aerospace represent a large set of C++ users, and low latency requirements are a reality - How to determine the correct buffer size, at all times? - You can't. For that, fall back to std::function - In reality, inplace_function will only be used in specialized cases, and for that you will have a good idea of the size of the callable object - If your size is too conservative, the static assert will tell you what size you should have used - Also, from experience, the implementation's default size is fine 90% of the time - Why not consider a custom allocator? - Primarily, for performance (keeping the allocated memory together with the function object itself is important, for example) - A secondary concern is simplicity (another template argument introduces more complexity in terms of copy construction, assignment, etc) - That was a good point about the allocator memory outliving the function as well - Another concern is giving the implementation freedom in terms of memory layout/alignment/type erasure/management function pointers, etc (custom allocators make this harder to acheive) - I'll add this discussion to the design considerations part of the spec - What's the difference between inplace_function and LLVM's function_ref? - Excellent point - I've not seen function_ref until today - One difference - an inplace_function can be stored/copied/moved, even for non-trivial callable objects (for function_ref you'd need a second step of converting this to a std::function before storing/copying) - Another difference - I am not convinced function_ref successfully captures closures correctly (at least in GCC on -O1 or above, it doesn't appear to capture out of scope variables by reference or copy) - Again, I'll expand on this and add this to the proposal (after taking a closer look at function_ref) - Why not publish this draft proposal on github.io? - I don't particularly like having to push updated pdfs into github either, but I think the best thing for me to do is rewrite the proposal in markdown - Incidentally, github renders pdfs fine for me (using chrome/chromeos) Again, thanks very much for the comments so far. This helps improve the proposal, even if it never makes it out of draft stage. Please keep in mind that the primary goal of this proposal (at present) is to measure the interest/response of such a mechanism. But I do note several related proposals such as small/inplace vectors, inplace strings, inplace any/variant - i.e. there seems to be a theme here. Many thanks, Carl On Thursday, 14 July 2016 23:00:20 UTC+4, Jeffrey Yasskin wrote: > > Could you have your paper discuss the difference vs LLVM's function_ref<> ( > http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=273520&view=markup#l62) > and explain your view (whatever it is) over which set of these possible > function abstractions we should put in the standard? > > Thanks, > Jeffrey > > On Wed, Jul 13, 2016 at 3:47 PM, Carl Cook > wrote: > >> Hi all, >> >> This is a cross posting from the SG14 reflector, regarding a draft >> proposal some of us are working on. >> >> Very briefly, some of us are interested in having a standardized function >> which does not incur an upfront memory allocation to store the callable >> target, instead opting for a compile time specified buffer (stack >> allocated). This has been quite useful in several low latency domains such >> as gaming and electronic trading. In other words, a drop-in replacement for >> std::function, where all data is on the stack. >> >> The original post is here: >> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion >> >> The resultant draft proposal is here: >> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf >> >> >> Please feel free to comment here or in the SG14 reflector. This is still >> very much in the draft stage, and all feedback is appreciated. The >> reference implementation is still a work in progress ( >> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h). >> >> Many thanks, >> Carl >> >> -- >> 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/e00db911-40f5-4c11-a4b8-32bba77aa0a5%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/ff1087cf-5777-47e9-8caa-d28136aae130%40isocpp.org. ------=_Part_1131_2098187099.1468536992778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks very much for the feedba= ck so far, this is exactly what I was looking for.

Below are my responses to the questions raised. Please let me know if I ha= ven't answered concisely enough, or have misunderstood the comments.
  • Is this too specialized for the standard library? Should th= is be in a TR/boost/extension only?
    • This is the most important = comment in my opinion, and the driver for this proposal - to determine the = level of support
    • Possibly it should be kept out of the standard. He= re we are talking about introducting a whole new type, plus optionally spec= ifying buffer sizes/alignment, just to save an allocation
    • On the fl= ip side, it's actually more than an allocation. It's cache locality= , potential to prefetch, deterministic performance, etc
    • This leads = on to a bigger question - should low latency/high performance be a concern = of the standard library?
      • I would argue yes, as industries such = as finance/games/image processing/aerospace represent a large set of C++ us= ers, and low latency requirements are a reality
  • = How to determine the correct buffer size, at all times?
    • You can= 't. For that, fall back to std::function
    • In reality, inplace_fu= nction will only be used in specialized cases, and for that you will have a= good idea of the size of the callable object
      • If your size is t= oo conservative, the static assert will tell you what size you should have = used
    • Also, from experience, the implementation's default s= ize is fine 90% of the time
  • Why not consider a custom= allocator?
    • Primarily, for performance (keeping the allocated m= emory together with the function object itself is important, for example)
    • A secondary concern is simplicity (another template argument introdu= ces more complexity in terms of copy construction, assignment, etc)
    • That was a good point about the allocator memory outliving the functio= n as well
  • Another concern is giving the implementation freedom= in terms of memory layout/alignment/type erasure/management function point= ers, etc (custom allocators make this harder to acheive)
  • I'll a= dd this discussion to the design considerations part of the spec
<= /ul>
  • What's the difference between inplace_function and LLVM'= ;s function_ref?
    • Excellent point - I've not seen function_r= ef until today
      • One difference - an inplace_function can be stor= ed/copied/moved, even for non-trivial callable objects (for function_ref yo= u'd need a second step of converting this to a std::function before sto= ring/copying)
      • Another difference - I am not convinced function_ref = successfully captures closures correctly (at least in GCC on -O1 or above, = it doesn't appear to capture out of scope variables by reference or cop= y)
    • Again, I'll expand on this and add this to the proposal= (after taking a closer look at function_ref)

--
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/ff1087cf-5777-47e9-8caa-d28136aae130= %40isocpp.org.
------=_Part_1131_2098187099.1468536992778-- ------=_Part_1130_1635151240.1468536992777-- .