RE: queue_transaction interface + unique_ptr + performance

emer...@redhat.com] Sent: Thursday, December 03, 2015 5:44 PM To: Somnath Roy Cc: Samuel Just; Casey Bodley; Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique_ptr + performance On 04/12/2015, Somnath Roy wrote: [snip] > # Test

RE: queue_transaction interface + unique_ptr + performance

-Original Message- From: Somnath Roy Sent: Thursday, December 03, 2015 10:16 PM To: 'Adam C. Emerson' Cc: Samuel Just; Casey Bodley; Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: RE: queue_transaction interface + unique_ptr + performance Adam, May be I am

RE: queue_transaction interface + unique_ptr + performance

1- I agree we should avoid shared_ptr whenever possible. 2- unique_ptr should not have any more overhead than a raw pointer--the compiler is enforcing the single-owner semantics. See for example https://msdn.microsoft.com/en-us/library/hh279676.aspx "It is exactly is efficient as a

RE: queue_transaction interface + unique_ptr + performance

> -Original Message- > From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel- > ow...@vger.kernel.org] On Behalf Of Somnath Roy > Sent: Thursday, December 03, 2015 3:13 AM > > *Also*, in this way we are unnecessary adding another smart pointer > overhead in the Ceph IO path. > As I

RE: queue_transaction interface + unique_ptr + performance

nath Roy Cc: Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: RE: queue_transaction interface + unique_ptr + performance 1- I agree we should avoid shared_ptr whenever possible. 2- unique_ptr should not have any more overhead than a raw pointer--the compiler is enfor

Re: queue_transaction interface + unique_ptr + performance

On 03/12/2015, Somnath Roy wrote: > Yes, I posted the new result after adding -O2 in the compiler flag and it > shows almost no overhead with unique_ptr. > I will add the test of adding to list overhead and start implementing the new > interface. > But, regarding my other point of changing all

RE: queue_transaction interface + unique_ptr + performance

muel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique_ptr + performance Hi, To those writing benchmarks, please note that the standard library provides std::make_shared() as an optimization for shared_ptr. It creates the object and its sh

Re: queue_transaction interface + unique_ptr + performance

On 03/12/2015, Somnath Roy wrote: > I don't think make_shared / make_unique is part of c++11 (and ceph is using > that). It is part of c++14 I guess.. std::make_shared is in C++11, std::make_unique is in C++14. In addition to performance, std::make_shared is also more correct, in that:

Re: queue_transaction interface + unique_ptr + performance

Hi, To those writing benchmarks, please note that the standard library provides std::make_shared() as an optimization for shared_ptr. It creates the object and its shared storage in a single allocation, instead of the two allocations required for "std::shared_ptr fs (new Foo())". Casey -

Re: queue_transaction interface + unique_ptr + performance

Well, yeah we are, it's just the actual Transaction structure which wouldn't be dynamic -- the buffers and many other fields would still hit the allocator. -Sam On Thu, Dec 3, 2015 at 11:29 AM, Casey Bodley wrote: > > - Original Message - >> Eh, Sage had a point that

Re: queue_transaction interface + unique_ptr + performance

- Original Message - > Eh, Sage had a point that Transaction has a bunch of little fields > which would have to be filled in -- its move constructor would be less > trivial than unique_ptr's. > -Sam It's true that the move ctor has to do work. I counted 18 fields, half of which are

Re: queue_transaction interface + unique_ptr + performance

y, December 3, 2015 6:50:26 AM > Subject: RE: queue_transaction interface + unique_ptr + performance > > 1- I agree we should avoid shared_ptr whenever possible. > > > sage -- -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://

Re: queue_transaction interface + unique_ptr + performance

gt; From: Adam C. Emerson [mailto:aemer...@redhat.com] > > Sent: Thursday, December 03, 2015 9:25 AM > > To: Somnath Roy > > Cc: Sage Weil; Samuel Just (sam.j...@inktank.com); > > ceph-devel@vger.kernel.org > > Subject: Re: queue_transaction interface + unique

Re: queue_transaction interface + unique_ptr + performance

- Original Message - > Well, yeah we are, it's just the actual Transaction structure which > wouldn't be dynamic -- the buffers and many other fields would still > hit the allocator. > -Sam Sure. I was looking specifically at the tradeoffs between allocating and moving the Transaction

Re: queue_transaction interface + unique_ptr + performance

Eh, Sage had a point that Transaction has a bunch of little fields which would have to be filled in -- its move constructor would be less trivial than unique_ptr's. -Sam On Thu, Dec 3, 2015 at 11:12 AM, Adam C. Emerson wrote: > On 03/12/2015, Casey Bodley wrote: > [snip] >>

Re: queue_transaction interface + unique_ptr + performance

