Re: PATCH (libstdc++-v3 mainline): Re-enable i386/atomicity.h

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <m3y91nf4ec.fsf@mira.informatik.hu-berlin.de>,
martin@v.loewis.de (Martin v. L�wis) writes:

> Now, with that patch accepted, there is an ABI change for i386. 

[For the record, the ABI change was actually introduced Nov 2002 to
 fix the usage of a non-i386 instruction in the i386 configuration.]

> If you would drop i486/atomicity.h, you would break binary
> compatibility with gcc-3.2-configured-for-i486+. If my understanding
> is correct (i.e. you would offer binary compatibility otherwise), I
> think i486/atomicity.h should stay.

OK.

> There are also performance considerations. I have timed the i386 and
> i486 versions on my PIII (performing the same atomic increment in a
> single thread over and over again), and found that the i386 version is
> still 50% slower than the i486 version. For i386-proper, this is ok:
> you can't do better on this processor.  For i486, I think the
> performance drop should be avoided, especially since more and more
> i386 systems will get replaced with i486+ over time, so many systems
> would have to pay for compatibility with systems that are rarely used.

Well, OK, thanks for running that test.  But, as you know, the use of
an atomic is typically buried inside of a use-case that does a
non-trivial amount of work (typically guarding the allocation of a
memory resource, etc.).  I measured 2-4% slowdown when the code path
is run in context in a test case that was designed to stress the path.
I think that number is more representative than an artificial use of
the atomic add.  But no matter, you line of argument wins for 3.3
release. ;-)

Regards,
Loren