Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)

[Jerry Quinn <jlquinn at optonline dot net>]

I See I am too late for 3.3.0 :-(  Unfortunately, I haven't had the
bandwidth to sort this out fast enough for the release.  So my
apologies for ending up on the critical path.

That said ...

B. Kosnik writes:
 > 
 > Jerry.
 > 
 > I'm not quite sure what to do about this. I'm not super happy about
 > __string. No doubt, you are not pleased with this either. This seems
 > mighty hacky: the iword/pword stuff seems less so, since these are
 > reserved slots.

You're right, I wasn't very happy with it.  __string was just a
wrapper for the char buffer manipulations that were going to have to
happen anyway with this approach.  I jut thought it was less ugly to
wrap it up.

 > 
 > I'm trying to come up with an external allocator, so that you can just do
 > 
 > string<char, char_traits<char>, __extern_alloc> for this stuff.
 > 
 > I think that would be better.
 > 
 > I'll work on this today, and let you know where I am tonight. If this
 > cannot be resolved, I'm going to suggest that we temporarily back out
 > the locale cache from 3.3.0 until this has been satisfactorily resolved.
 > I'm sure this is a big bummer to you, and it is to me as well. The other
 > speed improvements are still in 3.3.0 though, so it won't be quite as
 > dire as 3.2.x. Thoughts?

Yeah, that's very disappointing.  With v3 as I just checked it out,
3.3 is still more than 2X slower than 2.95 on writing ints to file.
But we're making forward progress.

 > I'm also having second thoughts about this approach to locale caching in
 > general. I've implemented __has_cache/__use_cache and while it's not as fast
 > as the __locale_cache code as present, it's still on par with 2.95 and
 > it seems like a better way to go.
 > 
 > Awful lot of "I's" in the above text. Your honest feedback is appreciated.

I'd rather see it in there than not.  For sure, the ABI compatibility
puts some limitations on what we can do.  And I agree that the pword
method has some unpleasant aspects to it.  Also, we need something
like the __has_cache approach to deal with the problem pointed out by
Petur in this thread:
http://gcc.gnu.org/ml/libstdc++/2003-04/msg00023.html

Will the __has_cache approach be ABI compatible and avoid the
allocation issues that are sinking the current approach?

I remember suggesting that the pword mechanism might be used to hold
this stuff if ABI concerns pop up again.  Although this will again
require fiddling with the static streams.

I'd like to see the patch.  I'm surprised you are getting speeds
equivalent to 2.95.

 > Also, perhaps this has been confused in the past: can you make sure that
 > 3.3 check-ins pass "make check-abi" before checking in, or explicitly
 > note that on the patch? If this is unclear, please let me know how the
 > docs can be improved to better reflect reality. As I pointed out, there
 > is still work to be done in check-abi. 

I thought I mostly had (once I was aware of it), but I'll be more
explicit and careful about it in the future.

Jerry