[Patch preview] libstdc++/24704
Paolo Carlini
pcarlini@suse.de
Mon May 22 16:47:00 GMT 2006
Hi,
upon Andrew insistence ;) I decided to return to this issue, and well,
apparently now I can imagine how to deal with it. An essential part of
the idea is the observation (originally made by Rth) that atomics are in
general *very* expensive, apparently very much so compared to
__gthread_active_p(), which is the important point of reference here.
Thus the below which I'm going to carefully regtest and performance test
on a few arches (besides x86-linux, which is fine), but I want to show
you early (maybe Bert can help with the tests, for example... and
*sorry* for not believing at all in the very feasibility of implementing
something similar).
Most of the patch consistes of mechanical renames, the "beef" being in
bits/atomicity.h where there are new dispatches to appropriate code:
either out of line, "full blown", __exchange_and_add and __atomic_add or
inline, trivial, __exchange_and_add_single and __atomic_add_single.
To give you an idea about the performance, a stupid program like this:
int main()
{
string a("1");
for (int i = 0; i < 10000000; ++i)
{
string ss1(a);
string ss2(ss1);
string ss3(ss2);
string ss4(ss3);
string ss5(ss4);
}
}
which does not involve threads, of course, goes (on my ready at hand
P4-2400):
mainline
6.380u 0.004s 0:06.38 100.0% 0+0k 0+0io 0pf+0w
patched
0.752u 0.004s 0:00.75 100.0% 0+0k 0+0io 0pf+0w
From the binary compatibility point of view, everything seems fine to
me, because we are still exporting untouched __exchange_and_add and
__atomic_add, and using them exactly like we were doing, when necessary
(__GTHREADS && __gthread_active_p()).
Pitfalls which I'm not seeing? Suggestions?
Thanks for now,
Paolo.
//////////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_24704_draft2
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20060522/866788ea/attachment.ksh>
More information about the Libstdc++
mailing list