This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)
- From: "B. Kosnik" <bkoz at nabi dot net>
- To: Jerry Quinn <jlquinn at optonline dot net>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 2 May 2003 00:34:06 -0500
- Subject: Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)
- References: <E190xa9-0006B0-00@tiamat><20030403103008.GA28026@alinoe.com><16012.17149.823856.404456@gargle.gargle.HOWL><20030411102928.GA32143@alinoe.com><16031.32556.123697.603768@gargle.gargle.HOWL><20030427153915.GA5850@alinoe.com><16044.51345.781643.861197@gargle.gargle.HOWL><16047.18989.705946.856897@gargle.gargle.HOWL><16048.47523.75693.638570@gargle.gargle.HOWL><20030501145155.7ce298cb.bkoz@nabi.net><16049.60536.905007.548382@gargle.gargle.HOWL>
>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.
No worries. Now we are free to work it out without the pressure of
looming deadlines.
>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.
Yep.
> > 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
Yeah.
>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.
Uncertain. I liked the pword mechanism for fitting this stuff back into
3.2.x abi, actually. It seems to work pretty well.
>I'd like to see the patch. I'm surprised you are getting speeds
>equivalent to 2.95.
I've gotten better results with mainline than v2 for a while now. This
is on athlon/p4/p3.
I'll try to clean it up enough to post. Some critical bits remain
unresolved, and I just hacked through all the ctype issues instead of
dealing with them correctly. I was just looking at num_put.
RH9, T30 (P4/1.8G/512) 2.96
6.630u 0.420s 0:09.40 75.0% 0+0k 0+0io 137pf+0w
RH9, T30 (P4/1.8G/512) 20030429-gcc-sh.exe
5.880u 0.410s 0:09.83 63.9% 0+0k 0+0io 215pf+0w
RH9, T30 (P4/1.8G/512) 20030429-gcc-static.exe NO __locale_cache
12.610u 0.390s 0:18.70 69.5% 0+0k 0+0io 122pf+0w
RH9, T30 (P4/1.8G/512) 20030429-gcc-3_3-branch.exe __use_cache
7.000u 0.300s 0:07.67 95.1% 0+0k 0+0io 124pf+0w
>I thought I mostly had (once I was aware of it), but I'll be more
>explicit and careful about it in the future.
Yep. I fixed up 'check-abi' for both added symbols and missing symbols.
-benjamin