Re: Passing UniquePtr by value is more expensive than by rref
Note that, later in his talk [1], Chandler clarifies that he still recommends passing unique_ptr by value, because while compilers may currently generate better code for passing them by reference, passing them by value is still more optimizable in the long term (since passing them by reference encodes a double indirection -- you're passing a reference to a pointer -- in the type system). Cheers, Botond [1] https://youtu.be/rHIkrotSwcc?t=2418 On Mon, Oct 14, 2019 at 8:43 AM Nathan Froyd wrote: > > On Mon, Oct 14, 2019 at 3:58 AM Henri Sivonen wrote: > > On Mon, Oct 14, 2019 at 9:05 AM Gerald Squelart > > wrote: > > > > > > I'm in the middle of watching Chandler Carruth's CppCon talk "There Are > > > No Zero-Cost Abstractions" and there's this interesting insight: > > > https://youtu.be/rHIkrotSwcc?t=1041 > > > > > > The spoiler is already in the title (sorry!), which is that passing > > > std::unique_ptr by value is more expensive than passing it by rvalue > > > reference, even with no exceptions! > > > > > > I wrote the same example using our own mozilla::UniquePtr, and got the > > > same result: https://godbolt.org/z/-FVMcV (by-value on the left, by-rref > > > on the right.) > > > So I certainly need to recalibrate my gutfeelometer. > > > > The discussion in the talk about what is needed to fix this strongly > > suggested (without uttering "Rust") that Rust might be getting this > > right. With panic=abort, Rust gets this right ( > > https://rust.godbolt.org/z/SZQaAS ) which really makes one appreciate > > both Rust-style move semantics and the explicitly not-committal ABI. > > With a little voodoo placement of [[clang::trivial_abi]] > (https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/, > https://reviews.llvm.org/D41039) on Pair specializations and UniquePtr > itself, one can make the by-value function look more like what you > might expect, but at the cost (!) of making the rvalue-ref function > look more like the original by-value function, > https://godbolt.org/z/A1wjl8. I think that's a reasonable tradeoff to > make if we wanted to start using [[clang::trivial_abi]]. > > -Nathan > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: To what extent is sccache's distributed compilation usable?
On 10/25/19 2:54 AM, Marcos Caceres wrote: Do you know if it's possible to cross compile on one of those for to target MacOS? I'd like to build on, and for, MacOS. Our official mac builds are cross-compiled from Linux, IIRC. So yeah, it should be possible to do that. Cross-compiling to target MacOS is a bit involved, requiring getting the relevant SDKs in the Linux box, the relevant mozconfig flags, and what not. But probably nothing too bad? I've done it in the past, mostly cargo-culting from the official mozconfigs in the tree. Not sure if there are official docs somewhere though. I also know that sccache-dist can be used somewhat painlessly from Mac, unlike icecc (requires some setup as described here[1], but doesn't seem too bad). So you have two options, I think: * Setup a Linux box as an sccache-dist scheduler and builder. This should require no SDKs or what not, but requires some setup in your mac as described here[1]. Then you'd just do regular sccache-enabled ./mach build from your Mac, which would then distribute work to your Linux box. * Setup a Linux box with a full cross-compilation setup, build there, and somehow pull the objdir from there back to your mac (not sure what's best here for incremental builds, rsync or something?). If you only have one builder, and your Mac is slow, the second option is probably a bit faster to get a clobber build than sccache (as you don't need to do network stuff for every compilation unit and such). But obviously I haven't measured, so it may be the case that the sccache overhead is low and the extra cores from your mac add up for it. Some caveats about the second setup: * I don't know how to best do the objdir / incremental builds with such a setup (some people in this list probably know though, and I'd be interested in knowing too!). * You need to do your changes over ssh, or have a setup where you also sync the src directories or something. The first option should also be relatively straight-forward, hopefully, looking at the docs here[2], though I haven't set up an sccache scheduler myself. Again there's people in this list that know more than me, so probably they can help more :) Cheers, -- Emilio [1]: https://firefox-source-docs.mozilla.org/build/buildsystem/sccache-dist.html [2]: https://github.com/mozilla/sccache/blob/master/docs/DistributedQuickstart.md#configure-a-scheduler ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
