220 27020 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal - non allocating std::function Date: Thu, 14 Jul 2016 17:35:39 -0700 Lines: 334 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/alternative; boundary=94eb2c0837a64baff50537a1ccfc X-Trace: ger.gmane.org 1468542954 1289 80.91.229.3 (15 Jul 2016 00:35:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 00:35:54 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBBXO7UC6AKGQEFZW2NCY@isocpp.org Fri Jul 15 02:35:43 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNr6V-000895-2m for gclcip-std-proposals@m.gmane.org; Fri, 15 Jul 2016 02:35:43 +0200 Original-Received: by mail-qk0-f199.google.com with SMTP id a123sf194577722qkd.2 for ; Thu, 14 Jul 2016 17:35:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references: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=XjnbucWBTm+2f/NwtymjUHzBzO64CY9R/e+ZO8K9y8g=; b=QmHIQ3R2ciotVRzMe/UZykXoMOutT4B2p5zEvZM2sM0EVS2jkyD068EG5Fws1FIBP7 E+IqwChXpCetqNHoUmHzOf57WWL6uqgCYpdoM5CYSnKzyRWI4TT047vrGBeO3onzn7Sl ehyTfeRdphjWMxyiOHssh/ZemuHbdmoL7gkgSToRDWfBi6wIC31oATrVQ7uIfiRhH3Ey 1jKCOG9HrsDHxcSt09cdehModw2TtbCH2N4+uEtO2zLF+i8VEQEGHB5JdxZI+B+TLIDf 4+NZSXLNOahnAwLgqEnMcLBO7oRl2j0JulW0QB4HnNMJOpeWClwzklEqxDnwUPO6fRAf P6DQ== X-Gm-Message-State: ALyK8tIIa6oHTbMB2AvWe2lEpuzKhj0ZqFnzhbGJ8G1ChUZaoRdKBtTtypi2dwjpoAsNFw== X-Received: by 10.129.48.208 with SMTP id w199mr13047495yww.58.1468542942056; Thu, 14 Jul 2016 17:35:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.9.7 with SMTP id 7ls2821735otp.32.gmail; Thu, 14 Jul 2016 17:35:40 -0700 (PDT) X-Received: by 10.200.54.243 with SMTP id b48mr6990715qtc.0.1468542940850; Thu, 14 Jul 2016 17:35:40 -0700 (PDT) Original-Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com. [2607:f8b0:400d:c09::22f]) by mx.google.com with ESMTPS id e13si3160614qkh.333.2016.07.14.17.35.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Jul 2016 17:35:40 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400d:c09::22f as permitted sender) client-ip=2607:f8b0:400d:c09::22f; Original-Received: by mail-qk0-x22f.google.com with SMTP id x1so3624512qkb.3 for ; Thu, 14 Jul 2016 17:35:40 -0700 (PDT) X-Received: by 10.55.149.70 with SMTP id x67mr20441324qkd.66.1468542940325; Thu, 14 Jul 2016 17:35:40 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.200.56.152 with HTTP; Thu, 14 Jul 2016 17:35:39 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400d:c09::22f as permitted sender) smtp.mailfrom=metafoo@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:27020 Archived-At: --94eb2c0837a64baff50537a1ccfc Content-Type: text/plain; charset=UTF-8 On Thu, Jul 14, 2016 at 3:56 PM, Carl Cook wrote: > 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) > > llvm::function_ref doesn't capture anything, and is not supposed to -- it's a *non-owning* handle to a callable that outlives the handle. (llvm::function_ref is to std::function as std::string_view is to std::string.) This is a feature and a design goal of llvm::function_ref, but I think it means it's addressing a fundamentally different problem than the one you're tackling here (which seems to be essentially, "let me control the size and alignment in std::function's small function optimization") > > - 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 > > . > -- 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/CAOfiQqn31H_Mfkxx3yty1%3Dwqu50JnpcSv25uLP3DNDTb5E8WYQ%40mail.gmail.com. --94eb2c0837a64baff50537a1ccfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 14, 2016 at 3:56 PM, Carl Cook <carl.cook@gmail.com> wrote:
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 en= ough, or have misunderstood the comments.
  • Is this too spe= cialized for the standard library? Should this be in a TR/boost/extension o= nly?
    • This is the most important comment in my opinion, and the = driver for this proposal - to determine the level of support
    • Possib= ly it should be kept out of the standard. Here we are talking about introdu= cting 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, determ= inistic performance, etc
    • This leads on to a bigger question - shoul= d low latency/high performance be a concern of the standard library?
    • I would argue yes, as industries such as finance/games/image processi= ng/aerospace represent a large set of C++ users, and low latency requiremen= ts are a reality
  • How to determine the correct bu= ffer size, at all times?
    • You can't. For that, fall back to = std::function
    • In reality, inplace_function will only be used in spe= cialized cases, and for that you will have a good idea of the size of the c= allable object
      • If your size is too conservative, the static ass= ert will tell you what size you should have used
    • Also, from ex= perience, the implementation's default size is fine 90% of the time
  • Why not consider a custom allocator?
    • Primari= ly, for performance (keeping the allocated memory together with the functio= n object itself is important, for example)
    • A secondary concern is s= implicity (another template argument introduces more complexity in terms of= copy construction, assignment, etc)
      • That was a good point abou= t the allocator memory outliving the function as well
    • Another = concern is giving the implementation freedom in terms of memory layout/alig= nment/type erasure/management function pointers, etc (custom allocators mak= e this harder to acheive)
    • I'll add this discussion to the desig= n considerations part of the spec
  • What's the diff= erence between inplace_function and LLVM's function_ref?
    • Ex= cellent point - I've not seen function_ref until today
      • One = difference - an inplace_function can be stored/copied/moved, even for non-t= rivial callable objects (for function_ref you'd need a second step of c= onverting this to a std::function before storing/copying)
      • Another d= ifference - I am not convinced function_ref successfully captures closures = correctly (at least in GCC on -O1 or above, it doesn't appear to captur= e out of scope variables by reference or copy)
llvm::function_ref doesn't capture anything, and i= s not supposed to -- it's a *non-owning* handle to a callable that outl= ives the handle. (llvm::function_ref is to std::function as std::string_vie= w is to std::string.) This is a feature and a design goal of llvm::function= _ref, but I think it means it's addressing a fundamentally different pr= oblem than the one you're tackling here (which seems to be essentially,= "let me control the size and alignment in std::function's small f= unction optimization")
    • Again, I'll expand on this and add this to t= he proposal (after taking a closer look at function_ref)
    =
  • Why not publish this draft proposal on github.io?
    • I don't particularly like hav= ing 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 sta= ge.

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 th= eme here.

Many thanks,
Carl

On Thursday, 14 July 2016 23:00:2= 0 UTC+4, Jeffrey Yasskin wrote:
Could you have your paper discuss the= difference vs LLVM's function_ref<> (http://llvm.or= g/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=3D27= 3520&view=3Dmarkup#l62) and explain your view (whatever it is) over= which set of these possible function abstractions we should put in the sta= ndard?

Thanks,
Jeffrey
=
On Wed, Jul 13, 2016 at 3:4= 7 PM, Carl Cook <carl...@gmail.com= > wrote:
Hi all,

This is a cross posting f= rom the SG14 reflector, regarding a draft proposal some of us are working o= n.

Very briefly, some of us are interested in havi= ng a standardized function which does not incur an upfront memory allocatio= n to store the callable target, instead opting for a compile time specified= buffer (stack allocated). This has been quite useful in several low latenc= y domains such as gaming and electronic trading. In other words, a drop-in = replacement for std::function, where all data is on the stack.



Please f= eel 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 implemen= tation is still a work in progress (https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h).


--
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.o= rg.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposa= ls/e00db911-40f5-4c11-a4b8-32bba77aa0a5%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-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.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn31H_Mfk= xx3yty1%3Dwqu50JnpcSv25uLP3DNDTb5E8WYQ%40mail.gmail.com.
--94eb2c0837a64baff50537a1ccfc-- .