This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Are these files used anywhere?


Hi!

We are currently using the stl_pthread_alloc.h files and underlying implementation to get the best performance in our MT application.

There are a couple of things in this implementation that makes sense to us in terms of MT and multiprocessor support, such as the SGI_SOURCE that tries to align to cacheboundries:

          // Try to get memory that's aligned on something like a
          // cache line boundary, so as to avoid parceling out
          // parts of the same line to different threads and thus
          // possibly different processors.
          {
            const int __cache_line_size = 128;  // probable upper bound
            __bytes_to_get &= ~(__cache_line_size-1);
            _S_start_free = (char *)memalign(__cache_line_size, __bytes_to_get);
            if (0 == _S_start_free) {
              _S_start_free = (char *)malloc_alloc::allocate(__bytes_to_get);
            }
          }

One idea would be to look into a modification of the standard stl_alloc implementation so that this could be thread aware and tries to do more alignment than it currently does.

I.e. stl_alloc could keep a small per thread free list (ifdef __STL_THREADS) and one "per process/threadinspecific" free list (as it currently does) and the interface to malloc for chunks bigger than 128 bytes (the current limit).

In any case i think that we (newbies to the internal stuff of STL) could use a discussion/get an explanation about the design decisions made about the diffrent layers of memory caching. I am aware that this is hard to do since each platform has it's own malloc() implementation, but for instance under Linux it feels like we are doing cacheing on several levels (since the malloc() under linux keeps free lists of it's own).

/Stefan

Phil Edwards wrote:

In include/bits, pthread_allocimpl.h is mostly copied from stl_alloc.h,
and stl_pthread_alloc.h just wraps pthread_allocimpl.h.

They aren't included anywhere.  I just moved them aside, built with
--enable-threads=posix, and did a library testsuite run with no problems.

Any objections to removing them?  (Out of curiosity, anybody recall what
they were last used for?)

Phil

--
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

-- 
The Heineken Uncertainty Principle:
        You can never be sure how many beers you had last night.
 
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]