Re: [boost] [thread] thread_specific_ptr performance

Subject: Re: [boost] [thread] thread_specific_ptr performance
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-01-12 06:24:46

Bugzilla from anthony.ajw_at_[hidden] wrote:
> 
> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
> 
>> On 01/11/2010 05:22 PM, Stefan Strasser wrote:
>>
>>> even though I understand the need for it now, it still seems odd
>>> that we use a std::map to simply access a value in another memory
>>> segment.
>>>
>>> have you thought about dynamically allocating an index into a
>>> (thread-specific) vector instead of a key based on the
>>> thread_specific_ptr's
>>> address?
>>> IIUC that would allow constant-time access in all cases.
>>
>> Yes, that's what I did in my patch in ticket #2361. One inconvenience
>> with that approach is to restrain the size of the vector if
>> thread_specific_ptrs are constantly created/destroyed. I did not solve
>> it in my patch but it should be quite doable.
>>
>> I really hope Anthony will take a look at it and come up with a
>> vector-based solution. Or I can finish the patch myself, if it has any
>> chance of getting into SVN. Anthony?
> 
> Boost 1.35 used a vector for the thread_specific_ptr data, but there
> were complaints about the excessive memory usage. The map version has a
> smaller memory footprint.
> 
> It is possible that an alternative scheme (such as using a sorted vector
> as a map) might yield something that is more reasonable on both fronts.
> 
> Anthony
> 

I would provide the thread_specific_ptr interface at several levels:
* 1st: using the specific 3pp/OS libraries interface (the number of
instances are limited by the 3pp/OS. The cost of this depends on the 3pp,
but usually is constant. The key need usualy less that 16bits.

* 2nd: the library could use a fixed size array allowing to extend the
number of TSS instances. The size of this direct access could be not too big
(256). The cost of this is the cost of 1st + one indirection +  constant
access to the array. The key need usually less that 16bits.

* 3rd: the library could use a dynamic size map as now allowing to avoid
limits. The cost of this is the cost of 1st + one indirection +  log(N)
access to the map. If the key is the address the key spends sizeof(void*).

The 1st level should be reserved to generic libraries that are could be used
by any application and with a high frequency usage of the get function. I'm
thinking for example to the current transaction on a transaction based
application, the current log, ...

We can also add another that could try on best level starting from a given
one: try the 1st level, if no 3pp/OS key is available it  continue with the
2nd level, and if not available continue with the 3rd level.

I'm sure we could store these keys on a 32bits for 32 bits machines. We need
just two bits to indicate the kind of key.

0 1st level
1 2nd level
2 3rd level

Just my 2cts
Vicente

-- 
View this message in context: http://old.nabble.com/Boost-library-submission-%28poll-for-interest%29-tp27020800p27126187.html
Sent from the Boost - Dev mailing list archive at Nabble.com.