[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