On 03/12/2015, Casey Bodley wrote: [snip] > The queue_transactions() interface could take a container of Transactions, > rather than pointers to Transactions, and the ObjectStore would move them > out of the container into whatever representation it prefers. [snip] Or a pointer and count (or we

Re: queue_transaction interface + unique_ptr + performance

On Thu, 3 Dec 2015, Casey Bodley wrote: > > Well, yeah we are, it's just the actual Transaction structure which > > wouldn't be dynamic -- the buffers and many other fields would still > > hit the allocator. > > -Sam > > Sure. I was looking specifically at the tradeoffs between allocating > and

Re: queue_transaction interface + unique_ptr + performance

- Original Message - > On Thu, 3 Dec 2015, Casey Bodley wrote: > > > Well, yeah we are, it's just the actual Transaction structure which > > > wouldn't be dynamic -- the buffers and many other fields would still > > > hit the allocator. > > > -Sam > > > > Sure. I was looking specifically

Re: queue_transaction interface + unique_ptr + performance

>From a simplicity point of view, I'd rather just move a Transaction object than use a unique_ptr. Maybe the overhead doesn't end up being significant? -Sam On Thu, Dec 3, 2015 at 1:23 PM, Casey Bodley wrote: > > - Original Message - >> On Thu, 3 Dec 2015, Casey

RE: queue_transaction interface + unique_ptr + performance

:sj...@redhat.com] Sent: Thursday, December 03, 2015 3:24 PM To: Casey Bodley Cc: Sage Weil; Somnath Roy; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique_ptr + performance From a simplicity point of view, I'd rather just move a Tra

Re: queue_transaction interface + unique_ptr + performance

o understand if it is using Transaction object afterwards. >> >> Thanks & Regards >> Somnath >> -Original Message- >> From: Adam C. Emerson [mailto:aemer...@redhat.com] >> Sent: Thursday, December 03, 2015 9:25 AM >> To: Somnath Roy >> Cc: Sage Wei

RE: queue_transaction interface + unique_ptr + performance

sage- From: Adam C. Emerson [mailto:aemer...@redhat.com] Sent: Thursday, December 03, 2015 9:17 AM To: Somnath Roy Cc: Casey Bodley; Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique_ptr + performance On 03/12/2015, Somnath

RE: queue_transaction interface + unique_ptr + performance

. Thanks & Regards Somnath -Original Message- From: Adam C. Emerson [mailto:aemer...@redhat.com] Sent: Thursday, December 03, 2015 9:25 AM To: Somnath Roy Cc: Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique

RE: queue_transaction interface + unique_ptr + performance

03, 2015 9:51 AM To: Somnath Roy Cc: Adam C. Emerson; Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org Subject: Re: queue_transaction interface + unique_ptr + performance As far as I know, there are no current users which want to use the Transaction later. You could also

Re: queue_transaction interface + unique_ptr + performance

On 04/12/2015, Somnath Roy wrote: [snip] > # Test Shared Smart ptr ## > micros_used for shared ptr: 27105354 One thing to keep in mind is that, if there are any cases where we really DO want to use shared_ptr, if we find ourselves assigning a new pointer then releasing an old one, it's

Re: queue_transaction interface + unique_ptr + performance

com); ceph-devel@vger.kernel.org > Subject: Re: queue_transaction interface + unique_ptr + performance > > On 03/12/2015, Somnath Roy wrote: >> Yes, I posted the new result after adding -O2 in the compiler flag and it >> shows almost no overhead with unique_ptr. >&

Re: queue_transaction interface + unique_ptr + performance

e are getting.. > > Thanks & Regards > Somnath > > -Original Message- > From: Adam C. Emerson [mailto:aemer...@redhat.com] > Sent: Thursday, December 03, 2015 9:17 AM > To: Somnath Roy > Cc: Casey Bodley; Sage Weil; Samuel Just (sam.j...@inktank.com); > ceph-deve

RE: queue_transaction interface + unique_ptr + performance

); Samuel Just (sam.j...@inktank.com) Cc: ceph-devel@vger.kernel.org Subject: RE: queue_transaction interface + unique_ptr + performance Hi Somnath, Great findings. As you mentioned, unique_ptr and smart_ptr always have a well known problem about the performance comparing to conventional pointer , Got

RE: queue_transaction interface + unique_ptr + performance

ath Roy; Sage Weil (s...@newdream.net); Samuel Just (sam.j...@inktank.com) Cc: ceph-devel@vger.kernel.org Subject: RE: queue_transaction interface + unique_ptr + performance Hi Somnath, Great findings. As you mentioned, unique_ptr and smart_ptr always have a well known problem about the perf

RE: queue_transaction interface + unique_ptr + performance

: queue_transaction interface + unique_ptr + performance *Also*, in this way we are unnecessary adding another smart pointer overhead in the Ceph IO path. As I communicated sometimes back (probably 2 years now :-) ) in the community, profiler is showing these smart pointers (shared_ptr) as one of the hot spot

RE: queue_transaction interface + unique_ptr + performance

*Also*, in this way we are unnecessary adding another smart pointer overhead in the Ceph IO path. As I communicated sometimes back (probably 2 years now :-) ) in the community, profiler is showing these smart pointers (shared_ptr) as one of the hot spot. Now, I decided to actually measure