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

Joel Sherrill joel.sherrill@OARcorp.com
Mon May 5 19:37:00 GMT 2003



Loren James Rittle wrote:
> 
> 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. ;-)

Not to beat a dying or already dead horse but what is the final solution 
for 3.3?

> Regards,
> Loren

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985



More information about the Gcc-patches mailing list