You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2009/02/03 00:05:10 UTC
Interesting piece of work for C++
Some of the work being done has been around performance. At this point
we have 2 locks
that still need some work.
One of these locks are in the OS memory allocator, to this end I have
spoken to the glic/gcc
maintainers and they are working on a better malloc/free for us. However
the other side of the
equation is to do some optional memory caching.
The biggest area where this will help us is around frame caching. An
experiment in this area
has been done with TLS caching (did not work out as the caches need to
be cross thread) and
a global pool test has determined that we can reduce the number of
allocations by 25% with
such a cache.
However to do this we need a lock free bucket. So, if someone has
interest to create a lock free bucket.
I.e. a lock free structure that you can push pointers into and pop them
back off from many threads at
the same time. If the bucket is empty return NULL. No ordering is required.
What is interesting in that all the cost in a lock free fifo is the
corrections to maintain order which we
don't need. so the CAS or DCAS impls of fifo without order can be used.
For algorithms see work
from Maged M. Michael & Michael L. Scott -- or google a bit
The bucket needs to be able to do at least 2 million insertions and 2M
removals per second without
breaking a sweat.
anyone interested? - nice isolated task, and fun. thought I would toss
it out before I started working on it.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Interesting piece of work for C++
Posted by John O'Hara <jo...@gmail.com>.
I think APR tries to do this. However, some people don't want to take all
of APR.... is there no other project in Apache or indeed Boost that has
this construct already?
john
2009/2/2 Carl Trieloff <cc...@redhat.com>
>
> Some of the work being done has been around performance. At this point we
> have 2 locks
> that still need some work.
>
> One of these locks are in the OS memory allocator, to this end I have
> spoken to the glic/gcc
> maintainers and they are working on a better malloc/free for us. However
> the other side of the
> equation is to do some optional memory caching.
>
> The biggest area where this will help us is around frame caching. An
> experiment in this area
> has been done with TLS caching (did not work out as the caches need to be
> cross thread) and
> a global pool test has determined that we can reduce the number of
> allocations by 25% with
> such a cache.
>
> However to do this we need a lock free bucket. So, if someone has interest
> to create a lock free bucket.
>
> I.e. a lock free structure that you can push pointers into and pop them
> back off from many threads at
> the same time. If the bucket is empty return NULL. No ordering is required.
>
> What is interesting in that all the cost in a lock free fifo is the
> corrections to maintain order which we
> don't need. so the CAS or DCAS impls of fifo without order can be used. For
> algorithms see work
> from Maged M. Michael & Michael L. Scott -- or google a bit
>
> The bucket needs to be able to do at least 2 million insertions and 2M
> removals per second without
> breaking a sweat.
>
> anyone interested? - nice isolated task, and fun. thought I would toss it
> out before I started working on it.
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Interesting piece of work for C++
Posted by Carl Trieloff <cc...@redhat.com>.
Rajith Attapattu wrote:
> On Mon, Feb 2, 2009 at 6:05 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> Some of the work being done has been around performance. At this point we
>> have 2 locks
>> that still need some work.
>>
>> One of these locks are in the OS memory allocator, to this end I have
>> spoken to the glic/gcc
>> maintainers and they are working on a better malloc/free for us. However
>> the other side of the
>> equation is to do some optional memory caching.
>>
>> The biggest area where this will help us is around frame caching. An
>> experiment in this area
>> has been done with TLS caching (did not work out as the caches need to be
>> cross thread) and
>> a global pool test has determined that we can reduce the number of
>> allocations by 25% with
>> such a cache.
>>
>> However to do this we need a lock free bucket. So, if someone has interest
>> to create a lock free bucket.
>>
>> I.e. a lock free structure that you can push pointers into and pop them
>> back off from many threads at
>> the same time. If the bucket is empty return NULL. No ordering is required.
>>
>> What is interesting in that all the cost in a lock free fifo is the
>> corrections to maintain order which we
>> don't need. so the CAS or DCAS impls of fifo without order can be used. For
>> algorithms see work
>> from Maged M. Michael & Michael L. Scott -- or google a bit
>>
>>
>
> I had a stab at this sometime back. Started to experiment with the lock free
> version first.
> I think you would need DCAS as you need to swap both the pointer and the
> counter atomically.
> Not sure if this can be achieve with CAS only, especially when u move to 64
> bit machines.
> Also not all processors support DCAS either. So I gave up this route.
>
> I think a more feasible approach might be the two-lock queue . I had some
> code around this.
> Unfortunately haven't had much time to tinker with it any further. I believe
> Andrew/Gordon had done a simillar execersie.
> Andrew had some thoughts around this, perhaps he could chime in.
we don't need fifo for this case, so it can be done with atomics, cas or
dcas - no locks needed.
Carl.
Re: Interesting piece of work for C++
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Feb 2, 2009 at 6:05 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
> Some of the work being done has been around performance. At this point we
> have 2 locks
> that still need some work.
>
> One of these locks are in the OS memory allocator, to this end I have
> spoken to the glic/gcc
> maintainers and they are working on a better malloc/free for us. However
> the other side of the
> equation is to do some optional memory caching.
>
> The biggest area where this will help us is around frame caching. An
> experiment in this area
> has been done with TLS caching (did not work out as the caches need to be
> cross thread) and
> a global pool test has determined that we can reduce the number of
> allocations by 25% with
> such a cache.
>
> However to do this we need a lock free bucket. So, if someone has interest
> to create a lock free bucket.
>
> I.e. a lock free structure that you can push pointers into and pop them
> back off from many threads at
> the same time. If the bucket is empty return NULL. No ordering is required.
>
> What is interesting in that all the cost in a lock free fifo is the
> corrections to maintain order which we
> don't need. so the CAS or DCAS impls of fifo without order can be used. For
> algorithms see work
> from Maged M. Michael & Michael L. Scott -- or google a bit
>
I had a stab at this sometime back. Started to experiment with the lock free
version first.
I think you would need DCAS as you need to swap both the pointer and the
counter atomically.
Not sure if this can be achieve with CAS only, especially when u move to 64
bit machines.
Also not all processors support DCAS either. So I gave up this route.
I think a more feasible approach might be the two-lock queue . I had some
code around this.
Unfortunately haven't had much time to tinker with it any further. I believe
Andrew/Gordon had done a simillar execersie.
Andrew had some thoughts around this, perhaps he could chime in.
> The bucket needs to be able to do at least 2 million insertions and 2M
> removals per second without
> breaking a sweat.
>
> anyone interested? - nice isolated task, and fun. thought I would toss it
> out before I started working on it.
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/